Docker "exec user process caused: no such file or directory"

The container’s init tried to exec the entrypoint and the kernel reported the target (or its interpreter) does not exist. Usually the file is there but its shebang interpreter or shared libraries are not.

What this error means

The container exits at startup with standard_init_linux.go:...: exec user process caused: "no such file or directory", even though the entrypoint file appears present in the image.

standard_init_linux.go:228: exec user process caused: no such file or directory
# entrypoint exists, but its #! interpreter (or a needed .so) does not

Common causes

CRLF line endings in the entrypoint script

A #!/bin/sh\r shebang (Windows CRLF) makes the kernel look for an interpreter literally named /bin/sh\r, which does not exist - reported as "no such file or directory".

Shebang interpreter not in the image

A script with #!/bin/bash in an Alpine image (which ships ash, not bash) fails because the interpreter path is absent.

A dynamically-linked binary missing its loader

A glibc-linked binary copied into a musl (Alpine) image cannot find its dynamic loader, producing the same "no such file or directory" at exec time.

How to fix it

Fix line endings and the shebang

Normalize the script to LF and point the shebang at an interpreter that exists in the image.

RUN sed -i 's/\r$//' /entrypoint.sh && chmod +x /entrypoint.sh
# use #!/bin/sh on Alpine; install bash if you need it
RUN apk add --no-cache bash

Match the binary’s libc to the base image

1. Build static binaries, or build against musl when targeting Alpine.
2. Use a glibc base (debian/ubuntu slim) for glibc-linked binaries.
3. Verify with ldd <binary> that all shared libraries resolve in the image.

How to prevent it

• Enforce LF endings on scripts via .gitattributes.
• Match the binary’s libc and interpreter to the base image.
• Smoke-test the image with docker run --rm <image> in CI before publishing.

Related guides