How to fix standard_init_linux.go: exec user process caused: no such file or directory in Docker

DockerBEGINNERMEDIUMUpdated Dec 1, 2025· 253 views

This error occurs when Docker cannot execute an entrypoint script or binary, typically because of Windows-style line endings (CRLF) in shell scripts. Converting files to Unix line endings (LF) resolves the issue in most cases.

Quick fix

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

file entrypoint.sh
  1. Check if the file has Windows line endings
  2. Convert line endings using dos2unix
  3. Convert line endings using sed
  4. Fix line endings in your IDE
docker — error
file entrypoint.sh
standard_init_linux.go: exec user process caused: no such file or directory

What this error means

When you see `standard_init_linux.go: exec user process caused: no such file or directory`, Docker is trying to execute your entrypoint script or binary but failing to find the interpreter or required libraries. Despite the confusing message, the file usually exists - the issue is that Docker cannot properly parse or execute it. The most common cause is Windows-style line endings (CRLF) in shell scripts. When a script like `entrypoint.sh` contains `#!/bin/bash\r\n` instead of `#!/bin/bash\n`, Linux interprets this as looking for an interpreter named `/bin/bash\r` (with a carriage return), which does not exist. This typically happens when developers create or edit scripts on Windows, or when Git automatically converts line endings. Less commonly, this error can indicate missing dynamic libraries in minimal base images like Alpine, or architecture mismatches between the build and runtime environments.

Typical symptoms

  • Container crashes immediately on startup with 'exec user process caused: no such file or directory'
  • Error mentions 'standard_init_linux.go' with varying line numbers (175, 178, 190, 211, 219, 228)
  • The entrypoint script file clearly exists when you inspect the container filesystem
  • Error started occurring after editing scripts on Windows or cloning on a Windows machine
  • Works fine on one developer's machine (Mac/Linux) but fails on another's (Windows)
  • CI/CD pipeline fails at container startup even though build succeeded

Common causes

  1. Shell script has Windows line endings (CRLF) instead of Unix line endings (LF)
  2. Git auto-converted line endings when cloning on Windows (core.autocrlf setting)
  3. IDE or text editor saved the file with Windows line endings
  4. Binary was compiled with dynamic linking on a different Linux distribution (glibc vs musl)
  5. Missing shared libraries in minimal base images like Alpine Linux
  6. Architecture mismatch (e.g., arm64 image running on x86_64 host)
  7. Shebang line references an interpreter that does not exist in the container

How to fix "standard_init_linux.go: exec user process caused: no such file or directory"

1Check if the file has Windows line endings

First, verify whether line endings are the culprit. You can inspect your script file using:

bash
file entrypoint.sh

If it shows "CRLF line terminators" or "with CRLF", that's the problem. You can also check with:

bash
cat -A entrypoint.sh | head -5

If you see ^M at the end of lines, those are carriage return characters from Windows.

2Convert line endings using dos2unix

The easiest fix is to convert the file to Unix line endings:

bash
dos2unix entrypoint.sh

If dos2unix is not installed, you can install it:

bash
# Ubuntu/Debian
sudo apt-get install dos2unix

# macOS
brew install dos2unix

# Alpine
apk add dos2unix
3Convert line endings using sed

If you cannot install dos2unix, use sed to strip carriage returns:

bash
sed -i 's/\r$//' entrypoint.sh

On macOS, you may need:

bash
sed -i '' 's/\r$//' entrypoint.sh
4Fix line endings in your IDE

You can also fix this directly in your editor:

VS Code: Look at the bottom-right status bar. Click on "CRLF" and select "LF", then save the file.

Notepad++: Go to Edit > EOL Conversion > Unix (LF), then save.

JetBrains IDEs: File > Line Separators > LF - Unix and macOS

5Add dos2unix to your Dockerfile

If you cannot control the source files (e.g., they come from a Windows-only environment), fix them during the Docker build:

dockerfile
# For Debian/Ubuntu based images
RUN apt-get update && apt-get install -y dos2unix \
    && dos2unix /app/entrypoint.sh \
    && apt-get remove -y dos2unix && apt-get autoremove -y

# For Alpine based images
RUN apk add --no-cache dos2unix \
    && dos2unix /app/entrypoint.sh \
    && apk del dos2unix

Alternatively, use sed without installing additional packages:

dockerfile
RUN sed -i 's/\r$//' /app/entrypoint.sh
6Configure Git to preserve line endings

Prevent this issue from recurring by configuring Git. Create or update .gitattributes in your repository root:

bash
# Force LF line endings for shell scripts
*.sh text eol=lf

# Force LF for other common script types
*.bash text eol=lf
*.zsh text eol=lf
Dockerfile text eol=lf
docker-entrypoint* text eol=lf

Alternatively, configure Git globally:

bash
git config --global core.autocrlf input

This converts CRLF to LF on commit but does not modify files on checkout.

7Rebuild the Docker image

After fixing the line endings, you must rebuild the image for changes to take effect:

bash
docker build --no-cache -t your-image:tag .

The --no-cache flag ensures Docker does not use cached layers that might contain the old file.

8Check for missing libraries (Alpine/Go binaries)

If line endings are not the issue, the problem might be missing dynamic libraries. This is common with Go binaries on Alpine:

dockerfile
# Option 1: Build a static binary (Go)
ENV CGO_ENABLED=0
RUN go build -o /app/myapp .

# Option 2: Use a compatible base image
FROM golang:1.21-alpine AS builder
# ... build steps ...

FROM alpine:3.18
RUN apk add --no-cache libc6-compat
COPY --from=builder /app/myapp /app/myapp

You can check what libraries a binary needs:

bash
ldd /app/myapp

Advanced notes

Why the error message is misleading: The Linux kernel reports "no such file or directory" when it cannot find the interpreter specified in a script's shebang line. When #!/bin/bash\r has a carriage return, the kernel looks for a program literally named /bin/bash\r, which does not exist, hence the error.

Multi-stage builds: When using multi-stage Docker builds, line ending issues in scripts copied between stages can be tricky. Consider converting line endings in the first stage before copying to the final image.

Binary compatibility: If you are building on Ubuntu/Debian and deploying to Alpine, remember that Alpine uses musl libc while most other distributions use glibc. Use CGO_ENABLED=0 for Go, or ensure your runtime image has compatible libraries.

ARM vs x86: This error can also occur when trying to run an image built for a different architecture. Use docker buildx for multi-architecture builds:

bash
docker buildx build --platform linux/amd64,linux/arm64 -t myimage:latest .

Frequently asked questions

What does "standard_init_linux.go: exec user process caused: no such file or dire" mean?
go: exec user process caused: no such file or directory, Docker is trying to execute your entrypoint script or binary but failing to find the interpreter or required libraries. Despite the confusing message, the file usually exists - the issue is that Docker cannot properly parse or execute it. The most common cause is Windows-style line endings (CRLF) in shell scripts.
How do I fix "standard_init_linux.go: exec user process caused: no such file or dire"?
This error occurs when Docker cannot execute an entrypoint script or binary, typically because of Windows-style line endings (CRLF) in shell scripts. Converting files to Unix line endings (LF) resolves the issue in most cases.
What causes "standard_init_linux.go: exec user process caused: no such file or dire"?
Shell script has Windows line endings (CRLF) instead of Unix line endings (LF) Git auto-converted line endings when cloning on Windows (core.autocrlf setting) IDE or text editor saved the file with Windows line endings
Is the "standard_init_linux.go: exec user process caused: no such file or dire" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading