Dash0 Raises $110M Series B at $1B Valuation

  • 13 min read

How to Fix "Name Already in Use by Container" in Docker

You run docker run --name web nginx to bring up a service and Docker comes back with this:

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

Docker is telling you exactly what to do — remove or rename. Which one is right depends on what's in the old container and whether you need it. A throwaway dev container is one command away from being out of your hair. A Postgres container that's mid-write needs a more careful approach.

Container names are unique per Docker host. When a container exits, it doesn't disappear. It sits in the exited state with its writable layer intact, holding onto its name until you explicitly remove it. That's what makes docker start <name> work later, and it's also what causes this error.

This article covers the four commands that fix or prevent the conflict: docker rm, docker rm -f, docker rename, and the --rm flag on docker run.

Why the name is taken

Run docker ps -a to see every container Docker knows about, not just the running ones:

bash
1
docker ps -a
123
CONTAINER ID   IMAGE          COMMAND                  STATUS                      NAMES
a4f8c9e12345   nginx:latest   "/docker-entrypoint.…"   Exited (0) 5 minutes ago    web
b7d2f8a91234   postgres:16    "docker-entrypoint.s…"   Up 2 hours                  db

The container named web is there, just stopped. As long as it exists in any state (created, restarting, running, paused, exited, removing, or dead), its name is claimed.

To narrow down to just the conflicting container:

bash
1
docker ps -a --filter "name=web"

Pay attention to STATUS. If it shows Up ..., the container is running and you'll need different commands than if it's Exited (...). The wrong command on a running database container will ruin your afternoon.

Remove a stopped container with docker rm

If the conflicting container is stopped, this is the simplest fix:

bash
1
docker rm web
1
web

Docker prints the name on success. Now run your original docker run command again and it'll work.

docker rm deletes the container's writable layer along with the container itself. Anything inside that wasn't backed by a volume is gone for good. If the container had a database, application logs that weren't shipped elsewhere, or files written at runtime, that's the cost of removal. Named volumes and bind mounts are never removed by docker rm. Anonymous volumes (created without a name) survive too, unless you pass -v.

You can remove multiple at once:

bash
1
docker rm web api worker

To clean up every stopped container on the host in one shot:

bash
1
docker container prune

Docker asks for confirmation. Add -f to skip the prompt in scripts. The How to Remove a Docker Container FAQ goes deeper on volume cleanup, filter-based removal, and the docker container rm alias.

Force-remove a running container with docker rm -f

If the container is running or paused, plain docker rm refuses:

1
Error response from daemon: cannot remove container "/web": container is running: stop the container before removing or force remove

You have two options. Stop it cleanly first, then remove:

bash
1
docker stop web && docker rm web

Or do both in one step with -f:

bash
1
docker rm -f web

These two are not equivalent. docker stop sends SIGTERM and waits up to 10 seconds (configurable with --timeout) for the process to exit gracefully before falling back to SIGKILL. docker rm -f sends SIGKILL immediately and removes the container. For an Nginx container sitting idle, the distinction is academic. For a Postgres container that's mid-write, it can leave you with a corrupt data file.

Rule of thumb: docker rm -f is fine for stateless workloads and dev containers you're iterating on. For anything writing to disk that you care about, stop it properly first.

Rename an existing container with docker rename

Sometimes you don't want to delete the old container, you want to keep it around under a different name. Maybe it has logs you haven't pulled yet, or it's a paused snapshot of state you'll come back to.

bash
1
docker rename web web-old

docker rename works on running, paused, and stopped containers. There's no output on success. Verify with:

bash
1
docker ps -a --filter "name=web"

Now the name web is free, and you can start a new container with it. The old container keeps its ID, its writable layer, its volumes, and its current state. Only the name changes.

One caveat: if the renamed container was created by Docker Compose, Compose won't recognize it anymore. Compose tracks containers by labels and project-prefixed names like myapp-web-1. Rename that to web-old and the next docker compose up creates a fresh myapp-web-1 next to it instead of reattaching. For Compose-managed containers, stick with docker compose rm or docker compose down.

