Skip to content
DevOps AI ToolKit
Newsletter
All guides
Docker with AI By James Joyner IV · · 8 min read

Docker Error Guide: 'volume is in use' — Cannot Remove a Volume Bound to a Container

Quick answer

Fix Docker's 'Error response from daemon: remove <vol>: volume is in use' by finding and removing the containers referencing the volume before deleting it safely.

Part of the Docker Container & Runtime Errors hub
  • #docker
  • #troubleshooting
  • #errors
  • #volumes
Free toolkit

Fixing errors like this? Get 500 free DevOps AI prompts

500 copy-paste AI prompts for the stack you actually run — one PDF, free.

Overview

Docker refuses to delete a volume that is still referenced by one or more containers — running or stopped. It appears on docker volume rm:

Error response from daemon: remove myapp_data: volume is in use - [6f3b2a1c9d4e]

When multiple containers reference the volume, all their IDs are listed:

Error response from daemon: remove myapp_data: volume is in use - [6f3b2a1c9d4e, a12f9e0b7c33]

The bracketed values are container IDs holding a reference to the volume. Docker will not remove a volume while any container — even a stopped one — still maps it, to protect you from deleting data another container expects. This is a safety guard, not a corruption error.

Symptoms

  • docker volume rm myapp_data fails with volume is in use and a list of container IDs.
  • docker volume prune skips the volume and reports it as still in use.
  • The volume persists even after you stopped the container that uses it (stopped containers still hold references).
  • docker compose down without -v leaves volumes that later cannot be removed while old containers linger.
  • Removing the volume works only after the referencing containers are deleted.

Common Root Causes

  • A stopped container still references the volume — stopping is not removing; the reference remains.
  • A running container is actively using the volume.
  • Multiple containers share the volume and all must be removed first.
  • Orphaned containers from a previous Compose project still mapping the volume.
  • A paused or created-but-never-started container holding the reference.
  • Trying to prune a named volume that is intentionally attached to a long-lived service.

Diagnostic Workflow

First, inspect the volume to confirm its name and driver:

docker volume ls
docker volume inspect myapp_data

Find every container (running or stopped) that references the volume — this is the key step:

docker ps -a --filter volume=myapp_data

You can also resolve the bracketed IDs from the error directly:

docker inspect 6f3b2a1c9d4e --format '{{.Name}} {{.State.Status}}'

List, for each container, exactly which mounts point at the volume:

docker inspect 6f3b2a1c9d4e \
  --format '{{range .Mounts}}{{.Name}} -> {{.Destination}}{{"\n"}}{{end}}'

Once you have confirmed which containers to remove and that their data is not needed, remove them and then the volume:

docker rm -f 6f3b2a1c9d4e a12f9e0b7c33
docker volume rm myapp_data

Example Root Cause Analysis

An engineer wants to reset a database and runs docker volume rm myapp_data, which fails: volume is in use - [6f3b2a1c9d4e]. The container was stopped, so they assumed it was safe. Listing all containers referencing the volume reveals the still-present stopped container:

docker ps -a --filter volume=myapp_data
# CONTAINER ID   IMAGE          STATUS                    NAMES
# 6f3b2a1c9d4e   myapp:1.4.2    Exited (0) 2 hours ago    myapp_db

The stopped container myapp_db still holds a reference, which is why Docker blocks removal. Confirming the mount destination before deleting:

docker inspect 6f3b2a1c9d4e \
  --format '{{range .Mounts}}{{.Name}} -> {{.Destination}}{{"\n"}}{{end}}'
# myapp_data -> /var/lib/postgresql/data

With the data confirmed disposable, removing the container releases the reference and the volume deletes cleanly:

docker rm myapp_db
docker volume rm myapp_data

For a Compose-managed stack, the equivalent one-shot is docker compose down -v, which removes the containers and their named volumes together.

Prevention Best Practices

  • Remember that stopping a container does not release its volume reference — you must docker rm it.
  • Use docker compose down -v to tear down a stack and its named volumes in one step when the data is disposable.
  • Name volumes clearly (myapp_data, myapp_cache) so you can tell disposable caches from precious data before deleting.
  • Back up important volumes (docker run --rm -v myapp_data:/data -v $PWD:/backup alpine tar czf /backup/data.tgz /data) before removal.
  • Clean up orphaned containers with docker compose down --remove-orphans to avoid stray references.
  • Never force-prune volumes on shared hosts without confirming which containers reference them.

Quick Command Reference

# Find every container referencing the volume
docker ps -a --filter volume=myapp_data

# Resolve a bracketed container ID from the error
docker inspect 6f3b2a1c9d4e --format '{{.Name}} {{.State.Status}}'

# See where the volume is mounted inside a container
docker inspect 6f3b2a1c9d4e \
  --format '{{range .Mounts}}{{.Name}} -> {{.Destination}}{{"\n"}}{{end}}'

# Remove referencing containers, then the volume
docker rm -f 6f3b2a1c9d4e && docker volume rm myapp_data

# Tear down a Compose stack and its volumes together
docker compose down -v

Conclusion

volume is in use is Docker’s safety guard against deleting data another container still maps — including stopped containers, which retain their references until removed. Use docker ps -a --filter volume=<name> to find every referencing container, confirm the mount and that the data is disposable, docker rm those containers, and then remove the volume. Backing up important volumes first and using docker compose down -v for disposable stacks keeps cleanup safe. For more volume fixes, see the Docker guides.

Free download · 368-page PDF

Get 500 Battle-Tested DevOps AI Prompts — Free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.