How to fix Container exited with code 126: command cannot be invoked in Docker

DockerINTERMEDIATEMEDIUMUpdated Dec 6, 2025· 219 views

Docker exit code 126 occurs when a command in your container specification is found but cannot be executed. This typically happens when entrypoint scripts or executable files lack proper execute permissions, preventing the container from starting successfully.

Quick fix

Fixes 126

docker logs <container-id>
# or
docker-compose logs <service-name>
  1. Check container logs to identify which file cannot be executed
  2. Add execute permissions in your Dockerfile
  3. Fix line endings for shell scripts
  4. Make file executable locally before building image
docker — error
docker logs <container-id>
# or
docker-compose logs <service-name>
Container exited with code 126: command cannot be invoked

What this error means

Exit code 126 is a standard Unix/Linux exit code that indicates a command or script exists but cannot be invoked. In Docker contexts, this means that the container runtime found the specified command (such as an entrypoint script or CMD executable) but was unable to execute it. This is distinct from exit code 127, which indicates the command was not found at all. With exit code 126, the file exists in the expected location but lacks the necessary permissions or proper file format to be executed by the container runtime. The error typically manifests during container startup when Docker attempts to run your ENTRYPOINT or CMD instruction. The container will start briefly, fail to execute the command, and immediately exit with code 126.

Typical symptoms

  • Container exits immediately after starting with code 126
  • Error message contains 'Permission denied' when referencing entrypoint or startup script
  • docker logs shows 'exec: permission denied' or similar execution errors
  • Container works when run with different entrypoint or command
  • Same Dockerfile works on one machine but fails on another with exit code 126
  • CI/CD pipeline fails at container start stage with exit code 126

Common causes

  1. Entrypoint script or executable file lacks execute permissions (most common cause)
  2. Line endings in shell scripts are Windows-style (CRLF) instead of Unix-style (LF), making scripts non-executable
  3. File was copied into container without preserving execute permissions
  4. Attempting to execute a file that is not a valid executable or script format
  5. SELinux or AppArmor security policies preventing execution in the container context
  6. Binary compiled for wrong architecture (e.g., ARM binary on x86 container)

How to fix "Container exited with code 126: command cannot be invoked"

1Check container logs to identify which file cannot be executed

First, identify exactly which file is causing the exit code 126 error:

bash
docker logs <container-id>
# or
docker-compose logs <service-name>

Look for error messages like:
- exec: "/entrypoint.sh": permission denied
- /usr/local/bin/docker-entrypoint.sh: Permission denied
- cannot execute binary file

This tells you which file needs permissions fixed.

2Add execute permissions in your Dockerfile

The most reliable fix is to add execute permissions directly in your Dockerfile before the file is used:

dockerfile
# Copy your script
COPY entrypoint.sh /usr/local/bin/

# Make it executable
RUN chmod +x /usr/local/bin/entrypoint.sh

# Use it as entrypoint
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

Place the chmod command immediately after copying the file and before it's used in ENTRYPOINT or CMD. This ensures permissions are set correctly in all environments.

3Fix line endings for shell scripts

If you're developing on Windows, your shell scripts may have Windows line endings (CRLF) which prevent them from executing on Linux containers:

Option 1: Fix locally before building

bash
# Convert line endings (Linux/Mac)
dos2unix entrypoint.sh

# Or using sed
sed -i 's/\r$//' entrypoint.sh

Option 2: Fix in Dockerfile

dockerfile
COPY entrypoint.sh /usr/local/bin/
RUN sed -i 's/\r$//' /usr/local/bin/entrypoint.sh && \
    chmod +x /usr/local/bin/entrypoint.sh

Option 3: Configure Git (preventative)
Add to your .gitattributes file:

bash
*.sh text eol=lf

This ensures Git always checks out shell scripts with Unix line endings.

4Make file executable locally before building image

If you prefer to set permissions before building, make the file executable on your host system:

bash
# Make script executable
chmod +x entrypoint.sh

# Verify it has execute permissions
ls -la entrypoint.sh
# Should show: -rwxr-xr-x

Then rebuild your Docker image. However, note that this approach can be less reliable across different operating systems and Git configurations. The Dockerfile approach (step 2) is generally more robust.

5Use COPY --chmod flag (Docker BuildKit)

If you're using Docker BuildKit (Docker 20.10+), you can set permissions directly in the COPY instruction:

dockerfile
# Enable BuildKit features
# syntax=docker/dockerfile:1

FROM ubuntu:22.04

# Copy with execute permissions
COPY --chmod=755 entrypoint.sh /usr/local/bin/entrypoint.sh

ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

This is the most elegant solution but requires BuildKit to be enabled:

bash
# Build with BuildKit
DOCKER_BUILDKIT=1 docker build -t myimage .
6Verify the fix and rebuild

After applying the fix, rebuild your image without using cache to ensure changes take effect:

bash
# Rebuild without cache
docker build --no-cache -t myimage .

# Run the container
docker run myimage

# Check exit code
docker ps -a
# Should show "Exited (0)" instead of "Exited (126)"

If the container still exits with code 126, inspect the filesystem inside the container to verify permissions:

bash
# Override entrypoint to inspect
docker run --rm --entrypoint ls myimage -la /usr/local/bin/entrypoint.sh

The file should show execute permissions (x flags in the permission string).

Advanced notes

Architecture Mismatches: Exit code 126 can also occur when trying to execute a binary compiled for a different architecture. For example, attempting to run an ARM64 binary in an AMD64 container will fail with "cannot execute binary file: Exec format error" and exit code 126. Use multi-architecture builds or ensure your base image matches your binary architecture.

SELinux Contexts: On systems with SELinux enabled (like RHEL/CentOS), files copied from the host may have incorrect security contexts. If you encounter this in production, you may need to adjust SELinux policies or run the container in permissive mode (not recommended for production).

Shebang Line Issues: Ensure shell scripts have a proper shebang line (#!/bin/sh or #!/bin/bash) as the first line. A missing or incorrect shebang can cause exec format errors. Also verify that the interpreter specified in the shebang exists in your container image.

Non-Executable File Formats: If you accidentally COPY a text file, Word document, or other non-executable format where Docker expects an executable, you'll get exit code 126. Verify your COPY commands are copying the correct files.

Docker Compose Considerations: When using docker-compose, ensure your entrypoint scripts are in the correct location relative to your docker-compose.yml file, and that volume mounts aren't overwriting executable files with non-executable versions from the host.

Frequently asked questions

What does "126" mean?
Exit code 126 is a standard Unix/Linux exit code that indicates a command or script exists but cannot be invoked. In Docker contexts, this means that the container runtime found the specified command (such as an entrypoint script or CMD executable) but was unable to execute it. This is distinct from exit code 127, which indicates the command was not found at all.
How do I fix "126"?
Docker exit code 126 occurs when a command in your container specification is found but cannot be executed. This typically happens when entrypoint scripts or executable files lack proper execute permissions, preventing the container from starting successfully.
What causes "126"?
Entrypoint script or executable file lacks execute permissions (most common cause) Line endings in shell scripts are Windows-style (CRLF) instead of Unix-style (LF), making scripts non-executable File was copied into container without preserving execute permissions
Is the "126" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading