Main Ecosystems
HomePython CorePandas ReferenceNumPy ScientificFastAPI & PydanticDjango Enterprise
More Ecosystems
Environment & SetupRequests & HTTPAsyncIO ConcurrencyObject-Oriented OOPPyTorch Deep LearningScikit-Learn MLFlask FrameworkWeb ScrapingDatabase & ORMDevOps & Docker

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

Verified FixPython 3.10+Docker 25.0+ / Linux ContainersSilo: devops

Quick Fix / Solution Rapide

Convert entrypoint script line endings from Windows CRLF (\r\n) to Unix LF (\n) using dos2unix or .gitattributes.

Root Cause Analysis

This error occurs when a Linux Docker container starts executing its ENTRYPOINT or CMD script (e.g. entrypoint.sh), but the Linux kernel cannot execute the file because Windows carriage return line endings (\r\n) corrupt the shebang interpreter path (looking for #!/bin/sh\r).

1. Windows CRLF vs Linux LF Line Endings

On Windows, text editors and Git default to CRLF line endings. When an entrypoint.sh script with CRLF line endings is copied into a Linux container, the kernel reads the shebang as #!/bin/sh\r. Because no binary named /bin/sh\r exists on the Linux filesystem, it reports no such file or directory.

2. Missing Executable Permissions (chmod +x)

If the entrypoint script lacks execute permissions inside the container, Linux fails to invoke the user process.

3. Non-Existent Binary or Missing Shared Libraries

Compiling a binary (e.g. Go, C, or PyInstaller executable) against glibc and running it inside an Alpine Linux container (musl libc) causes dynamic linker missing errors.

4. Misspelled Shebang Interpret Paths

Using #!/usr/bin/bash in minimal Alpine containers where only #!/bin/sh or #!/bin/ash is installed.

Reproduction Code (MCVE)

Example: Bug Reproduction
# **Note de reproductibilité :** Dépendant de l'OS de l'hôte lors du build.
raise OSError('standard_init_linux.go:228: exec user process caused "no such file or directory" (corrupted shebang interpreter /bin/sh\\r)')

Solution 1: Convert Line Endings to LF and Set .gitattributes

Enforce Unix LF line endings across shell scripts using a repository .gitattributes file.

Example: Recommended Solution
print('Create or update .gitattributes in repository root:')
print('*.sh text eol=lf')
print('Dockerfile text eol=lf')
print('\nIn Dockerfile, install dos2unix as a safeguard:')
print('RUN apt-get update && apt-get install -y dos2unix \\')
print('    && dos2unix /app/entrypoint.sh \\')
print('    && chmod +x /app/entrypoint.sh')

Solution 2: Ensure Valid Shebang and POSIX Compatibility

Use #!/bin/sh for maximum portability across Alpine, Debian, and Ubuntu base images.

Example: Alternative Solution
print('#!/bin/sh')
print('set -e')
print('echo "Container starting..."')
print('exec "$@"')

A common mistake is checking file existence with ls inside the container and assuming the file is fine because entrypoint.sh is listed. The error message no such file or directory refers to the interpreter /bin/sh\r specified inside the shebang, NOT the script file itself. Always run dos2unix entrypoint.sh or check with file entrypoint.sh in Linux (look for 'with CRLF line terminators'). Contrast this error with Permission denied, which occurs when chmod +x was omitted.