[GH-ISSUE #243] Windows Docker-compose exec fails with OCI runtime exec format error

kerem commented

2026-03-14 21:30:43 +03:00

Owner

Originally created by @djs-0415 on GitHub (May 18, 2019).
Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/243

I'm setting up ArchiveBox using the Docker image and instructions found here. Though it appears to have been successfully setup on my computer, I cannot use the main command to add an individual link

echo "https://example.com" | docker-compose exec -T archivebox /bin/archive

I expected the outputted archive data to be stored in my data/ volume but it does not appear to be, and I get the following error OCI runtime exec failed: exec failed: container_linux.go:344: starting container process caused "exec format error": unknown

Originally created by @djs-0415 on GitHub (May 18, 2019). Original GitHub issue: https://github.com/ArchiveBox/ArchiveBox/issues/243 I'm setting up ArchiveBox using the Docker image and instructions found [here](https://github.com/pirate/ArchiveBox/wiki/Docker#docker-compose). Though it appears to have been successfully setup on my computer, I cannot use the main command to add an individual link ```echo "https://example.com" | docker-compose exec -T archivebox /bin/archive``` I expected the outputted archive data to be stored in my data/ volume but it does not appear to be, and I get the following error ```OCI runtime exec failed: exec failed: container_linux.go:344: starting container process caused "exec format error": unknown```

kerem

2026-03-14 21:30:43 +03:00

closed this issue
added the
touches: data/schema/architecture
label

kerem commented

2026-03-14 21:30:59 +03:00

Author

Owner

@pirate commented on GitHub (Jul 9, 2019):

Strange, seems like it might be a docker issue specific to your system. Can you post your OS, docker, and docker-compose version info here?

# on linux
➜ lsb_release -a
# on mac
➜ sw_vers -productVersion

# docker info
➜  docker --version
Docker version 18.09.2, build 6247962
➜ docker-compose --version
docker-compose version 1.23.2, build 1110ad01

@pirate commented on GitHub (Jul 9, 2019): Strange, seems like it might be a docker issue specific to your system. Can you post your OS, docker, and docker-compose version info here? ``` # on linux ➜ lsb_release -a # on mac ➜ sw_vers -productVersion # docker info ➜ docker --version Docker version 18.09.2, build 6247962 ➜ docker-compose --version docker-compose version 1.23.2, build 1110ad01 ```

kerem commented

2026-03-14 21:31:04 +03:00

Author

Owner

@0xazure commented on GitHub (Nov 17, 2019):

Confirming I'm also seeing this error.

OS: Windows 10 1903
docker: Docker version 19.03.4, build 9012bf5
docker-compose: docker-compose version 1.24.1, build 4667896b

This is what I'm seeing:

docker-compose exec archivebox /bin/archive /data/sources/test.txt
OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec format error": unknown

I'm not really familiar with Docker, but here's some debugging I was able to do:

I can stat /bin/archive:

docker-compose exec archivebox stat /bin/archive
File: /bin/archive -> /home/pptruser/app/bin/archivebox
Size: 33              Blocks: 0          IO Block: 4096   symbolic link
Device: 801h/2049d      Inode: 656175      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2019-11-17 16:28:51.000000000 +0000
Modify: 2019-11-17 16:28:51.000000000 +0000
Change: 2019-11-17 16:28:52.317055100 +0000                                                                              Birth: -

Since /bin/archive is just a convenience symlink, I tried to run ./archivebox/archive.py directly:

docker-compose exec archivebox archivebox/archive.py
/usr/bin/env: ‘python3\r’: No such file or directory

even though:

docker-compose exec archivebox which python3
/usr/bin/python3

and

docker-compose exec archivebox /usr/bin/env python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39)

The work-around I found successful was to run archivebox/archive.py directly from python3:

docker-compose exec archivebox python3 archivebox/archive.py /data/sources/test.txt
[*] [2019-11-17 17:11:56] Parsing new links from output/sources/test.txt...
> Adding 3 new links to index (parsed import as Plain Text)
[*] [2019-11-17 17:11:56] Saving main index files...
    √ /data/index.json
    √ /data/index.html
[▶] [2019-11-17 17:11:56] Updating content for 3 pages in archive...

This change isn't onerous, it just doesn't match the instructions in the Docker setup article on the wiki.

Not entirely sure what the fix here would be, but hopefully this info is useful.

