How to fix OCI runtime create failed: container_linux.go: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory in Docker

DockerBEGINNERMEDIUMUpdated Dec 6, 2025· 372 views

This error occurs when you try to run or exec into a Docker container using /bin/bash, but the container's image doesn't include bash. This is common with Alpine, distroless, or scratch-based images that use minimal shells like sh or ash, or have no shell at all.

Quick fix

Fixes OCI runtime create failed: container_linux.go: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory

# Instead of this (fails on Alpine/minimal images):
docker exec -it mycontainer /bin/bash

# Use this:
docker exec -it mycontainer /bin/sh
  1. Use /bin/sh instead of /bin/bash
  2. Update your Dockerfile to use sh
  3. Install bash in Alpine-based images
  4. Handle distroless and scratch images
docker — error
# Instead of this (fails on Alpine/minimal images):
docker exec -it mycontainer /bin/bash
# Use this:
docker exec -it mycontainer /bin/sh
OCI runtime create failed: container_linux.go: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory

What this error means

The "no such file or directory" error for /bin/bash indicates that the Docker container you're trying to access doesn't have the bash shell installed. This happens because many lightweight Docker images are built to minimize size and attack surface by excluding unnecessary binaries. Alpine Linux images, which are extremely popular due to their ~5MB size, use BusyBox with ash (Almquist shell) instead of bash. Distroless images from Google and scratch-based images often have no shell at all. When you try to run `docker exec -it container /bin/bash` or set `CMD ["/bin/bash"]` in your Dockerfile, Docker can't find the executable and throws this OCI runtime error. The "OCI runtime create failed" prefix tells you this is a container creation/execution error at the runtime level, meaning the container can't even start the specified command because the binary simply doesn't exist in the image's filesystem.

Typical symptoms

  • docker exec -it container /bin/bash fails with 'no such file or directory'
  • Container fails to start with OCI runtime create failed error
  • Dockerfile CMD or ENTRYPOINT using /bin/bash causes container to exit immediately
  • Scripts with #!/bin/bash shebang fail to execute inside container
  • Error message contains 'stat /bin/bash: no such file or directory'
  • Container works when started with /bin/sh instead of /bin/bash

Common causes

  1. Using an Alpine-based image which includes ash/sh but not bash
  2. Using a distroless image that has no shell at all
  3. Using a scratch-based minimal image without any shell
  4. Base image had bash removed to reduce image size
  5. Dockerfile doesn't install bash package
  6. Using exec form CMD/ENTRYPOINT that requires a non-existent shell

How to fix "OCI runtime create failed: container_linux.go: starting container process caused: exec: "/bin/bash": stat /bin/bash: no such file or directory"

1Use /bin/sh instead of /bin/bash

The quickest fix is to use the shell that's actually available in the image. Most images include at least /bin/sh:

bash
# Instead of this (fails on Alpine/minimal images):
docker exec -it mycontainer /bin/bash

# Use this:
docker exec -it mycontainer /bin/sh

For Alpine images specifically, you can also use:

bash
docker exec -it mycontainer /bin/ash

To check what shells are available in an image:

