How to fix OCI runtime create failed: container_linux.go: starting container process caused: exec: permission denied in Docker

Check if your entrypoint script has the execute permission. In your Dockerfile, add:

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

If you're using a local file, ensure it has execute permissions before building:

chmod +x entrypoint.sh
docker build -t myimage .

Verify inside a running container (if possible):

docker run --rm -it --entrypoint /bin/sh myimage -c "ls -la /entrypoint.sh"

Ensure your script has a valid shebang as the very first line:

#!/bin/bash
# or
#!/bin/sh
# or for better portability
#!/usr/bin/env bash

Common shebang issues:
- Missing shebang entirely
- Space before the shebang: #!/bin/bash (invalid)
- Wrong interpreter path: #!/bin/bash when bash isn't installed (use #!/bin/sh for Alpine)
- BOM (byte order mark) at the start of the file from Windows editors

Check for hidden characters:

head -1 entrypoint.sh | cat -A

The output should show exactly #!/bin/bash$ (the $ represents end of line).

Windows-style line endings can cause the shebang to be interpreted as #!/bin/bash\r which fails. Convert to Unix line endings:

Using dos2unix:

dos2unix entrypoint.sh

Using sed:

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

In your Dockerfile (fix during build):

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

Configure Git to preserve line endings:

# In .gitattributes
*.sh text eol=lf

If you're on a system with SELinux enabled, mounted volumes may be blocked from execution. Check SELinux status:

getenforce

Option A: Add the :z or :Z flag to volume mounts:

docker run -v /host/path:/container/path:z myimage

- :z - Relabels the content to be shared among containers
- :Z - Relabels the content as private (only this container)

Option B: Check for SELinux denials:

sudo ausearch -m avc -ts recent | grep docker

Option C: Temporarily set SELinux to permissive (for testing only):

sudo setenforce 0

If this fixes the issue, create a proper SELinux policy rather than leaving it permissive.

AppArmor can block container operations. Check if AppArmor is causing the issue:

Check AppArmor status:

sudo aa-status

Run container with AppArmor disabled (for testing):

docker run --security-opt apparmor=unconfined myimage

Check AppArmor denials:

sudo dmesg | grep -i apparmor | tail -20

If disabling AppArmor fixes the issue, consider creating a custom AppArmor profile rather than running unconfined in production.

If you're mounting a volume over a directory containing your entrypoint, the mounted content may override the executable:

Problematic setup:

# docker-compose.yml
volumes:
  - ./src:/app  # If /app/entrypoint.sh is your ENTRYPOINT, this overrides it

Solutions:

1. Mount to a subdirectory instead:

volumes:
  - ./src:/app/src

2. Keep entrypoint outside the mounted path:

COPY entrypoint.sh /usr/local/bin/entrypoint.sh
RUN chmod +x /usr/local/bin/entrypoint.sh
ENTRYPOINT ["/usr/local/bin/entrypoint.sh"]

3. Ensure the local file has execute permissions when mounting:

chmod +x ./src/entrypoint.sh

The error can also occur if the specified command doesn't exist. Test interactively:

# Override entrypoint to get a shell
docker run --rm -it --entrypoint /bin/sh myimage

# Inside container, check if the binary exists
which my-binary
ls -la /path/to/entrypoint

For Alpine-based images, remember that bash may not be installed:

# Use sh instead of bash
ENTRYPOINT ["/bin/sh", "/entrypoint.sh"]

# Or install bash
RUN apk add --no-cache bash