@0xazure commented on GitHub (Nov 17, 2019): Confirming I'm also seeing this error. OS: Windows 10 1903 `docker`: Docker version 19.03.4, build 9012bf5 `docker-compose`: docker-compose version 1.24.1, build 4667896b This is what I'm seeing: ```sh docker-compose exec archivebox /bin/archive /data/sources/test.txt OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec format error": unknown ``` I'm not really familiar with Docker, but here's some debugging I was able to do: I can `stat /bin/archive`: ```sh docker-compose exec archivebox stat /bin/archive File: /bin/archive -> /home/pptruser/app/bin/archivebox Size: 33 Blocks: 0 IO Block: 4096 symbolic link Device: 801h/2049d Inode: 656175 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2019-11-17 16:28:51.000000000 +0000 Modify: 2019-11-17 16:28:51.000000000 +0000 Change: 2019-11-17 16:28:52.317055100 +0000 Birth: - ``` Since `/bin/archive` is just a convenience symlink, I tried to run `./archivebox/archive.py` directly: ```sh docker-compose exec archivebox archivebox/archive.py /usr/bin/env: ‘python3\r’: No such file or directory ``` even though: ```sh docker-compose exec archivebox which python3 /usr/bin/python3 ``` and ```sh docker-compose exec archivebox /usr/bin/env python3 Python 3.5.3 (default, Sep 27 2018, 17:25:39) ``` The work-around I found successful was to run `archivebox/archive.py` directly from `python3`: ```sh docker-compose exec archivebox python3 archivebox/archive.py /data/sources/test.txt [*] [2019-11-17 17:11:56] Parsing new links from output/sources/test.txt... > Adding 3 new links to index (parsed import as Plain Text) [*] [2019-11-17 17:11:56] Saving main index files... √ /data/index.json √ /data/index.html [▶] [2019-11-17 17:11:56] Updating content for 3 pages in archive... ``` This change isn't onerous, it just doesn't match the instructions in the Docker setup article on the wiki. Not entirely sure what the fix here would be, but hopefully this info is useful.

kerem commented

2026-03-14 21:31:09 +03:00

Author

Owner

@eSoares commented on GitHub (Jan 21, 2020):

Hello,

From the error and from this [1] blog post, my guess is the error is the lack of shebang in the script run in CMD.

[1] - https://www.lewuathe.com/exec-format-error-in-docker-container.html

@eSoares commented on GitHub (Jan 21, 2020): Hello, From the error and from this [1] blog post, my guess is the error is the lack of shebang in the script run in CMD. [1] - https://www.lewuathe.com/exec-format-error-in-docker-container.html

kerem commented

2026-03-14 21:31:14 +03:00

Author

Owner

@pirate commented on GitHub (Feb 4, 2020):

