How to Fix Kubernetes MountVolume.SetUp Failed

MountVolume.SetUp failed means the kubelet could not prepare a declared volume for a pod. The event text usually identifies whether the source is a missing Secret or ConfigMap, an unbound PVC, a CSI driver failure, a permissions problem, or a node-specific mount error.

Preserve the exact event

kubectl describe pod POD -n NAMESPACE
kubectl get events -n NAMESPACE --sort-by=.lastTimestamp
kubectl get pod POD -n NAMESPACE -o wide

Record the volume name, node, timestamp, and full failure message. Related event reasons include FailedMount, FailedAttachVolume, and FailedMapVolume; each represents a different stage.

Do not delete the pod before preserving its events. A replacement scheduled to the same conditions often fails identically while useful evidence ages out.

Match volume declarations and mounts

Inspect the effective pod specification:

kubectl get pod POD -n NAMESPACE -o yaml

Confirm that every volumeMount.name matches an entry under spec.volumes. Check mountPath, subPath, readOnly, projected items, and container names. A subPath target must exist in the volume and can introduce behavior different from mounting the whole volume.

If a controller owns the pod, inspect and fix its pod template rather than the generated pod:

kubectl get pod POD -n NAMESPACE \
  -o jsonpath='{range .metadata.ownerReferences[*]}{.kind}{"/"}{.name}{"\n"}{end}'

Check Secrets and ConfigMaps

For a referenced Secret, inspect only metadata and key names:

kubectl get secret SECRET -n NAMESPACE
kubectl get secret SECRET -n NAMESPACE \
  -o jsonpath='{range $k,$v := .data}{$k}{"\n"}{end}'

For a ConfigMap:

kubectl get configmap CONFIGMAP -n NAMESPACE
kubectl describe configmap CONFIGMAP -n NAMESPACE

Both resources must exist in the pod’s namespace, and each key listed under items must exist unless the source is intentionally optional. Avoid decoding or printing secret values during routine diagnosis.

Inspect PVC and PV state

kubectl get pvc -n NAMESPACE
kubectl describe pvc CLAIM -n NAMESPACE
kubectl get pv

Confirm the claim is Bound, the StorageClass is correct, and capacity and access modes match the workload. Review whether the volume supports the requested topology and simultaneous attachment pattern.

ReadWriteOnce usually restricts a volume to one node, not necessarily one pod. A stale attachment to another node can produce an attach failure before setup begins.

Check the CSI driver

Identify the driver from the PV and inspect its controller and node components:

kubectl get pv PV -o yaml
kubectl get csidriver
kubectl get pods -A -o wide | grep -i csi

Then read recent logs for the driver pod on the affected node and any relevant controller component. Look for authentication failures, missing topology, volume-not-found errors, timeouts, and unsupported mount options.

Do not restart every CSI pod as an initial response. Determine whether the failure affects one volume, one node, one zone, or the whole driver first.

Compare nodes and permissions

If the same volume or workload succeeds on other nodes, inspect the affected node:

kubectl describe node NODE
kubectl get pods -A -o wide --field-selector spec.nodeName=NODE

Using an approved node access path, check kubelet logs and the required mount helper for the filesystem or network storage. Host firewall, DNS, credentials, SELinux, AppArmor, and stale mount state can all affect node-side setup.

For volumes that mount successfully but fail inside the container, review runAsUser, runAsGroup, fsGroup, ownership, and the storage driver’s permission behavior. That is often a container access problem rather than MountVolume.SetUp itself.

Fix the declared source

For Helm- or GitOps-managed workloads, correct the chart values or repository manifest. Avoid creating empty placeholder resources just to move past the mount error; the application may start with missing or unsafe configuration.

Review the proposed diff before applying changes to volume names, claims, access modes, Secrets, ConfigMaps, mount options, or security context.

Diagnose it with Rumus

Diagnose this Kubernetes MountVolume.SetUp failed event. Preserve the exact volume,
node and message; inspect pod volume and volumeMount references, Secret and ConfigMap
key metadata without exposing values, PVC/PV binding, StorageClass, access modes,
CSI controller and node health, topology, node and kubelet events, mount helpers,
and security context. Start read-only and do not delete pods, detach volumes,
restart CSI components, or edit resources without approval.

Confirm the fix

Watch the replacement or updated pod:

kubectl get pod POD -n NAMESPACE -w
kubectl describe pod POD -n NAMESPACE
kubectl get events -n NAMESPACE --sort-by=.lastTimestamp

Confirm the mount event stops recurring, the pod becomes ready, the application can read or write only as intended, and the fix survives the next rollout and GitOps or Helm reconciliation.