🚨 Docker Error Guide: 'No command specified' — Fix Missing CMD/ENTRYPOINT

Overview

Docker raises this when you try to start a container from an image that has no default command and you did not supply one on the command line. The daemon has nothing to execute as PID 1, so container creation fails immediately:

docker: Error response from daemon: No command specified.

You will also see the equivalent at start time for an already-created container:

Error response from daemon: No command specified
Error: failed to start containers: <name>

Symptoms

• docker run myimage fails instantly with No command specified and no container logs are produced.
• The image builds fine, but nothing runs when you start it.
• A container created from a scratch or minimal base image (scratch, busybox rebuilt, a squashed image) will not start.
• docker start <container> fails for a container that was created with --entrypoint "" (entrypoint blanked out).
• Running the image with an explicit command (docker run myimage /bin/sh) works, but running it bare does not.

Common Root Causes

• No CMD or ENTRYPOINT in the Dockerfile — the image was built without either instruction and none was inherited from the base, so there is no default process.
• Base image has no default command — FROM scratch and some deliberately minimal images ship without a CMD; the child image must define one.
• Entrypoint blanked at run time — docker run --entrypoint "" myimage (with no trailing command) removes the entrypoint and leaves nothing to run.
• Inherited command was cleared — a multi-stage or FROM-based rebuild that resets ENTRYPOINT/CMD (e.g. ENTRYPOINT []) without providing a replacement.
• Compose service without a command — a docker-compose.yml service built from such an image and no command: key.
• Wrong image entirely — running a data-only or filesystem image that was never meant to be a runnable service.

Diagnostic Workflow

First confirm the image genuinely has no configured command. Inspect the Cmd and Entrypoint fields:

docker image inspect myimage --format 'Entrypoint={{.Config.Entrypoint}} Cmd={{.Config.Cmd}}'

A result of Entrypoint=[] Cmd=[] (both empty) confirms the image defines no default process:

Entrypoint=[] Cmd=[]

Check the image’s build history to see whether a CMD/ENTRYPOINT was ever set or later cleared:

docker history --no-trunc myimage | grep -i -E 'CMD|ENTRYPOINT'

If nothing prints, no such instruction is in the layers. Confirm the container can run when you supply a command explicitly, which isolates the cause to the missing default:

docker run --rm myimage /bin/sh -c 'echo it-runs'

For a Compose service, inspect the resolved config for a command or entrypoint:

docker compose config

Example Root Cause Analysis

A team built a tiny Go service on a distroless-style minimal base and pushed it. Deploys failed with:

docker: Error response from daemon: No command specified.

Inspecting the image showed both fields empty:

Entrypoint=[] Cmd=[]

The Dockerfile copied the compiled binary into the image but never told Docker to run it — it ended with the COPY and no ENTRYPOINT/CMD. The base image (FROM scratch) contributed no default either. Because the image had no process to launch, every docker run failed before a container ever started.

Fix: add an exec-form ENTRYPOINT naming the binary:

FROM scratch
COPY app /app
ENTRYPOINT ["/app"]

After rebuilding, docker image inspect showed Entrypoint=[/app] and the container started normally.

Prevention Best Practices

• Always end a runnable image’s Dockerfile with an explicit ENTRYPOINT and/or CMD in exec form (["/app"]), so PID 1 is deterministic.
• When you set ENTRYPOINT [] to clear an inherited entrypoint, immediately provide a replacement CMD or ENTRYPOINT.
• For FROM scratch and minimal bases, remember nothing is inherited — you must define the command yourself.
• If you deliberately blank the entrypoint at run time, always append the command to run: docker run --entrypoint "" myimage /bin/sh.
• Add a command: (or rely on the image default) for every Compose service and verify with docker compose config.
• Smoke-test images in CI with a bare docker run --rm myimage so a missing command is caught before deploy.

Quick Command Reference

# Show the image's default entrypoint and command
docker image inspect myimage --format 'Entrypoint={{.Config.Entrypoint}} Cmd={{.Config.Cmd}}'

# Find where CMD/ENTRYPOINT was set in the layers
docker history --no-trunc myimage | grep -iE 'CMD|ENTRYPOINT'

# Run the image with an explicit command to confirm it otherwise works
docker run --rm myimage /bin/sh -c 'echo ok'

# Run with an explicit entrypoint override plus command
docker run --rm --entrypoint /app myimage --flag value

# See a Compose service's resolved command/entrypoint
docker compose config

Conclusion

No command specified is Docker telling you the image has no default process and you did not provide one. Confirm it by inspecting Config.Entrypoint and Config.Cmd — if both are empty, the fix is to add an exec-form ENTRYPOINT/CMD to the Dockerfile (essential for scratch and minimal bases), restore an entrypoint you blanked, or pass a command on the docker run/Compose line. A bare docker run smoke test in CI catches this before it reaches production.