exec: "/entrypoint.sh": permission denied at the end of a long OCI runtime create failed line here meant the container's entrypoint script existed but had no execute bit. Add RUN chmod +x /entrypoint.sh to the Dockerfile, rebuild the image and run it again.

In the test below the script was written inside the image by a RUN line and got mode -rw-r--r--. One more RUN chmod +x line turned it into -rwxr-xr-x and the container started.

The error

PS> docker run --rm --name fix8-d3-ep-nox fix8-d3-ep:nox
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/entrypoint.sh": permission denied
System.Management.Automation.RemoteException
Run 'docker run --help' for more information

The exit code was 126. The System.Management.Automation.RemoteException line comes from the Windows PowerShell 5.1 capture of Docker's error output, not from Docker. The Dockerfile: 

FROM alpine
RUN echo '#!/bin/sh' > /entrypoint.sh && echo 'echo "fix8-d3 entrypoint ran"' >> /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

Why it happens

The file named in ENTRYPOINT is started as a program, and starting a file as a program needs the execute permission on Linux. The file created with echo ... > inside the image had none. Overriding the entrypoint showed the mode: 

PS> docker run --rm --entrypoint ls fix8-d3-ep:nox -l /entrypoint.sh
-rw-r--r--    1 root     root            40 Nov  6 08:17 /entrypoint.sh

The build itself succeeded; the error only appears when a container starts. A first attempt that copied the same script with COPY entrypoint.sh /entrypoint.sh from a Windows folder did not reproduce the error on this machine: the copied file arrived as -rwxr-xr-x and the container printed its line. On this setup the mode of a script written inside the image decided the outcome.

The fix

FROM alpine
RUN echo '#!/bin/sh' > /entrypoint.sh && echo 'echo "fix8-d3 entrypoint ran"' >> /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
PS> docker build -q -t fix8-d3-ep:fixed .
sha256:b252002fa57064ef14461b9b366ba9695ca82498cb20c4d7aecdddedd94379db
PS> docker run --rm --name fix8-d3-ep-fixed fix8-d3-ep:fixed
fix8-d3 entrypoint ran
PS> docker run --rm --entrypoint ls fix8-d3-ep:fixed -l /entrypoint.sh
-rwxr-xr-x    1 root     root            40 Nov  6 08:17 /entrypoint.sh

The chmod line sits after the line that creates the script, and the rebuilt image held the file as -rwxr-xr-x. Checking the mode with --entrypoint ls, as above, is a quick way to see what the image holds without starting the script itself.

How it was reproduced

A two-line script written into an alpine image by a RUN echo line, no chmod, used as ENTRYPOINT; built with docker build -q -t fix8-d3-ep:nox . and started with docker run from Windows PowerShell 5.1 on Docker Engine 29.9.2 (Docker Desktop on Windows 11, base image built from alpine-minirootfs-3.24.2). The fix8-d3- names are this test's. The containers ran with --rm, and the three test images were removed afterwards with docker rmi.

Frequently asked

What does 'exec: "/entrypoint.sh": permission denied' mean in Docker?
The entrypoint script is in the image but has no execute permission. In this test it had mode -rw-r--r--, and docker run stopped with OCI runtime create failed and exit code 126.
How do I make an entrypoint script executable in a Dockerfile?
Add RUN chmod +x /entrypoint.sh after the line that creates or copies the script, rebuild the image, and run it again. In this test the mode became -rwxr-xr-x and the container started.
How can I check the permissions of a file inside a Docker image?
Override the entrypoint with ls, for example docker run --rm --entrypoint ls image -l /entrypoint.sh. It prints the mode without running the script.

More decoded errors in the Fixes category. If the message ends in "no such file or directory" instead, see Docker: exec /entrypoint.sh: no such file or directory.