As @0xazure mentions above, the bin/archive is just a symlink to archivebox/archive.py. Symlinks are special files with only one line (the path they point to), so we cant add a shebang to the symlink. I believe the problem is actually a rogue carriage return on the shebang line of archive.py (caused by merging someone's PR who edited it on windows).

I just removed any \r and added a \n to be safe, try the latest version and let me know if it's still happening.

@pirate commented on GitHub (Feb 4, 2020): As @0xazure mentions above, the `bin/archive` is just a symlink to `archivebox/archive.py`. Symlinks are special files with only one line (the path they point to), so we cant add a shebang to the symlink. I believe the problem is actually a rogue carriage return on the shebang line of `archive.py` (caused by merging someone's PR who edited it on windows). I just removed any `\r` and added a `\n` to be safe, try the latest version and let me know if it's still happening.

kerem commented

2026-03-14 21:31:20 +03:00

Author

Owner

@0xazure commented on GitHub (Feb 4, 2020):

I gave 90d8093bae30e600bdf2cc0958b232d80d268e33 (approximately latest master as of writing this) a go, and it still didn't work.

However, @pirate your comment about removing \r got me on track to identifying what I believe to be the issue.

When trying ~latest master, I was still seeing the same

docker-compose exec archivebox archivebox/archive.py
/usr/bin/env: ‘python3\r’: No such file or directory

error, specifically with that ‘python3\r’ problem. I have access to a macOS machine, so I went back to some earlier commits before the potential fix was introduced and tried to run ArchiveBox; every run was successful and did not display errors, so I had a suspicion that it was a Windows-host-only problem.

I don't really use Windows as a development environment, so I hadn't configured git at all; turns out core.autocrlf was set to true, which means on Windows git will check out files with \r\n endings even if the source repo only has \n. I set this to false, re-checked out ArchiveBox, and rebuilt the Docker container from scratch; this fixed running ArchiveBox as docker-compose exec archivebox archivebox/archive.py.

As for docker-compose exec archivebox /bin/archive not working, I think it's an issue related to the fact that Windows doesn't understand unix symlinks, so when they get copied over into the Docker container they're broken in some strange way.

TLDR; this looks like it's a Windows line ending (\r\n) on the host vs unix line ending (\n) on the guest issue surfaced by Docker. It might be worth adding a .gitattributes file to the repo to better control how line endings are handled across platforms. I also think (re?)generating the convenience symlinks as part of the Dockerfile setup might be worth it to ensure the symlinks work correctly if the host is non-unix (e.g. Windows).

Hopefully the above write-up helps, and let me know if I can assist with further testing!

@0xazure commented on GitHub (Feb 4, 2020): I gave `90d8093bae30e600bdf2cc0958b232d80d268e33` (approximately latest `master` as of writing this) a go, and it still didn't work. However, @pirate your comment about removing `\r` got me on track to identifying what I believe to be the issue. When trying ~latest `master`, I was still seeing the same ```sh docker-compose exec archivebox archivebox/archive.py /usr/bin/env: ‘python3\r’: No such file or directory ``` error, specifically with that `‘python3\r’` problem. I have access to a macOS machine, so I went back to some earlier commits before the potential fix was introduced and tried to run ArchiveBox; every run was successful and did not display errors, so I had a suspicion that it was a Windows-host-only problem. I don't really use Windows as a development environment, so I hadn't configured `git` at all; turns out [`core.autocrlf`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-coreautocrlf) was set to `true`, which means on Windows `git` will check out files with `\r\n` endings even if the source repo only has `\n`. I set this to `false`, re-checked out ArchiveBox, and rebuilt the Docker container from scratch; this fixed running ArchiveBox as `docker-compose exec archivebox archivebox/archive.py`. As for `docker-compose exec archivebox /bin/archive` not working, I think it's an issue related to the fact that Windows doesn't understand unix symlinks, so when they get [copied over into the Docker container](https://github.com/pirate/ArchiveBox/blob/90d8093bae30e600bdf2cc0958b232d80d268e33/Dockerfile#L50) they're broken in some strange way. **TLDR;** this looks like it's a Windows line ending (`\r\n`) on the host vs unix line ending (`\n`) on the guest issue surfaced by Docker. It might be worth adding a `.gitattributes` file to the repo to [better control how line endings are handled](https://www.git-scm.com/docs/gitattributes#_end_of_line_conversion) across platforms. I also think (re?)generating the convenience symlinks as part of the [Dockerfile](https://github.com/pirate/ArchiveBox/blob/90d8093bae30e600bdf2cc0958b232d80d268e33/Dockerfile) setup might be worth it to ensure the symlinks work correctly if the host is non-unix (e.g. Windows). Hopefully the above write-up helps, and let me know if I can assist with further testing!

kerem commented

2026-03-14 21:31:25 +03:00

Author

Owner

@pirate commented on GitHub (Feb 4, 2020):

Ah, in that case I'm tempted to just say I don't support Windows hosts. The repo should be cloned and run entirely in the WSL to avoid this problem. There are a number of other things that break on Windows hosts, so rather than patch over the problem I think I'd rather explicitly drop support.

@pirate commented on GitHub (Feb 4, 2020): Ah, in that case I'm tempted to just say I don't support Windows hosts. The repo should be cloned and run entirely in the WSL to avoid this problem. There are a number of other things that break on Windows hosts, so rather than patch over the problem I think I'd rather explicitly drop support.

kerem commented

2026-03-14 21:31:30 +03:00

Author

Owner

@pirate commented on GitHub (Jul 24, 2020):

You're welcome to try this on the latest version, it may change things but we still don't officially support windows.

docker pull nikisweeting/archivebox
# or git checkout django && git pull && docker build . -t archivebox

# cd path/to/archivebox/output
docker run -v $PWD:/data archivebox init
docker run -v $PWD:/data archivebox add 'https://example.com'

@pirate commented on GitHub (Jul 24, 2020): You're welcome to try this on the latest version, it may change things but we still don't officially support windows. ```bash docker pull nikisweeting/archivebox # or git checkout django && git pull && docker build . -t archivebox # cd path/to/archivebox/output docker run -v $PWD:/data archivebox init docker run -v $PWD:/data archivebox add 'https://example.com' ```

kerem commented

2026-03-14 21:31:35 +03:00

Author

Owner

@0xazure commented on GitHub (Jul 30, 2020):

Hey @pirate, that's totally fair about Windows support, no worries. I'm glad we were able to get to the bottom of the issue and hopefully the posts here will help others if they run into similar problems.

@0xazure commented on GitHub (Jul 30, 2020): Hey @pirate, that's totally fair about Windows support, no worries. I'm glad we were able to get to the bottom of the issue and hopefully the posts here will help others if they run into similar problems.

Rows
Columns

[GH-ISSUE #243] Windows Docker-compose exec fails with OCI runtime exec format error #3186