How to fix "Error response from daemon: No such container"

Overview

Docker prints "Error response from daemon: No such container" when the target container name or ID does not match any container visible to the current Docker context/daemon. Common causes include typos, removed containers, wrong Docker context or host, and Compose name differences.

Quickstart (most common fixes)

• Verify the container exists: docker ps -a --format '{{.Names}}\t{{.ID}}'
• Use exact name or full ID: docker stop <id> or docker rm <id>
• Check your Docker context/host: docker context ls and docker context use default
• For Compose: use docker compose ps and reference the Compose-assigned name
• If using sudo/rootless inconsistently: try the same command with or without sudo

Minimal working example

This reproduces the error and shows how to fix it.

# 1) Create a container
docker run -d --name demo-nginx -p 8080:80 nginx:alpine

# 2) Typo when stopping -> error
docker stop demo-ngnix
# => Error response from daemon: No such container: demo-ngnix

# 3) Discover the correct name or ID
docker ps --format '{{.Names}}\t{{.ID}}'
# demo-nginx    4f1c7c7a3d9b

# 4) Use the correct reference
docker stop demo-nginx

# 5) If it was already removed, confirm via ps -a
docker ps -a --format '{{.Names}}\t{{.ID}}' | grep demo-nginx || echo "not found"

Step-by-step diagnosis

1. List containers (running and exited)

• docker ps -a --no-trunc
• Look for the target container in the Names column. If missing, it truly does not exist on this daemon.

1. Check for typos and ambiguous matches

• Prefer full container IDs or exact names.
• To match exactly by name: docker ps -a --filter name='^/my-container$'

1. Confirm the current Docker context/host

• Show contexts: docker context ls
• Switch if needed: docker context use default
• If using a remote host: ensure DOCKER_HOST points to the right daemon; clear it to use local: unset DOCKER_HOST

1. Root vs rootless vs sudo (Linux)

• Containers started with sudo docker ... likely run under the root-managed daemon.
• If you created containers without sudo, use the same for subsequent commands.
• Try both: docker ps -a and sudo docker ps -a to see which daemon has the container.

1. Docker Compose naming

• Compose prefixes names: <project>_<service>_<index>.
• Check names with docker compose ps or docker ps --format '{{.Names}}'.
• Use docker compose stop <service> instead of raw container names when possible.

1. Confirm the container hasn’t been removed

• Recent cleanup could have pruned it: docker system df to review reclaimable space.
• If removed, recreate: e.g., docker run ... or docker compose up -d.

1. Validate you’re not mixing tooling

• Podman or nerdctl are different from Docker; containers won’t be visible across tools.
• Ensure your commands use the same CLI/daemon you used to create the container.

1. Ensure the daemon is running

• docker info should succeed; if it fails, start Docker Desktop or the Linux service.

Special cases and remedies

• Stopped containers: You can still reference them with docker start <id> or docker rm <id>. Use docker ps -a to see stopped containers.
• Partial ID collisions: If multiple containers share the same prefix, specify a longer prefix or the full ID.
• Duplicate names: Docker denies duplicate names. If a name is free but your command errors, you might be on the wrong context/daemon.
• Swarm/Stacks: Services create task containers with generated names. Use docker service ps <service> and docker stack ps <stack> to identify actual task containers.

Recovery patterns

• Recreate from image
  • docker run -d --name <name> <image:tag>
• Recreate from Compose
  • docker compose up -d (in the project directory)
• Restore from saved artifacts
  • If you exported the container: docker import/docker load (for images), then re-run a container.

Pitfalls to avoid

• Assuming names are global: Names are per-daemon. Different contexts/hosts can have containers with the same names.
• Forgetting Compose prefixes: Don’t look for web, look for <project>_web_1 unless you set container_name.
• Case sensitivity: Names and IDs are case-sensitive.
• Pruning blindly: docker system prune -a removes stopped containers and unused images; ensure you don’t need them.
• Mixing shells/ENV: A set DOCKER_HOST, DOCKER_CONTEXT, or KUBECONFIG may point you away from the expected environment.

Performance notes

• Prefer filtering to reduce output:
  • docker ps -a --filter name='myapp' --format '{{.ID}}\t{{.Names}}'
• Avoid repeated full ps -a in scripts; cache IDs in variables:
  • CID=$(docker ps -aqf name='^/myapp$') && [ -n "$CID" ] && docker stop "$CID"
• Use exact IDs in automation to skip name resolution.
• For large hosts, --format significantly speeds up ps output processing.

Tiny FAQ

Q: I can see the container in Docker Desktop UI, but CLI says "No such container". A: Verify CLI context matches the UI’s selected context. Run docker context ls and switch if needed.

Q: After reboot, I get the error for containers started by systemd. A: Ensure Docker started before the service, or add Requires=docker.service and After=docker.service in your unit.

Q: docker rm returns the error, but docker images shows the image. A: Images and containers are different objects. Recreate the container: docker run ....

Q: Compose reports no such container for a service. A: Run in the project directory and use docker compose ps. The real container name includes the project prefix.

Q: Using SSH remote, commands fail with the error. A: Confirm the remote daemon is reachable and you have permissions. Check docker context inspect <ctx> and your SSH key/host.