🚨 Docker Error Guide: 'container name is already in use' — Fix Naming Conflicts on docker run

Overview

Docker refuses to create a container because another container already holds the name you requested:

docker: Error response from daemon: Conflict. The container name "/myapp" is already in use by container "3f9a1c2b7e04...". You have to remove (or rename) that container to be able to reuse that name.

Container names are unique per daemon. A stopped container still reserves its name, so re-running with the same --name collides with the leftover until you remove or rename one of them.

Symptoms

• docker run --name myapp ... fails with Conflict and names an existing container ID.
• docker create fails the same way.
• A restarted script or CI job fails on the second run but worked the first time.
• docker ps shows nothing, but docker ps -a reveals a stopped container with the name.

Common Root Causes

• A stopped container still holds the name — exited containers keep their name until removed.
• A previous run was not cleaned up — the container was started without --rm and never removed.
• Two processes racing — a supervisor and a manual docker run both trying to create the same name.
• A crashed or restarting container — a container in a restart loop still occupies the name.
• Re-running an idempotent script — the script assumes a fresh daemon and always uses a fixed --name.

Diagnostic Workflow

List all containers, including stopped ones, and filter by the conflicting name:

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

Inspect the existing container’s state to decide whether to stop, remove, or keep it:

docker inspect --format '{{.Name}} {{.State.Status}} {{.Id}}' myapp

If it is disposable, stop it (if running) and remove it, then re-run:

docker stop myapp
docker rm myapp
docker run --name myapp -d myapp:1.4.2

If it is running and you must replace it in one step, force removal:

docker rm -f myapp
docker run --name myapp -d myapp:1.4.2

To keep the old one, choose a different name or let Docker auto-generate one:

docker run --name myapp-2 -d myapp:1.4.2

Example Root Cause Analysis

A deploy script failed on its second invocation:

Conflict. The container name "/myapp" is already in use by container "3f9a1c2b7e04...".

docker ps showed nothing running, but docker ps -a --filter "name=myapp" revealed:

CONTAINER ID   IMAGE          STATUS                     NAMES
3f9a1c2b7e04   myapp:1.4.1    Exited (0) 5 minutes ago   myapp

The prior deploy started the container without --rm, and the script stopped it but never removed it. The exited container still reserved the name myapp, so the next docker run --name myapp collided. The fix was to remove the old container before starting the new one:

docker rm -f myapp 2>/dev/null || true
docker run --name myapp -d myapp:1.4.2

rm -f is idempotent enough for a redeploy: it clears a running or stopped container, and the || true tolerates the first run when nothing exists yet.

Prevention Best Practices

• Use --rm for short-lived and CI containers so they never linger to cause a name conflict.
• In redeploy scripts, run docker rm -f <name> 2>/dev/null || true before docker run.
• Prefer orchestration (Docker Compose, systemd units) that manages container lifecycle and naming for you.
• Let Docker auto-generate names for ephemeral one-off runs instead of forcing a fixed --name.
• Periodically prune stopped containers: docker container prune -f.

Quick Command Reference

docker ps -a --filter "name=myapp"        # find the conflicting container
docker inspect --format '{{.State.Status}}' myapp
docker stop myapp                         # stop if running
docker rm myapp                           # remove to free the name
docker rm -f myapp                        # force-remove running container
docker container prune -f                 # clear all stopped containers

Conclusion

The name conflict means a container — usually a stopped leftover — already owns the name you passed to --name. List with docker ps -a, then remove or rename the old container to free the name. Using --rm for ephemeral work and a docker rm -f || true before redeploys makes the error disappear from your pipelines. Find more runtime fixes in the Docker stack guides.