How to fix /bin/sh: 1: mycommand: not found in Docker

DockerBEGINNERLOWUpdated Dec 1, 2025· 412 views

This error occurs when Docker tries to execute a command or binary that doesn't exist in the container's filesystem or isn't in the PATH. It commonly happens with minimal base images like Alpine or when using the scratch base image that lacks shell utilities.

Quick fix

Fixes /bin/sh: 1: mycommand: not found

docker run --rm -it your-image-name ls /bin
  1. Identify the missing command
  2. Use exec form for CMD/ENTRYPOINT with minimal images
  3. Install missing commands in your Dockerfile
  4. Add executable to PATH or use absolute paths
docker — error
docker run --rm -it your-image-name ls /bin
/bin/sh: 1: mycommand: not found

What this error means

The "command not found" error in Docker containers indicates that the container runtime cannot locate the executable you're trying to run. This typically manifests as "/bin/sh: 1: mycommand: not found" and occurs when Docker uses /bin/sh to parse your CMD or ENTRYPOINT instructions but cannot find either the shell itself or the command you want to execute. Docker containers are isolated environments with their own filesystem. Unlike your host system, they only contain files explicitly added through your Dockerfile (via base image, COPY, ADD, or RUN commands). If you reference a binary that wasn't included in the image build, the container has no way to execute it. This error is particularly common when using minimal base images (scratch, Alpine, distroless) that intentionally exclude utilities to reduce image size, or when switching from full-featured base images like Ubuntu to lighter alternatives without adjusting your Dockerfile commands accordingly.

Typical symptoms

  • Container exits immediately with '/bin/sh: 1: command: not found' error
  • Docker build fails during RUN commands with 'not found' errors
  • Container starts but application fails with 'executable file not found in $PATH'
  • Multi-stage builds work in earlier stages but fail in final stage
  • Same Dockerfile works on one machine but fails on another
  • Docker exec commands fail when trying to run utilities like bash or curl

