Fix MountVolume.SetUp failed for volume: mount failed exit status 32 in Kubernetes

TL;DR

You have a Pod stuck in ContainerCreating with this in the events:

MountVolume.SetUp failed for volume "my-pv" : mount failed: exit status 32

This usually boils down to one of three things. The volume is still attached to a dead or terminating node (Multi-Attach). A filesystem utility is missing on the node — e2fsck, xfs_repair, or similar. Or there's a stale mount left over from a previous Pod. Check which node the old Pod ran on first, then work outward from there.

Read the full error before doing anything

Run this immediately to get the real error chain:

kubectl describe pod <pod-name> -n <namespace>

Scroll to the Events section. You'll usually see one of these patterns:

Multi-Attach error for volume ... Volume is already exclusively attached to one node
mount failed: exit status 32 — filesystem tools missing or corrupted
Unable to attach or mount volumes: unmounted volumes=[my-pv] — PVC still bound to old node
Output: mount: /var/lib/kubelet/pods/.../mount: can't read superblock — corrupted volume

Which pattern you're hitting determines what to fix.

Cause 1: Multi-Attach — volume still locked to another node

A node crashes or gets cordoned. The old Pod never cleanly terminated. Now the new Pod lands on a different node — but AWS EBS or GCE PD only allows one attachment at a time. Kubernetes won't forcibly detach the volume until it's sure the old node is gone.

# Check which node currently has the PV attached
kubectl get pv <pv-name> -o jsonpath='{.spec.nodeAffinity}'

# Check VolumeAttachment objects
kubectl get volumeattachment

# Find the old Pod that still has the claim
kubectl get pods --all-namespaces -o wide | grep <pvc-name>

If the old Pod is stuck in Terminating:

# Force delete the stuck Pod — only do this if the node is confirmed dead/replaced
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0

If the VolumeAttachment itself is orphaned (the node is already gone):

# List stale VolumeAttachments
kubectl get volumeattachment

# Delete the orphaned one
kubectl delete volumeattachment <attachment-name>

Wait 30–60 seconds after deletion. The new Pod should start mounting.

Cause 2: Missing filesystem utilities on the node

exit status 32 from mount is the kernel saying it doesn't have what it needs. The module or userspace tool for the filesystem isn't installed. This catches a lot of people after an OS upgrade or when using minimal node images — a fresh Ubuntu 22.04 minimal install, for example, doesn't ship with xfsprogs out of the box.

# SSH into the affected node
ssh <node-ip>

# Check what filesystem the PV uses — get this from kubectl first
kubectl get pv <pv-name> -o jsonpath='{.spec.csi.fsType}'

# On the node, verify the tool exists
which mkfs.ext4
which mkfs.xfs
which mount.nfs  # for NFS volumes

Install whatever's missing:

# Debian/Ubuntu
apt-get install -y e2fsprogs xfsprogs nfs-common

# RHEL/CentOS/Amazon Linux
yum install -y e2fsprogs xfsprogs nfs-utils

After installing, kubelet retries automatically. If it doesn't pick up within a minute, delete the Pod to force a new mount attempt:

kubectl delete pod <pod-name> -n <namespace>

Cause 3: Stale mount point or corrupted filesystem

A previous failed mount can leave a ghost entry that blocks new attempts. Check the node directly:

# Find leftover mounts for the volume
cat /proc/mounts | grep <pv-name>
# or by PVC UID
ls /var/lib/kubelet/pods/ | xargs -I{} ls /var/lib/kubelet/pods/{}/volumes/

Found a stale entry? Clean it up:

# Unmount the stale path
umount -l /var/lib/kubelet/pods/<pod-uid>/volumes/<plugin>/<pv-name>

# Then restart kubelet to clean state
systemctl restart kubelet

Corrupted ext4 or xfs filesystem? Detach the volume from the node first via your cloud console, then run the appropriate repair tool:

# For ext4
e2fsck -f /dev/<device>

# For xfs
xfs_repair /dev/<device>

Cause 4: PVC access mode mismatch

Running multiple Pod replicas with a ReadWriteOnce (RWO) volume across different nodes? That won't work. RWO means one node, period.

kubectl get pvc <pvc-name> -o jsonpath='{.spec.accessModes}'

Your options:

Switch to a storage class that supports ReadWriteMany — NFS, AWS EFS, and CephFS all handle this
Pin all Pods sharing the PVC to the same node using nodeSelector or podAffinity
If RWX isn't available, drop down to replicas: 1 on the Deployment

Cause 5: CSI driver not running on the target node

# Check if the CSI node plugin is healthy on the affected node
kubectl get pods -n kube-system -o wide | grep csi

# Look at logs from the CSI node DaemonSet pod on that node
kubectl logs -n kube-system <csi-node-pod> -c <csi-driver-container>

If the CSI pod is in CrashLoopBackOff or simply absent from that node, nothing else matters — the volume can't mount until the driver is healthy. Fix the CSI issue first, then come back to the Pod.

Verification

# Watch Pod events in real time
kubectl get events -n <namespace> --watch --field-selector involvedObject.name=<pod-name>

# Confirm Pod transitions to Running
kubectl get pod <pod-name> -n <namespace> -w

# Verify the volume is mounted inside the container
kubectl exec -it <pod-name> -n <namespace> -- df -h
kubectl exec -it <pod-name> -n <namespace> -- ls <mount-path>

Pod hits Running and df -h shows the volume at the expected path? Mount issue resolved.

Prevention

Set terminationGracePeriodSeconds high enough for Pods to cleanly release volumes — 60–120 seconds is a reasonable baseline for database workloads
Add PodDisruptionBudgets to control rolling behavior and prevent detach race conditions during node drains
Use StatefulSet for stateful workloads on block storage — it manages volume lifecycle far more reliably than Deployment
Keep CSI drivers updated; driver releases frequently include mount reliability fixes