Windows Docker-compose exec fails with OCI runtime exec format error

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

[0xazure]

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]

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!