Docker Error Guide: 'volume is in use' — Cannot Remove a Volume Bound to a Container
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.
- #docker
- #troubleshooting
- #errors
- #volumes
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_datafails withvolume is in useand a list of container IDs.docker volume pruneskips 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 downwithout-vleaves 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 rmit. - Use
docker compose down -vto 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-orphansto 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.
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.