Introduction

Docker no such container means the daemon you are talking to cannot find a container matching the name or ID in your command. The container may have exited and been removed, been recreated under another name, or exist on a different daemon context.

Symptoms

  • docker exec, logs, or rm returns no such container
  • The command worked earlier but now fails for the same name
  • docker ps does not show the expected workload

Common Causes

  • The container exited and was removed with --rm
  • The name or ID is wrong or stale
  • You are connected to a different Docker context

Step-by-Step Fix

  1. 1.Confirm whether the container still exists
  2. 2.Check both running and exited containers before assuming Docker lost state.
bash
docker ps -a
docker ps -a --format "table {{.ID}}\t{{.Names}}\t{{.Status}}"
  1. 1.Verify you are talking to the expected daemon
  2. 2.The same name can exist on one Docker context but not another.
bash
docker context ls
docker context show
docker info
  1. 1.Check whether the workload was auto-removed or recreated
  2. 2.Containers started with --rm, Compose updates, and CI jobs often replace the original container ID.
bash
docker compose ps
docker events --since 10m
  1. 1.Retry the command with the current name or ID
  2. 2.Use the exact value from docker ps -a, not a cached name from an earlier runbook or shell history.
bash
docker logs <current-container-name>
docker exec -it <current-container-name> /bin/sh
  1. 1.If the container is gone, move upstream
  2. 2.Inspect the service definition, restart policy, and deploy tooling that created the container rather than retrying the same dead ID.

Prevention

  • Prefer stable service names from Compose or orchestration instead of memorizing container IDs
  • Be careful with --rm when you still need post-failure inspection
  • Check docker context show in scripts and incident runbooks
  • Investigate recreate loops in Compose, CI, or deploy automation when names keep changing