snapshot already exists: containerd's snapshotter has leftover state for a container that no longer exists
containerd builds each container's writable layer as a snapshot. A leftover snapshot from a container that was removed uncleanly blocks the new one from being created.
Applies to: Clusters using containerd
What it means
containerd's snapshotter manages the layered filesystem each container runs on, creating a writable snapshot per container and removing it on cleanup. When that cleanup does not complete — the runtime restarted mid-operation, the node lost power, the filesystem returned an error — the snapshot remains, and creating a container with the same identity fails because the snapshot key is taken. The pod stays in ContainerCreating while the kubelet retries against a state that will not resolve on its own. Like several other node-level runtime problems, this affects one node and looks like an application failure until you notice the pod runs fine elsewhere.
Most common causes
- An unclean shutdown of containerd or of the node.
- A snapshot removal that failed because of a filesystem error.
- Disk pressure preventing cleanup from completing.
- A snapshotter mismatch after a containerd configuration change.
- Corruption in containerd's metadata database.
- Interrupted image pulls leaving partial snapshots behind.
How to diagnose it
- Read the error in the pod's events, which names the snapshot key.
- List snapshots on the node with containerd's own tooling and look for the orphan.
- Check containerd's log for the earlier failed cleanup:
journalctl -u containerd. - Check disk space, since cleanup failures are frequently caused by a full filesystem.
- Check whether the node restarted uncleanly around the time the problem started.
How to fix it
- Remove the orphaned snapshot on the node using containerd's tooling.
- Free disk space so cleanup can complete.
- Restart containerd, which resolves some transient inconsistencies.
- Drain and replace the node if the metadata database is genuinely corrupted — repairing it in place is not reliable.
- Delete and recreate the pod so it takes a new identity, if the specific key cannot be cleared.
Notes
Because this is node-local, the fastest mitigation is often to get the pod scheduled elsewhere — cordon the node, delete the pod, and investigate the node separately rather than while a workload is waiting on it.
Related
- failed to reserve container name — A container with that name already exists
- DiskPressure — The node is low on disk or inodes
Sources
- containerd — Getting Started
- containerd CRI plugin configuration
- Kubernetes documentation — Debugging Kubernetes nodes with crictl