bash
docker run --rm -it myimage ls -la /bin/*sh*
2Update your Dockerfile to use sh

If your Dockerfile uses bash in CMD or ENTRYPOINT, switch to sh:

dockerfile
# Before (fails on Alpine):
CMD ["/bin/bash", "-c", "echo hello"]
ENTRYPOINT ["/bin/bash", "/entrypoint.sh"]

# After (works on all images with a shell):
CMD ["/bin/sh", "-c", "echo hello"]
ENTRYPOINT ["/bin/sh", "/entrypoint.sh"]

Also update any shebang lines in your scripts:

bash
# Before:
#!/bin/bash

# After (POSIX-compatible):
#!/bin/sh

Note: Using sh means you lose bash-specific features like arrays, [[ ]] conditionals, and certain string manipulations. If you need these, install bash instead.

3Install bash in Alpine-based images

If you need bash features, install it in your Dockerfile:

dockerfile
FROM alpine:latest

# Install bash
RUN apk add --no-cache bash

# Now you can use /bin/bash
CMD ["/bin/bash"]

This adds about 4MB to your image size. For interactive shells:

bash
# First, rebuild the image with bash installed
docker build -t myimage:with-bash .

# Then you can exec with bash
docker exec -it mycontainer /bin/bash

You can also install bash interactively in a running container (changes won't persist):

bash
docker exec -it mycontainer /bin/sh -c "apk add --no-cache bash && /bin/bash"
4Handle distroless and scratch images

Distroless and scratch images have no shell at all. You cannot exec into them directly.

For debugging distroless images, use debug variants:

bash
# Google's distroless images have debug tags with busybox shell
docker run -it --entrypoint /busybox/sh gcr.io/distroless/base:debug

For scratch images, you must use multi-stage builds and ensure your binary doesn't need a shell:

dockerfile
# Build stage
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o myapp

# Runtime stage - no shell available
FROM scratch
COPY --from=builder /app/myapp /myapp
# Must use exec form (JSON array) - shell form won't work
ENTRYPOINT ["/myapp"]

To debug scratch containers, use docker cp or attach with a sidecar:

bash
# Copy files out for inspection
docker cp mycontainer:/app/logs ./logs

# Or use docker debug (Docker Desktop 4.27+)
docker debug mycontainer
5Use exec form for CMD and ENTRYPOINT

When using minimal images, always use the exec form (JSON array) instead of shell form:

dockerfile
# Shell form - requires /bin/sh to parse the command (will fail on scratch)
CMD echo "hello"
ENTRYPOINT /app/start.sh

# Exec form - runs directly without a shell (works on any image)
CMD ["echo", "hello"]
ENTRYPOINT ["/app/start.sh"]

The shell form implicitly wraps your command in /bin/sh -c "...". If /bin/sh doesn't exist, the container fails to start.

Mixed usage - you can use exec form ENTRYPOINT with shell form CMD for flexibility:

dockerfile
# Runs: /app/myapp with arguments from CMD
ENTRYPOINT ["/app/myapp"]
CMD ["--config", "/etc/app/config.yaml"]
6Verify which shell is available

Before writing your Dockerfile or exec commands, check what's available in your base image:

bash
# List all shell-like binaries
docker run --rm myimage ls -la /bin/ 2>/dev/null | grep -E 'sh|bash|ash|zsh'

# Check if specific shell exists
docker run --rm myimage which sh
docker run --rm myimage which bash

# Inspect the image's default shell
docker inspect --format='{{.Config.Shell}}' myimage

Common shells by base image:
- Ubuntu/Debian: bash, sh (dash)
- Alpine: ash, sh (symlink to ash)
- BusyBox: ash, sh
- Distroless: none (or busybox in :debug tags)
- Scratch: none

Advanced notes

Windows line endings: If you're getting "not found" errors even after verifying the shell exists, check for Windows line endings (CRLF) in your scripts. Convert them:

bash
# In Dockerfile
RUN sed -i 's/\r$//' /app/script.sh

# Or use dos2unix
RUN apk add --no-cache dos2unix && dos2unix /app/script.sh

Git Bash on Windows: When using Git Bash, paths get mangled. Use double slashes:

bash
docker exec -it container //bin/sh

Copying a shell into scratch images: For debugging, you can copy a static shell binary:

dockerfile
FROM scratch
COPY --from=busybox:uclibc /bin/sh /bin/sh

Using nsenter for shell-less containers: On Linux hosts, you can enter a container's namespaces directly:

bash
# Get the container's PID
PID=$(docker inspect --format '{{.State.Pid}}' mycontainer)

# Enter all namespaces
sudo nsenter -t $PID -m -u -i -n -p /bin/sh

Kubernetes debugging: Use ephemeral containers to debug distroless pods:

bash
kubectl debug -it mypod --image=busybox --target=mycontainer

Frequently asked questions

What does "OCI runtime create failed: container_linux.go: starting container proc" mean?
The "no such file or directory" error for /bin/bash indicates that the Docker container you're trying to access doesn't have the bash shell installed. This happens because many lightweight Docker images are built to minimize size and attack surface by excluding unnecessary binaries. Alpine Linux images, which are extremely popular due to their ~5MB size, use BusyBox with ash (Almquist shell) instead of bash.
How do I fix "OCI runtime create failed: container_linux.go: starting container proc"?
This error occurs when you try to run or exec into a Docker container using /bin/bash, but the container's image doesn't include bash. This is common with Alpine, distroless, or scratch-based images that use minimal shells like sh or ash, or have no shell at all.
What causes "OCI runtime create failed: container_linux.go: starting container proc"?
Using an Alpine-based image which includes ash/sh but not bash Using a distroless image that has no shell at all Using a scratch-based minimal image without any shell
Is the "OCI runtime create failed: container_linux.go: starting container proc" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading