Docker: OCI runtime create failed — executable file not found in $PATH

The exact error string

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: exec: "myapp": executable file not found in $PATH: unknown

# older Docker wording, same meaning:
# oci runtime error: container_linux.go:349: starting container process caused
# "exec: \"myapp\": executable file not found in $PATH"

The wall of runtime jargon obscures a simple message. Everything up to the last part is plumbing — containerd's shim, then runc, reporting that it failed to start the container process. The part that matters is at the very end: exec: "myapp": executable file not found in $PATH. Docker successfully pulled the image, created the container, and then tried to launch myapp inside it — and there is no such executable anywhere on the container's PATH.

Which cause is yours?

Fix 1: a typo in the command

The most common cause, and the easiest to dismiss too quickly. The name in your CMD, ENTRYPOINT, or docker run argument must match the executable exactly — Linux is case-sensitive, and a stray character is enough. These fail:

# "pyton" — typo
docker run myimage pyton app.py

# capital N — Linux is case-sensitive
docker run myimage Node app.js

Corrected:

docker run myimage python app.py
docker run myimage node app.js

Fix 2: the binary isn't in the image

Slim base images are deliberately minimal, and tools you assume are everywhere often aren't there. curl, git, ps, bash and make are all commonly absent. Verify by opening a shell in the image:

docker run --rm -it myimage sh
/ # which curl
/ #                       ← no output: curl is not installed
/ # echo $PATH            ← see exactly which directories were searched

If it's genuinely missing, install it in the Dockerfile:

# Debian/Ubuntu-based images
RUN apt-get update && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

# Alpine
RUN apk add --no-cache curl

Note the same-layer cleanup — installing packages without it silently inflates the image, which the Docker Image Optimizer flags along with the other size and caching issues in a Dockerfile.

Fix 3: the image has no shell (distroless / scratch)

This is the cause that confuses people most, because the command looks obviously correct. Docker's CMD and ENTRYPOINT have two syntaxes, and they behave very differently:

On a distroless or scratch base there is no /bin/sh at all, so shell form fails immediately — and the error names your program, not the shell, which is what makes it misleading. This fails, because shell form needs /bin/sh, which doesn't exist here:

FROM gcr.io/distroless/nodejs20
COPY . /app
CMD node /app/server.js

This works, because exec form runs the binary directly with no shell involved:

FROM gcr.io/distroless/nodejs20
COPY . /app
CMD ["node", "/app/server.js"]

The trade-off: exec form gives you no shell features. Variable expansion ($PORT), pipes, && chains and globbing all stop working, because there's no shell to interpret them. If you need those and a minimal image, either move the logic into an entrypoint script (and keep a shell in the image) or resolve the values at build time.

Fix 4: the file exists but isn't executable

If ls shows your script but it still won't run, check the permission bits. COPY does not reliably preserve the execute bit — especially when the file came from a Windows checkout:

/ # ls -l /entrypoint.sh
-rw-r--r--    1 root  root   214 Jul 19 09:00 /entrypoint.sh
#  ↑ no `x` anywhere — it is not executable

# fix it in the Dockerfile so it's baked into the image
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

# or set the bit at copy time (BuildKit)
COPY --chmod=755 entrypoint.sh /entrypoint.sh

The --chmod flag requires BuildKit (the default builder in current Docker, but not universal in older CI images or `DOCKER_BUILDKIT=0` setups) — on the legacy builder it is silently ignored rather than erroring, so the file ends up with the same permissions as before and the fix appears not to have worked. If you're not certain which builder is active, the RUN chmod +x form above works on both.

Also make sure you're using an absolute path, or that the script's directory is actually on PATH. A bare ENTRYPOINT ["entrypoint.sh"] only works if that directory is on the search path; ["/entrypoint.sh"] or ["./entrypoint.sh"] with a matching WORKDIR is unambiguous — see the WORKDIR pitfall below, which is more common than it sounds.

Fix 5: CRLF line endings from Windows

A script written or checked out on Windows has \r\n line endings. The shebang then reads as #!/bin/sh\r, and Linux dutifully looks for an interpreter literally named sh\r — which doesn't exist, producing a not-found error that points at a path looking perfectly correct:

# confirm: a trailing ^M or \r on every line means CRLF
cat -A entrypoint.sh | head -1
# #!/bin/sh^M$

dos2unix entrypoint.sh                    # convert to LF

# stop git from reintroducing it — .gitattributes:
*.sh text eol=lf

The .gitattributes rule is the durable fix; converting the file once only helps until the next checkout on a Windows machine. This same CRLF trap also produces exec format error depending on how the file is invoked, so it's worth ruling out whenever a script-based entrypoint misbehaves.

Fix 6: a relative path with no matching WORKDIR

More common than the CRLF case above, and easy to miss because the file clearly exists. A relative command — CMD ["./app"] or ENTRYPOINT ["./entrypoint.sh"] — is resolved against the container's current working directory, which comes from WORKDIR, not from wherever COPY happened to place the file. If WORKDIR is missing entirely, points somewhere else, or is declared after the CMD/ENTRYPOINT line, the relative path resolves against the wrong directory (often /) and the file isn't there:

# fails — no WORKDIR set, so "./app" resolves against / , not /app
FROM golang:1.22
COPY app /app/app
CMD ["./app"]

# works — WORKDIR makes the relative path resolve where the binary actually is
FROM golang:1.22
COPY app /app/app
WORKDIR /app
CMD ["./app"]

When in doubt, skip the ambiguity and use an absolute path instead — CMD ["/app/app"] works regardless of what WORKDIR is set to.

Fix 7: docker exec into a running container

Everything above assumes you're starting a new container. A large share of this error also shows up on a container that's already running, via docker exec, and it's worth calling out separately because the wording differs slightly:

$ docker exec -it mycontainer bash
OCI runtime exec failed: exec failed: unable to start container process:
exec: "bash": executable file not found in $PATH: unknown

Note exec failed rather than create failed — the container already exists, you're just failing to start a new process inside it. The overwhelmingly common cause is trying to exec into an alpine-based container with bash, which alpine doesn't ship:

docker exec -it mycontainer sh              # works on alpine — use sh instead of bash
docker exec -it mycontainer which bash      # confirms whether bash exists at all

If you specifically need bash for a debugging session, install it in the image (apk add --no-cache bash) rather than assuming it's there — the same fix as the alpine case above, just triggered via exec instead of run.

Not to be confused with: exec format error

These two are neighbours and easy to mix up:

Debugging checklist

• ✓ Read past the runc/shim noise — the real message is the final exec: "..." part
• ✓ docker run --rm -it myimage sh — can you even get a shell?
• ✓ No shell → distroless/scratch: switch CMD/ENTRYPOINT to exec form
• ✓ Shell works → which <cmd> and echo $PATH inside it
• ✓ Missing → typo, or install it (apt-get/apk add) in the Dockerfile
• ✓ Alpine asking for bash? Use /bin/sh or apk add --no-cache bash
• ✓ Script present but not running → ls -l for the x bit; RUN chmod +x
• ✓ cat -A the script — a trailing ^M means CRLF; convert to LF
• ✓ Using a relative command like ./app? Check WORKDIR is set, correct, and comes before CMD/ENTRYPOINT
• ✓ Error came from docker exec, not docker run? Try sh instead of bash — alpine has no bash