🚨 Docker Error Guide: 'No such container' — Fix Missing Container References

Overview

A command targeting a container fails because the daemon has no container matching the name or ID you gave it:

Error response from daemon: No such container: myapp

docker exec, docker logs, docker stop, docker inspect, and similar commands resolve their argument to an existing container. If the name is misspelled, the container was removed, or it never existed on this daemon, Docker returns No such container.

Symptoms

• docker exec, docker logs, or docker stop fails with No such container.
• docker ps does not list the container you referenced.
• A script that just created and removed a container tries to use it again.
• A short ID prefix no longer uniquely matches any container.

Common Root Causes

• Typo in the name or ID — a single wrong character means no match.
• Container was removed — a --rm container exited and cleaned itself up, or someone ran docker rm.
• Container is on a different host or context — you are pointed at the wrong daemon via docker context.
• Container never started — a failed docker run left nothing behind.
• Using a name that was never assigned — assuming a --name that the run command did not set.
• Race in scripts — referencing the container before creation completes or after auto-removal.

Diagnostic Workflow

List all containers, running and stopped, to see what actually exists:

docker ps -a

Search specifically for the name you expected:

docker ps -a --filter "name=myapp"

Confirm you are talking to the right daemon; a wrong context is a common surprise:

docker context ls
docker context show

If you expect a container that exited with --rm, check the daemon logs or event stream:

docker events --since 10m --filter "container=myapp"

When you do have a valid reference, verify its state before acting on it:

docker inspect --format '{{.Name}} {{.State.Status}}' <container-id>

Example Root Cause Analysis

A health-check script intermittently failed:

Error response from daemon: No such container: myapp

docker ps -a --filter "name=myapp" returned nothing at the moment of failure. The container had been started with --rm for a one-shot migration:

docker run --rm --name myapp myapp:1.4.2 migrate

Because --rm removes the container as soon as it exits, the follow-up docker logs myapp sometimes ran after the migration finished and the container had already been auto-removed. There was simply no container left to reference. The fix was to drop --rm for jobs whose logs are inspected afterward, then remove the container explicitly once done:

docker run --name myapp myapp:1.4.2 migrate
docker logs myapp
docker rm myapp

The lesson: --rm and post-run inspection do not mix — the container disappears the instant it exits.

Prevention Best Practices

• Verify container existence with docker ps -a (or a --filter) before commands that assume it.
• Avoid --rm for containers whose logs or exit state you inspect after they finish.
• Confirm the active docker context when managing remote or multiple daemons.
• Use exact, stable names via --name rather than short ID prefixes that can become ambiguous.
• In scripts, guard actions with docker inspect <name> >/dev/null 2>&1 && ... so a missing container fails gracefully.

Quick Command Reference

docker ps -a                              # list all containers
docker ps -a --filter "name=myapp"        # find by name
docker context ls                         # check daemons you can target
docker inspect --format '{{.State.Status}}' myapp
docker events --since 10m --filter "container=myapp"

Conclusion

No such container means Docker resolved your name or ID to nothing on the current daemon — usually a typo, a removed --rm container, or the wrong context. List with docker ps -a, confirm the context, and reference containers by exact stable names. Skipping --rm where you need post-run logs eliminates the most common surprise. More runtime fixes live in the Docker stack guides.