runc · Docker
The message
standard_init_linux.go: exec user process caused: no such file or directory
What it means
The container tried to run its entrypoint and the kernel answered "no such file" — and the trap is that the file is plainly there. The script's line endings are CRLF, so the first line reads as #!/bin/sh\r and the kernel goes looking for an interpreter literally named sh\r; cloning on Windows or leaving git's autocrlf on produces exactly this. dos2unix entrypoint.sh converts that one file (or sed -i 's/\r$//' entrypoint.sh without it), and a .gitattributes line of *.sh text eol=lf stops it coming back. Naming an interpreter in #! that the image does not have — bash in an alpine image — gives the same words.
The fix
dos2unix entrypoint.sh- Printed by
- runc
- Docker
- 12
Docker errors only become readable once you place them in a layer — the client failing to reach the daemon, the registry refusing you, a RUN failing during the build, and a container dying the instant it starts are four different problems — and for the build and run layers the line itself is not the reason: the reason is in the output of the command that was running inside, while the cost of each fix differs by layer too.
Reading an error message
- Read from the first line down. The lower you go the more it is about the tool’s internals; the cause is usually at the top.
- If there is a file and a line number, start there — not the top stack frame, but the topmost line that names a file you wrote.
- Search the message verbatim, but strip your own paths and variable names first; those are what stop the search from matching.
- The same condition is worded differently across tool versions. If results look wrong, add the version number to the query.
- Before pasting a fix, check what it throws away. Some of these cannot be undone.
Common questions
Q. What does “standard_init_linux.go: exec user process caused: no such file or directory” mean?
The container tried to run its entrypoint and the kernel answered "no such file" — and the trap is that the file is plainly there. The script's line endings are CRLF, so the first line reads as #!/bin/sh\r and the kernel goes looking for an interpreter literally named sh\r; cloning on Windows or leaving git's autocrlf on produces exactly this. dos2unix entrypoint.sh converts that one file (or sed -i 's/\r$//' entrypoint.sh without it), and a .gitattributes line of *.sh text eol=lf stops it coming back. Naming an interpreter in #! that the image does not have — bash in an alpine image — gives the same words.
Q. How do I fix it?
dos2unix entrypoint.sh — before running it, check the explanation above for what this command discards.
Q. Which tool prints this?
runc. It sits under Docker, and the message runs to 10 words.