Common causes

  1. Using minimal base images (scratch, Alpine, distroless) that don't include /bin/sh or common utilities
  2. Executable not installed in the container image during build
  3. Binary not in the container's PATH environment variable
  4. Using shell form of CMD/ENTRYPOINT with images lacking a shell
  5. Missing execute permissions on copied binaries or scripts
  6. Volume mounts overlaying directories containing executables
  7. Multi-stage builds where binaries installed in earlier stages aren't copied to final stage
  8. COPY command accidentally overwriting system directories like /bin
  9. Missing dynamic libraries required by the executable
  10. Scripts referencing interpreters not present in the image (#!/bin/bash when only /bin/sh exists)

How to fix "/bin/sh: 1: mycommand: not found"

1Identify the missing command

First, determine exactly what command is missing. Check your Dockerfile's CMD or ENTRYPOINT instruction and note which executable is failing.

If the error mentions '/bin/sh' itself is not found, you're using a base image without a shell (like scratch). If it's '/bin/sh: 1: mycommand: not found', the shell exists but can't find your command.

Run this to inspect your image and check what's actually in it:

bash
docker run --rm -it your-image-name ls /bin

If this fails with the same error, your base image is too minimal to support shell commands.

2Use exec form for CMD/ENTRYPOINT with minimal images

If you're using FROM scratch or other minimal base images, switch from shell form to exec form in your Dockerfile. This removes the dependency on /bin/sh.

Before (shell form - requires /bin/sh):

dockerfile
CMD myapp --port 8080

After (exec form - direct binary execution):

dockerfile
CMD ["myapp", "--port", "8080"]

The exec form passes arguments as a JSON array and Docker executes the binary directly without invoking a shell. This works with scratch and distroless images.

Similarly for ENTRYPOINT:

dockerfile
ENTRYPOINT ["/app/myapp"]
CMD ["--config", "/etc/config.yaml"]
3Install missing commands in your Dockerfile

If your application needs specific utilities, install them during the image build. For Alpine Linux base images:

dockerfile
FROM alpine:3.19

# Install common utilities
RUN apk add --no-cache bash curl wget git

# Install your application dependencies
COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . /app
WORKDIR /app
CMD ["python", "app.py"]

For Debian/Ubuntu images:

dockerfile
FROM ubuntu:22.04

RUN apt-get update && apt-get install -y \
    curl \
    git \
    wget \
 && rm -rf /var/lib/apt/lists/*

Make sure installations happen before you try to use the commands.

4Add executable to PATH or use absolute paths

If you're copying a binary into your image, either place it in a directory that's already in PATH, or update PATH to include your binary's location.

Option 1: Copy to standard location

dockerfile
COPY myapp /usr/local/bin/myapp
RUN chmod +x /usr/local/bin/myapp
CMD ["myapp"]

Option 2: Update PATH environment variable

dockerfile
COPY myapp /app/bin/myapp
RUN chmod +x /app/bin/myapp
ENV PATH="/app/bin:$PATH"
CMD ["myapp"]

Option 3: Use absolute path

dockerfile
COPY myapp /app/myapp
RUN chmod +x /app/myapp
CMD ["/app/myapp"]

Note the chmod +x command to ensure execute permissions are set.

5Fix multi-stage build issues

In multi-stage builds, files from earlier stages don't automatically carry over. If you installed binaries in an earlier stage, you must explicitly copy them to the final stage.

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

# Final stage - scratch has no shell/utilities
FROM scratch
# Copy the binary from builder stage
COPY --from=builder /build/myapp /myapp
ENTRYPOINT ["/myapp"]

If your app needs shared libraries, copy those too:

dockerfile
FROM alpine:3.19 AS final
COPY --from=builder /build/myapp /usr/local/bin/myapp
COPY --from=builder /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/
CMD ["myapp"]
6Verify script interpreters exist

If you're running shell scripts, ensure the shebang line matches available interpreters in your container.

Check what's available in your base image:

bash
docker run --rm alpine:3.19 ls -l /bin/sh /bin/bash

Alpine has /bin/sh but not /bin/bash by default. Update your scripts:

Before:

bash
#!/bin/bash
echo "Hello"

After (for Alpine):

bash
#!/bin/sh
echo "Hello"

Or install bash in your Dockerfile:

dockerfile
RUN apk add --no-cache bash
7Check for volume mount conflicts

Volumes can overlay directories in your image. If you mount a volume at /app and your binary is in /app/myapp, the volume will hide the binary.

Problematic docker-compose.yml:

yaml
volumes:
  - ./src:/app  # This hides everything in /app from the image

Solution 1: Mount at subdirectory

yaml
volumes:
  - ./src:/app/src  # Only overlay the src subdirectory

Solution 2: Keep binaries outside mounted path

dockerfile
COPY myapp /usr/local/bin/myapp
WORKDIR /app
# Now mounting at /app won't hide the binary

Advanced notes

Missing Dynamic Libraries: If your binary was compiled on a different system, it may depend on shared libraries not present in your minimal Docker image. Use ldd /path/to/binary on the host to see dependencies, or switch to static compilation:

bash
# Go static binary
CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o myapp

# Rust static binary
cargo build --release --target x86_64-unknown-linux-musl

Distroless Images: Google's distroless images provide a middle ground between scratch and full distros. They include minimal runtime dependencies (libc, SSL certs) but no shell, package managers, or utilities. Use exec form commands exclusively.

Debugging Minimal Images: You can't docker exec into scratch or distroless images to debug. Instead, temporarily switch your Dockerfile to use the debug variant:

dockerfile
# FROM gcr.io/distroless/static-debian11
FROM gcr.io/distroless/static-debian11:debug

The debug tag includes a busybox shell for troubleshooting. Remove it before production.

Platform Architecture Issues: If you build on Apple Silicon (ARM64) but deploy to AMD64, ensure you specify the platform:

bash
docker build --platform linux/amd64 -t myapp .

Or use buildx for multi-platform builds.

Frequently asked questions

What does "/bin/sh: 1: mycommand: not found" mean?
The "command not found" error in Docker containers indicates that the container runtime cannot locate the executable you're trying to run. This typically manifests as "/bin/sh: 1: mycommand: not found" and occurs when Docker uses /bin/sh to parse your CMD or ENTRYPOINT instructions but cannot find either the shell itself or the command you want to execute. Docker containers are isolated environments with their own filesystem.
How do I fix "/bin/sh: 1: mycommand: not found"?
This error occurs when Docker tries to execute a command or binary that doesn't exist in the container's filesystem or isn't in the PATH. It commonly happens with minimal base images like Alpine or when using the scratch base image that lacks shell utilities.
What causes "/bin/sh: 1: mycommand: not found"?
Using minimal base images (scratch, Alpine, distroless) that don't include /bin/sh or common utilities Executable not installed in the container image during build Binary not in the container's PATH environment variable
Is the "/bin/sh: 1: mycommand: not found" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading