Error response from daemon: remove fix7-vol: volume is in use — a container still holds the volume, and a stopped container counts. Find it with docker ps -a --filter volume=<name>, remove that container, then remove the volume.

Two shortcuts do not work. docker volume rm -f gave the same refusal, and docker rm -v on the holder removed the container but kept the named volume and its data. Removing a named volume is always its own step.

The error

PS> docker volume rm fix7-vol
Error response from daemon: remove fix7-vol: volume is in use - [c62f819b2f6c26830d7124ae3088afad3c710c10a3c44e3efedc8c32d81a9c6d]

Why it happens

Docker will not delete a volume while any container is defined with it, running or not. A stopped container can be started again and expects its data, so it holds the volume as firmly as a running one. That is why the error surprises people: docker ps without -a lists only running containers and shows nothing, while the holder sits in the Exited list.

The long hexadecimal value in brackets is the full ID of the container that holds the volume. docker inspect fix7-volc --format '{{.Id}}' returned exactly that value in the test. In this reproduction the holder was a one-off container that wrote a file and exited; in a real project it may be a Compose service or a database container that was stopped rather than removed.

The fix

PS> docker ps -a --filter volume=fix7-vol --format 'table {{.ID}}\t{{.Names}}\t{{.Status}}'
CONTAINER ID   NAMES       STATUS
c62f819b2f6c   fix7-volc   Exited (0) Less than a second ago
PS> docker rm -v fix7-volc
fix7-volc
PS> docker volume ls --filter dangling=true --filter name=fix7-
DRIVER    VOLUME NAME
local     fix7-vol
PS> docker run --rm -v fix7-vol:/data alpine cat /data/note.txt
saved

Once the holder was gone, the volume showed up as dangling, meaning no container references it, and the file written earlier was still inside: -v did not touch the named volume. The test then mounted it in a running container, which gave the same refusal even with -f. Removing that container freed the volume: 

PS> docker volume rm -f fix7-vol
Error response from daemon: remove fix7-vol: volume is in use - [4e3ea16d6cba82e00114eb24a7193793eaf71ceda7dd8e4e6da6f34553a71ea3]
PS> docker rm -f fix7-volr
fix7-volr
PS> docker volume rm fix7-vol
fix7-vol

docker volume ls --filter dangling=true is the list of volumes you can remove without touching a container. Read it before you delete anything: a dangling volume can still be the only copy of a database whose project is simply down. The test added --filter name=fix7- so that only its own volumes were listed; drop it on your machine. For a Compose project, docker compose down removes the project's containers, which releases the volumes they held.

How it was reproduced

Docker Desktop 4.96.3 with engine 29.9.2, from Windows PowerShell 5.1, with the cached alpine:latest image. A named volume was created, a short-lived container wrote one file into it and exited, and docker volume rm ran against the stopped holder, then against a running one. Each command ran through cmd /c with 2>&1 so the error text was captured as printed. fix7-vol, fix7-volc and fix7-volr are the test's own names, all removed at the end.

Frequently asked

How do I fix 'volume is in use' in Docker?
Find the holder with docker ps -a --filter volume= and the volume name, remove that container with docker rm (add -f if it is running), then run docker volume rm again.
Why is a Docker volume in use when no container is running?
Stopped containers count. docker ps hides them and docker ps -a shows them. In the test an exited container held the volume, and the error gave its full container ID.
Does docker rm -v delete a named volume?
No. In the test it removed the container and left the named volume and its file in place. The flag is for a container's anonymous volumes; a named volume needs docker volume rm.

More decoded errors in the Fixes category. Named, anonymous and bind mounts side by side, with the clean-up for each: Files in and out: bind mounts and volumes on Windows.