What does docker:volume_in_use mean?

Docker cannot remove the volume because a running or stopped container still references it, so you must detach or delete the dependent container first.

How do I prevent docker:volume_in_use in CI?

Clean up containers and volumes as part of CI teardown. Avoid sharing volumes across many long-lived containers without clear ownership.

Error response from daemon: Conflict: volume is in use

Fix it fast

Most likely: One or more containers still reference the volume, including stopped containers.

1. Confirm this is your error

Error response from daemon: Conflict: volume is in use

2. Check the cause

docker volume inspect <volume>
docker ps -a --filter volume=<volume>
docker inspect <container-id>

3. Apply the safe fix

# Stop and remove the containers that still use the volume.
docker stop <container-id>
docker rm <container-id>
docker volume rm <volume>

4. Verify it works

docker ps -a --filter volume=<volume>
docker volume rm <volume>

Don't use unsafe shortcuts

Do not use docker volume prune on a shared machine until you know what data it will remove.
Do not remove a named volume before confirming it is not holding database or application state you need.
Do not check only running containers, stopped containers can still keep a volume referenced.

What Local Operation Failed

The remote service may be fine. This class of error is usually about what the local machine was allowed to read, write, cache, or execute.

Free the resource that is still in use

Find containers using the resource:docker ps -a (then inspect mounts as needed).

Stop/remove the container(s), then retry removal.

If the daemon is stuck, restart Docker and retry.

Manual cleanup checklist

Print the current user, working directory, and relevant cache path so you know which filesystem location is actually failing.

Check ownership, permissions, and free space on the affected path directly with ls -la <path> and df -h.

If this only happens in CI or containers, inspect mounted volumes and cache restores, because stale ownership and read-only mounts are common causes.

Why the Local Machine Blocked It

Usually this comes down to a running container is still using the volume/filesystem layer, a previous container left a stale mount or a stuck process, or the host OS is holding file locks (more common on desktop environments).

Verify the Local Path Is Usable Again

Retry the remove command and confirm it succeeds, and confirm the resource no longer appears in docker volume ls / docker ps -a.

How Docker manages resources

Docker got far enough to read or write local state, but the host filesystem blocked the operation. Ownership drift, read-only mounts, stale caches, full disks, and restrictive permissions all show up in this layer. These are usually local machine or runner problems rather than upstream service problems, so fix the path, ownership, or free space before changing dependency versions.

Prevent Local State Drift

To prevent this, clean up containers and volumes as part of CI teardown, and avoid sharing volumes across many long-lived containers without clear ownership.