Prevent the problem with --rm

The cleanest way to avoid name conflicts is to not create persistent containers in the first place. The --rm flag on docker run tells Docker to remove the container automatically when its main process exits:

bash
1
docker run --rm --name web -p 8080:80 nginx

When you Ctrl-C out of that container (or its process exits for any reason), Docker cleans it up. The name web is free immediately. Run the same command again and there's no conflict.

--rm is the right default for one-off commands, short-lived scripts, CI jobs, and dev containers you're iterating on. It is not appropriate for production services. There's no way to inspect what happened after an unexpected exit, because the container is gone, along with its filesystem state and any logs accessible via docker logs. For long-running services, you want the container to stick around so you can debug it. Pair --restart unless-stopped with a named container instead.

--rm and -d work together, but a detached container with --rm that crashes vanishes immediately, taking the logs and filesystem state you'd need to debug it.

When you actually wanted docker start

Before reaching for docker rm, ask whether you want to throw the old container away at all. If the answer is "I want my container back the way it was," the right command is docker start, not another docker run:

bash
1
docker start web

This brings the stopped container back to running with all its configuration, environment variables, port mappings, and writable layer intact. No docker run, no name conflict to resolve. The How to Start a Docker Container FAQ covers the run versus start distinction in more detail.

Common pitfalls

Repeating docker run when you meant docker start

The most common cause of this error is muscle memory. You run a container, stop it, and then reflexively type docker run --name web ... again expecting Docker to resume it. Docker has no way to know your intent. From its perspective, you asked it to create a new container with a name that's already taken. Either remove the old container, or use docker start web if you wanted to resume.

Force-removing a stateful container

docker rm -f on a Postgres, MySQL, or Redis container that's serving live writes can leave the on-disk state inconsistent. The data files survive because they're on a volume, but the database may need recovery on next start, or refuse to start at all. Always docker stop first for stateful workloads, and confirm the stop completed before removing.

Compose containers reappearing after rm

If you remove a container created by Docker Compose with docker rm, then run docker compose up again, Compose creates a fresh container with the same name. That's what up is supposed to do: bring the project to its declared state, which means re-creating anything missing. To avoid the surprise, use docker compose rm or docker compose down instead, which both update Compose's view of the project at the same time.

Names that come back from --restart policies

A container started with --restart always is restarted by the Docker daemon after a host reboot, even if you docker stopped it manually and didn't remove it. (--restart unless-stopped does the opposite: a manual stop sticks across reboots, which is the whole point of picking it over always.) If you see a name conflict for a container you swore you killed, run docker ps -a and remember that the restart policy outlives a stop.

The conflicting container is on a different Docker context

If docker ps -a doesn't show the conflicting container but Docker still claims the name is in use, you might be looking at the wrong daemon. Run docker context ls to see which context is active. The container could be on a remote daemon, a different Docker Desktop VM, or a Colima instance you forgot about. Switch contexts with docker context use <name> before troubleshooting further.

Final thoughts

The error message tells you what to do. Pick docker rm (or docker rm -f) when the container is disposable, docker rename when it isn't, and reach for --rm on the original docker run to stop the problem from coming back on throwaway workloads. If you wanted your old container running again, docker start is the answer.

Individual conflicts are easy to fix. Patterns over time are harder. Some host has 30 stopped containers nobody cleaned up. A service is restarting every 12 minutes and nobody noticed because docker ps only shows the latest run. A container got OOM-killed yesterday and the logs rotated before anyone pulled them. docker ps -a is a snapshot. It won't tell you that web has restarted 47 times in the last hour.

Dash0 is an OpenTelemetry-native observability platform. It ingests container telemetry as OTLP without proprietary agents, and infrastructure monitoring ties exit codes and restart counts to the logs and distributed traces from the same container, using standard OpenTelemetry semantic conventions. When a container exits, you can find out why. Start a free trial to track container exits, restarts, and OOM kills next to the application logs that explain them. No credit card required.