🦭 Podman Error: 'volume is being used by the following container(s)' on volume rm

Exact Error Message

$ podman volume rm pgdata
Error: volume pgdata is being used by the following container(s): 4f2c9a1b8e77,
9d13ca70bb42: volume is being used

During a bulk cleanup you may instead see it wrapped by prune:

$ podman volume prune
WARNING! This will remove all volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Error: volume appcache is being used by the following container(s): 1b7f0c22de91: volume is being used

What It Means

Podman tracks a reference from every container to each named volume it mounts, and that reference lives in the container’s record in the local storage database — not in the running process. Removing a volume while any container record still names it would leave a dangling mount definition, so Podman refuses. The critical detail is that the reference survives the container stopping: a container in Exited or Created state still holds its volume just as firmly as a running one, because the record has not been deleted.

This is why the error so often appears “impossible” — podman ps shows nothing, the workload is clearly down, yet the volume will not go. podman ps without -a hides exactly the stopped containers that are causing the problem. The same applies to pods: an infra container inside a stopped pod is a real container record and will keep a volume alive, and systemd- or Quadlet-managed units can recreate a holder within seconds of you removing it, making the reference look like it never disappeared.

Common Causes

• A stopped-but-not-removed container still holds the reference; podman ps hides it without -a.
• A pod’s infra container or a sibling container in the same pod mounts the volume.
• A Quadlet .container unit (or a plain systemd service running podman run) restarts and recreates the holder immediately after removal.
• The volume is mounted by a container created from a podman kube play manifest that is still deployed.
• An anonymous volume was promoted or reused, so the name you see maps to a container you did not expect.
• A build or a one-shot --rm container crashed before cleanup, leaving an orphaned record behind.

Diagnostic Commands

Start by listing volumes and confirming the exact name — trailing whitespace and prefixing from compose projects are common surprises:

podman volume ls
podman volume ls --format '{{.Name}}\t{{.Driver}}\t{{.Mountpoint}}'

Ask Podman directly which containers reference the volume. The volume filter accepts a volume name and matches container records regardless of state:

podman ps -a --filter volume=pgdata
podman ps -a --filter volume=pgdata --format '{{.ID}}\t{{.Names}}\t{{.State}}'

Inspect the volume itself for its mountpoint, driver options, and labels — the labels often reveal which compose project or Quadlet unit created it:

podman volume inspect pgdata

For rootless Podman, the on-disk data lives under your home directory, not /var/lib/containers. Confirm the path before you delete anything you cannot recreate:

ls -la ~/.local/share/containers/storage/volumes/pgdata/_data
du -sh ~/.local/share/containers/storage/volumes/*

If a holder keeps reappearing, look for a systemd unit that owns it:

systemctl --user list-units 'podman*' '*.service' | grep -i pgdata
ls ~/.config/containers/systemd/

Step-by-Step Resolution

1. Identify every container holding the volume, including stopped ones:

podman ps -a --filter volume=pgdata --format '{{.ID}} {{.Names}} {{.State}}'

2. Stop and remove the holders. Use -v on podman rm when you also want the container’s anonymous volumes cleaned up in the same step:

podman stop 4f2c9a1b8e77 9d13ca70bb42
podman rm -v 4f2c9a1b8e77 9d13ca70bb42

3. If a systemd or Quadlet unit keeps recreating the holder, stop the unit first — otherwise the container returns before you can delete the volume:

systemctl --user stop database.service
systemctl --user list-timers --all | grep -i database

For a Quadlet-managed stack, the .volume unit itself may also be re-creating the volume on demand:

# ~/.config/containers/systemd/pgdata.volume
[Volume]
VolumeName=pgdata

Disable the consuming .container unit and reload before retrying:

systemctl --user disable --now database.service
systemctl --user daemon-reload

4. Remove the volume. podman volume rm -f removes the volume and forcibly removes the containers that use it — it is not a “skip the check” flag, so use it only when destroying those containers is acceptable:

podman volume rm pgdata
# or, when you accept that the holding containers are destroyed too:
podman volume rm -f pgdata

5. Clean up unused volumes in bulk once the holders are gone. podman volume prune removes only volumes with no container references:

podman volume prune
podman volume prune --filter label=project=legacy

6. For a full reclaim including volumes, images, and networks, use system prune with the explicit opt-in flag, then verify:

podman system prune --volumes
podman volume ls

For generating cleanup and lifecycle scripts around named volumes, the Podman prompts in the prompt library can produce a reviewed teardown routine.

Prevention

• Always create containers with --rm for one-shot work so records never linger to hold volumes.
• Prefer named volumes over anonymous ones so ownership is obvious in podman volume ls.
• Use podman rm -v as your default removal habit to clear anonymous volumes with the container.
• Label volumes at creation (podman volume create --label project=app pgdata) so prune --filter can target them safely.
• Stop the owning systemd or Quadlet unit before manual cleanup rather than fighting its restart policy.
• Keep data you care about on an explicit host bind mount or a backed-up named volume, never on an anonymous one.

Related Errors

• Error: no such volume — the name is wrong or the volume was already removed; check podman volume ls for compose-style prefixes.
• Error: pod already exists — a pod record is still present, a sibling situation covered in pod already exists.
• no space left on device — storage exhaustion rather than a reference problem; see no space left on device.
• Error: unable to start container: container state improper — the container record exists but is mid-transition; stop it before removing.

Frequently Asked Questions

Why does podman ps show nothing but the volume is still in use? podman ps lists running containers only. Stopped and created containers still hold volume references, so you must use podman ps -a --filter volume=NAME to see the real holders.

Does podman volume rm -f just skip the safety check? No. It force-removes the containers using the volume as well as the volume itself. Treat it as a destructive operation on those containers, not as a way to bypass validation.

How do I get rid of anonymous volumes? Remove their containers with podman rm -v, then run podman volume prune. Anonymous volumes appear as long hex names in podman volume ls and are only reachable through the container that created them.

Why does the holder come back seconds after I remove it? A systemd unit — often a Quadlet .container file in ~/.config/containers/systemd/ — is restarting it. Stop and disable that unit first. For related rootless systemd session issues see crun sd-bus transport endpoint.