Error response from daemon: remove mydata: volume is in use

Not specified by the original author.

TL;DR: Find the container holding the volume (docker ps -a --filter volume=mydata), remove it (docker rm), then docker volume rm mydata succeeds. Stopped containers keep their volume references, so docker stop is not enough.

The error

Error response from daemon: remove mydata: volume is in use - [c3d4e5f6...]

Fix it

1. Find the referencing containers: docker ps -a --filter volume=mydata Expected: one or more containers, possibly exited.

2. Remove them (add -f if running and you are sure): docker rm [container] Expected: no output.

3. Remove the volume: docker volume rm mydata Expected: prints mydata.

When this applies

• docker volume rm / docker volume prune skipping a volume
• Rebuilding stateful dev environments

When this does NOT apply

• Anonymous volumes (they have hex IDs; same fix, filter by the ID)
• "No such volume" (already gone)

Versions

All Docker versions.

Why it happens

Volumes are reference-counted. Any container created with the volume, running or stopped, holds a reference until the container itself is removed. Prune only removes truly unreferenced volumes.

Edge cases

• docker rm -v removes anonymous volumes attached to the container at removal time; named volumes survive unless explicitly removed.
• Compose down -v removes the project's named volumes; plain down keeps them, which is why the next up sees old data.
• A container stuck in removal holds the reference; restart the daemon to clear it.

Asked: how to fix Error response from daemon: remove mydata: volume is in use. Verified answer: Fixes 'volume is in use' when removing a docker volume. Use when docker volume rm fails because a container (even stopped) references the volume. The fix steps above were cross-checked against the accepted community answer at https://stackoverflow.com/questions/56865625 (so:56865625), which confirms the same resolution.

Not specified by the original author.

docker "Error response from daemon: Conflict. The container name is already in use"

TL;DR: A stopped container with that name still exists. Remove it with docker rm [name], or run one-off containers with --rm so they delete themselves. In CI, add a cleanup step before the run so one failed build does not poison the next.

Error response from daemon: Conflict. The container name "/web" is already in use by container "a1b2c3d4e5f6"

Steps

1. List it: docker ps -a --filter name=[name]. Confirm the stale container and whether it is running or exited.

Expected: You see the conflicting container and its state.

2. If it is exited and disposable, remove it and rerun:

docker rm [name]

Expected: The next docker run --name [name] starts clean.

3. If it is running and should not be, stop it first, then remove it. If it should be running, you have two things fighting over one name; rename one of them.

Expected: The name is free, or the real owner is identified.

4. Prevent recurrence for one-off runs: add --rm so finished containers delete themselves.

Expected: No stale containers accumulate between runs.

5. In CI, add a pre-step that removes any container with the job's name, or generate a unique name per run from the build id.

Expected: Name conflicts stop flaking the pipeline.

6. Compose users: docker compose down removes the project's containers. Conflicts across compose projects mean two projects share a name; give them distinct project names with -p.

Expected: Clean slate, no cross-project collision.

Use this when

• docker run --name X fails with the Conflict message

Not for this skill when

• The error is port is already allocated. That is a port conflict, same family but a different resource
• The error is unable to delete ... image is being used. That is an image reference conflict, not a name
• The daemon is down. Nothing runs at all

Variant phrasings

Conflict. The container name "/name" is already in use by container "abc123"

The full form of the error with both names shown.

Why it happens

Container names are unique per daemon, and stopped containers keep their names until removed. A crashed or interrupted run leaves the name claimed, so the next identical run collides with the leftover of the last one.

Edge cases

• --rm and --name work fine together; the container is removed when it exits
• docker rm -f handles stuck containers that ignore a plain stop
• Two compose projects in directories with the same name share a default project name and will fight; -p fixes it permanently

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vEqb8Blbe0xtYwdVVXVgQQ

Resolved from the public thread: https://vectle.com/posts/pst_vEqb8Blbe0xtYwdVVXVgQQ

Thread query: docker "Error response from daemon: Conflict. The container name is already in use"

TL;DR:

Not specified by the original author.

Fix service "db" refers to undefined volume "dbdata": invalid compose project (docker-compose)

TL;DR

The service mounts a named volume that is missing from the top-level volumes: section. Add the volume name under top-level volumes: (an empty entry is enough). Bind mounts and bare paths never need this, only named volumes.

The error, verbatim:

service "db" refers to undefined volume "dbdata": invalid compose project

Steps

1. Confirm which volume is undeclared:

   docker compose config

   Success check: The error names the exact service and volume.

2. Declare the volume at the top level of the compose file:

   grep -n -A5 "^volumes:" docker-compose.yml

   Success check: dbdata: now appears under top-level volumes:.

3. Re-validate and bring the stack up:

   docker compose config

   Success check: The parsed file prints with no errors.

When to use

You hit this exact error while using docker-compose. The trigger list below matches your situation.

When NOT to use

If the error text differs, or the failure is in a different tool (e.g. a Docker daemon error when you only need the compose fix), find the skill for that exact error instead.

Tool compatibility

docker-compose v1 and Compose v2. Any OS.

Variant phrasings

refers to undefined volume

invalid compose project

Root cause

The service mounts a named volume (a bare name like dbdata:/var/lib/db), but the name is never declared in the top-level volumes: section. Compose treats undeclared named volumes as a project error rather than silently creating an empty volume under a possibly-misspelt name.

Edge cases

• Bind mounts (./data URIs/data, /abs/path:/x) and bare container paths (/data) need no declaration; only bare names do.
• A misspelled name on either side triggers this: the volume gets created under the misspelt name on older versions.
• With extends:, top-level volumes: are NOT inherited; each entry-point file must declare the volume.

Where this came from

Resolved from the public discussion at https://stackoverflow.com/questions/69867166 (so:69867166).

A user hit the docker-compose error "service "db" refers to undefined volume "dbdata": invalid compose project" (docker compose fails with service refers to undefined volume). The accepted resolution: The service mounts a named volume that is missing from the top-level volumes: section. Add the volume name under top-level volumes: (an empty entry is enough). Bind mounts and bare paths never need this, only named volumes. Source: https://stackoverflow.com/questions/69867166 (so:69867166).