moby: starting container process caused: "exec: \"/bin/sh\": stat /bin/sh: no such file or directory"

You load the image when docker starting up. Just remove and install docker again. Work for me

guys, this error may be related to corrupted images (in my case there was shutdown of a build machine during build process). Subsequent attempt to build lead to this problem. So i fixed this by removing all images (including hidden ones) because i cant rely of them anymore. My save-day command was:

docker rmi -f $(docker images -aq)

!!! be careful - it will remove all your images !!!

Looking at the above, I don’t think there’s a bug at hand, so I’ll close this issue.

There are various reasons why this (or similar errors) can occur; some examples:

Create script.sh

cat <<-'EOF'> script.sh 
#!/bin/sh

echo "hello world"
EOF

Create Dockerfile

cat <<-'EOF'> Dockerfile
FROM busybox
COPY /script.sh /
CMD ["/script.sh"]
EOF

Now trying to build an image from these;

example1 fails, because script.sh is not executable:

$ docker build --no-cache -t example1 .
$ docker run --rm example1
docker: Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/script.sh\": permission denied": unknown.
``

example2: change the script to be executable, and build a new image. Now the image works:

```bash
$ chmod +x script.sh
$ docker build --no-cache -t example2 .
$ docker run --rm example2
hello world

example3; gives a “not found” error, even though the file exists, and is executable. This is because it has the wrong line-endinges (DOS/Windows), but Linux gives a cryptic error for that situation;

$ unix2dos script.sh
$ docker build --no-cache -t example3 .
$ docker run --rm example3
standard_init_linux.go:190: exec user process caused "no such file or directory"

Closing this issue, but hope the above helps

@fiantsev Thanks!! This worked for me, but, instead of removing all the images, I used docker images to see the images built today and removed them using docker rmi -f <list_of_image_ids>

The “bent image” clue helped me. I got here from googling the error. Docker had crashed while it was upping a project, and the image it was on apparently got bent when it hung, or when I forced Docker to restart.

Removing the specific image that was corrupted with docker rmi -f <myImageId> was a good start, but the full resolution was to prune after that so it stopped bringing the image back from my local cache. docker system prune

You just made a new issue, fixed it, then closed the issue. Ingenius!

$docker inspect gcr.io/distroless/static-debian11:debug
            "Cmd": null,
            "Entrypoint": [
                "/busybox/sh"
            ]

solution 1:

FROM gcr.io/distroless/static-debian11:debug
SHELL ["/busybox/sh", "-c"]
RUN xxx

solution 2:

RUN ["sh", "-c", "mkdir -p /app \
    && ln -sf /usr/local/bin/etcd* /app/etcd"]

works for me

In case anyone is still running into this issue (as I was)… Apparently sometimes this output can appear when you use single quotes instead of double quotes in an ENTRYPOINT or CMD directive.

For instance, the exact same Dockerfile with ENTRYPOINT ['/path/to/bin'] will produce an error message, but the one with ENTRYPOINT ["/path/to/bin"] will behave as expected, with no issues. For reference, this is the error message I was getting:

docker: Error response from daemon: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"/bin/sh\": stat /bin/sh: no such file or directory": unknown.
ERRO[0000] error waiting for container: context canceled 

Also, if you run docker inspect <your image>, the issue is pretty annoying to spot, as it’s not immediately obvious that the entrypoint command is wrapped in single quotes. See this output from the docker inspect command:

"Entrypoint": [
                "/bin/sh",
                "-c",
                "['/go/bin/app']"
            ],

Notice the single quotes.

I eventually stumbled on this article which helped me tremendously, but only after I had debugged this issue for 3 and a half hours.

It would be really nice for this to be fixed somehow, but I’m not sure where to log a fresh issue.

@fiantsev Thanks!! This worked for me, but, instead of removing all the images, I used docker images to see the images built today and removed them using docker rmi -f <list_of_image_ids>

You sir, are fantastic!