🦭 Podman Error: 'container has dependent containers which must be removed before it'

Exact Error Message

Error: container 6f2a1c9d4b3e7a58f0c2d1e9b8a7654321fedcba0987654321abcdef01234567
has dependent containers which must be removed before it:
9a8b7c6d5e4f3210fedcba9876543210abcdef1234567890abcdef1234567890:
container already exists

Adding -f does not change the outcome, and the pod case reads slightly differently:

Error: removing container 6f2a1c9d4b3e (infra) from pod web-stack:
container 9a8b7c6d5e4f has dependent containers which must be removed before it

What It Means

Podman tracks explicit dependency edges between containers, not just the loose coupling Docker users may be used to. When one container joins another container’s namespace — its network, IPC, PID, UTS, or cgroup namespace — the joining container cannot function if the target disappears. Podman records that relationship in its database and refuses to remove the target while any dependent still exists, because doing so would leave a container pointing at a namespace that no longer has an owner.

The most common source of these edges is a pod. Every Podman pod has an infra container that owns the shared namespaces; every other container in the pod depends on it. That is why removing the infra container directly always fails while ordinary members are still around. The second source is manual namespace sharing: --network container:web, --pid container:app, --ipc container:cache, and --uts container:web each create the same kind of edge. Crucially, podman rm -f only forces a stop before removal — it does not force removal of dependents, so force alone never resolves this error. You either remove the dependents first, or ask Podman to walk the graph for you with --depend.

Common Causes

• Trying to remove a pod’s infra container while other containers in the pod still exist.
• A sidecar started with --network container:<name> sharing the primary container’s network namespace.
• A debug or exec-helper container attached with --pid container:<name> and never cleaned up.
• Containers sharing IPC via --ipc container:<name> for shared-memory workloads such as databases or CUDA jobs.
• --uts container:<name> used to keep a consistent hostname across a group of containers.
• Kubernetes-style YAML played with podman kube play, which creates a pod and therefore an infra container plus dependents.

Diagnostic Commands

List every container including stopped ones, since dependents that are exited still block removal:

podman ps -a
podman ps -a --pod

Filter to the pod that owns the container you are trying to remove:

podman ps -a --filter pod=web-stack --format '{{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Pod}}'

Ask Podman directly which containers depend on the one you are removing:

podman inspect --format '{{.Dependencies}}' 6f2a1c9d4b3e

Find sidecars sharing a namespace by inspecting the namespace mode of every container:

podman ps -aq | xargs -r podman inspect \
  --format '{{.Name}} net={{.HostConfig.NetworkMode}} pid={{.HostConfig.PidMode}} ipc={{.HostConfig.IpcMode}} uts={{.HostConfig.UTSMode}}'

Confirm whether the container is an infra container at all, which decides whether you should be using podman pod rm:

podman inspect --format '{{.IsInfra}} {{.Pod}}' 6f2a1c9d4b3e

Step-by-Step Resolution

1. Identify the blocking dependents by ID. The error message lists them, but inspect gives you the full set in one place:

podman inspect --format '{{.Dependencies}}' 6f2a1c9d4b3e

2. If the container belongs to a pod, do not remove containers individually — remove the pod, which tears down members and the infra container in the correct order:

podman pod ps
podman pod rm -f web-stack

3. If it is not a pod but a manual namespace share, let Podman walk the dependency graph and remove the target together with everything that depends on it:

podman rm --depend 6f2a1c9d4b3e

4. To remove dependents deliberately instead — for example when you want to keep the primary running — stop and remove the sidecars first, then the target:

podman rm -f 9a8b7c6d5e4f
podman rm -f 6f2a1c9d4b3e

5. If you inherited a tangle of stopped containers with no idea which shares what, clear all stopped containers and then retry, which resolves most cases without hand-tracing edges:

podman container prune
podman ps -a

6. Verify the container and any pod are gone, and that no orphaned namespace owner remains:

podman ps -a --filter id=6f2a1c9d4b3e
podman pod ps
podman system df

Rootless users hit this most often through podman kube play, because a single YAML file quietly creates a pod plus an infra container. The matching teardown is podman kube down, which removes the pod as a unit and avoids the dependency error entirely. If you generated systemd or Quadlet units from a pod, remove the units too — otherwise the service will recreate the pod behind you and it will look like removal silently failed; see Podman error: Quadlet unit failed to start for how those units are wired.

Prevention

• Manage grouped containers as pods and tear them down with podman pod rm, never container by container.
• For podman kube play workloads, always use podman kube down -f <file> so the pod and infra container are removed together.
• Name sidecars with a shared prefix (app, app-proxy, app-logs) so dependency groups are obvious in podman ps -a.
• Prefer podman rm --depend in cleanup scripts instead of retry loops around plain podman rm -f.
• Run podman container prune on a schedule so stopped dependents do not accumulate and block later removals.
• Document namespace sharing in your compose or Quadlet files rather than passing --network container: ad hoc on the command line.

Related Errors

• container already exists on create — a stopped container with the same name is still present; remove it or use --replace.
• no such container — the dependent was already removed and your ID or name is stale.
• cannot connect to Podman socket — a tooling or service problem rather than a dependency graph issue; see Podman error: cannot connect to Podman socket.
• netavark: IO error — network backend failure when creating or removing a shared network namespace; see Podman error: netavark IO error.

Frequently Asked Questions

Why doesn’t podman rm -f work here? -f forces a stop of a running container before removal. It says nothing about dependents, and Podman will not silently orphan a container whose namespace owner you are deleting. Use --depend to force removal of the whole dependency chain instead.

Is podman rm --depend safe to script? It is, but understand its blast radius: it removes every container transitively depending on the target, which for an infra container means the whole pod. In automation, log podman inspect --format '{{.Dependencies}}' first so the removal set is recorded.

Why can’t I remove the infra container to “free up” a pod? The infra container owns the pod’s shared namespaces by design; removing it while members exist would break them. Podman intentionally blocks this. Remove the pod with podman pod rm -f, or remove members first if you are rebuilding the pod in place.

Do stopped containers still count as dependents? Yes. Dependency edges live in Podman’s database, not in the running process tree, so an exited sidecar blocks removal exactly like a running one. podman container prune is the quickest way to clear that class of blocker. For more container-runtime fixes, see the Podman guides.