FailedMount: The kubelet could not mount a volume into the pod

FailedMount is emitted when the kubelet cannot make a volume available inside the container. It covers missing ConfigMaps and Secrets, unbound claims, attach failures, and filesystem problems — the message says which.

Applies to: All Kubernetes versions

What it means

Mounting is the last step before a container starts, and FailedMount is the event the kubelet emits when it cannot complete it. The reason is always in the message, and the messages fall into a few distinct families that need completely different responses: a named ConfigMap or Secret that does not exist, a PersistentVolumeClaim that is not bound, a timeout waiting for a volume that has not attached, or a filesystem-level error from the CSI driver. Because a pod holds in ContainerCreating while this repeats, the visible symptom is a pod that never starts, with the real explanation buried a few lines into the events.

Most common causes

• A ConfigMap or Secret mounted as a volume does not exist in the pod's namespace.
• A PersistentVolumeClaim referenced by the pod is not bound to a volume.
• The underlying volume has not attached to the node, so there is nothing to mount yet.
• The volume is already mounted elsewhere with an access mode that forbids a second mount.
• A subPath that does not exist in the volume, or a subPath expansion that resolved to nothing.
• A filesystem mismatch — the volume is formatted differently from what the storage class declares.
• An NFS or SMB server that is unreachable, or credentials for it that are wrong.

How to diagnose it

1. Read the full event: kubectl describe pod POD. The message names the volume and the specific failure.
2. For a missing object, confirm it exists in the pod's namespace: kubectl get configmap,secret -n NAMESPACE.
3. For a claim, check its status: kubectl get pvc -n NAMESPACE. A claim in Pending is the cause, not a symptom.
4. For an attach problem, check the volume attachment objects: kubectl get volumeattachment.
5. Check the kubelet log on the pod's node for the underlying mount error: journalctl -u kubelet | grep -i mount.
6. For network filesystems, test reachability from the node itself rather than from inside the cluster.

How to fix it

1. Create the missing ConfigMap or Secret in the pod's namespace and delete the pod so it retries.
2. Resolve the claim — a missing StorageClass, an unavailable volume, or a quota is the usual reason a claim will not bind.
3. For access-mode conflicts, ensure only one pod uses a ReadWriteOnce volume at a time, or move to a volume type that supports multiple writers.
4. Correct the subPath, or create the path inside the volume before referencing it.
5. Fix network filesystem reachability and credentials at the node level.

Notes

The kubelet retries mounts indefinitely, so this event repeats with a rising count rather than failing the pod outright. A pod can sit in ContainerCreating for hours on a mount error that was fully diagnosable in the first ten seconds.

Related

• FailedAttachVolume — The volume could not be attached to the node
• PersistentVolumeClaim Pending — The claim has not bound to a volume

Sources

• Kubernetes documentation — Volumes
• Kubernetes documentation — Persistent Volumes
• Kubernetes documentation — Debug Pods