timeout expired waiting for volumes to attach or mount: The kubelet gave up waiting for a volume and will retry

This message means the kubelet waited its allotted time for volumes to become usable and they did not. It names the volumes it is still waiting for, which is the fastest route to the real cause.

Applies to: All Kubernetes versions

What it means

Before starting containers, the kubelet waits for every volume to be attached and mounted. When that wait exceeds its internal timeout, it logs Unable to attach or mount volumes: unmounted volumes=[…], unattached volumes=[…]: timed out waiting for the condition and tries again. The message is more useful than it first appears because of those two lists: a volume in unattached means the attach stage never completed, which points at the storage backend or the attach-detach controller, while a volume in unmounted means it attached but the mount failed, which points at the node, the filesystem, or a missing ConfigMap or Secret.

Most common causes

• The underlying attach failed or is slow, which will also show as FailedAttachVolume.
• A referenced ConfigMap or Secret does not exist, so its volume never becomes ready.
• A network filesystem server is unreachable from the node.
• The CSI node plugin is not running on the node.
• The volume is still attached to another node.
• The storage backend is slow enough under load that attach exceeds the timeout, then succeeds on a later retry.

How to diagnose it

1. Read which volumes are named in the message: kubectl describe pod POD. The two lists separate attach problems from mount problems.
2. For unattached volumes, check kubectl get volumeattachment and the attach-detach controller.
3. For unmounted volumes, check that every referenced ConfigMap and Secret exists in the namespace.
4. Check the CSI node plugin on that node: kubectl get pods -n kube-system -o wide | grep NODE.
5. Check the kubelet log for the underlying error, which is more specific than the timeout: journalctl -u kubelet.

How to fix it

1. Resolve whichever underlying problem the lists point at — the timeout itself is a symptom and not the thing to fix.
2. Create missing ConfigMaps and Secrets, then delete the pod so it retries promptly.
3. Restore the CSI node plugin if it is absent.
4. For a genuinely slow backend, the retry usually succeeds; if it does not, the problem is not slowness.
5. Ensure the pod holding the volume on another node has fully terminated.

Notes

This message is a wrapper around a more specific failure that has usually already been emitted as its own event. Scrolling up in the event list is almost always more productive than acting on the timeout.

Related

• FailedMount — A volume could not be mounted into the pod
• ContainerCreating — The kubelet is still preparing the container

Sources

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