How to Resolve "exec user process caused: no such file or directory" in Docker

The error "exec user process caused: no such file or directory" occurs during Docker container startup when the Linux kernel fails to execute the designated ENTRYPOINT or CMD binary/script. Despite the misleading wording, this error rarely means the entrypoint file itself is completely missing. Instead, it typically indicates that the script contains Windows CRLF line endings, points to an invalid shell interpreter in its shebang line (e.g., #!/bin/bash on Alpine), or lacks required dynamic binary dependencies.

The Problem

When starting a container with docker run or docker-compose up, the container immediately stops or enters a CrashLoopBackOff state. The logs display one of these exact exception formats:

standard_init_linux.go:228: exec user process caused: no such file or directory

On newer Docker versions with containerd, the message is formatted as:

exec /entrypoint.sh: no such file or directory

Error: failed to start container "app": Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "/app/entrypoint.sh": stat /app/entrypoint.sh: no such file or directory

Why It Happens

When Linux attempts to execute a file specified in ENTRYPOINT or CMD, the kernel reads the first line (the shebang) or checks dynamic binary libraries. This error triggers due to:

• CRLF Line Endings: The entrypoint script was edited or checked out on Windows using CRLF ( ) line breaks. Linux interprets the shebang #!/bin/sh , attempting to execute a interpreter file named /bin/sh which does not exist.
• Missing Shell Interpreter: The script specifies #!/bin/bash, but the base container image (like Alpine Linux) only includes /bin/sh.
• Missing C Library Dependencies: A compiled Go, Rust, or C binary compiled on another OS lacks required shared libraries (e.g., dynamic glibc dependencies missing in a scratch or alpine image).
• Incorrect Working Directory: The ENTRYPOINT path is defined using a relative path that fails to resolve because WORKDIR was set incorrectly in the Dockerfile.

The Fix

The most common fix is converting script line endings from CRLF (Windows) to LF (Unix).

Step 1: Convert line endings from CRLF to LF

Run dos2unix on your entrypoint script directly on your host workstation before building the image:

dos2unix entrypoint.sh

Alternatively, convert line endings inside your Dockerfile using sed during the build phase:

COPY entrypoint.sh /entrypoint.sh
RUN sed -i 's/
$//' /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

To prevent Git on Windows from converting files back to CRLF automatically, add a .gitattributes file to your repository root:

*.sh text eol=lf

Step 2: Fix Shebang lines for minimal images

Ensure your entrypoint.sh shebang uses standard POSIX shell (/bin/sh) if you are building on Alpine Linux base images:

#!/bin/sh
set -e

exec "$@"

If your script specifically requires bash, install bash in your Dockerfile:

RUN apk add --no-cache bash

Step 3: Ensure executable permissions

Ensure the script has executable permissions prior to image creation:

chmod +x entrypoint.sh

Still Not Working?

If you encounter this issue with compiled binaries (e.g., Go binaries) running inside scratch or alpine images, the binary was likely linked dynamically against glibc on the host system.

Recompile your Go binary as a static executable by disabling CGO during compilation:

CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o myapp .

Static binaries do not rely on external shared object dynamic linkers like ld-linux.so and will execute natively inside minimal Docker images without throwing exec user process caused: no such file or directory.