How to fix MountVolume.SetUp failed: volume not found in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 5, 2025· 125 views

This error occurs when a pod references a volume that doesn't exist, typically due to a deleted PersistentVolume, unbound PVC, or failed dynamic provisioning.

Quick fix

Fixes MountVolume.SetUp failed: volume not found

kubectl get pvc -n <namespace>
  1. Check PVC status
  2. Check PV status
  3. Verify storage class exists
  4. Fix Released PV with stale claimRef
kubernetes — error
kubectl get pvc -n <namespace>
MountVolume.SetUp failed: volume not found

What this error means

The "volume not found" error indicates that the kubelet is trying to mount a volume for your pod, but the referenced storage resource doesn't exist or cannot be accessed. This happens after pod scheduling but before the container can start. Unlike attachment failures (which involve cloud provider operations), this error means the volume object itself is missing or in an invalid state. The PersistentVolume may have been deleted, the PVC may not be bound, or dynamic provisioning may have failed silently. This is a fundamental problem—the storage your pod needs simply isn't there.

Typical symptoms

  • Pod stuck in ContainerCreating state
  • kubectl describe pod shows "volume not found" error
  • PVC shows Pending instead of Bound status
  • PV shows Released status with stale claimRef
  • Storage class provisioner logs show errors

Common causes

  1. PersistentVolume was deleted while PVC still references it
  2. PVC not bound to any PV (stuck in Pending)
  3. Dynamic provisioning failed (quota exceeded, provisioner error)
  4. Storage class does not exist or is misconfigured
  5. PV in Released state with stale claimRef from deleted PVC

How to fix "MountVolume.SetUp failed: volume not found"

1Check PVC status

Verify the PVC exists and is bound:

bash
kubectl get pvc -n <namespace>

Expected output shows Bound status:

bash
NAME      STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS
my-pvc    Bound    pv-xxx    10Gi       RWO            standard

If status is Pending, the PVC hasn't found a matching PV.

2Check PV status

View PersistentVolumes and their states:

bash
kubectl get pv

Look for:
- Available: Can be bound to a PVC
- Bound: Attached to a PVC
- Released: PVC was deleted but PV retains data
- Failed: Reclamation failed

3Verify storage class exists

Check that the storage class referenced by the PVC exists:

bash
# List storage classes
kubectl get storageclass

# Check PVC's requested storage class
kubectl get pvc <pvc-name> -o jsonpath='{.spec.storageClassName}'

If the storage class doesn't exist, create it or update the PVC.

4Fix Released PV with stale claimRef

If a PV is in Released state and you want to reuse it:

bash
# Clear the claimRef to make PV available again
kubectl patch pv <pv-name> -p '{"spec":{"claimRef": null}}'

The PV will transition to Available and can be bound to a new PVC.

Warning: This may expose data from the previous claim.

5Check provisioner logs

For dynamic provisioning failures, check the CSI driver or provisioner logs:

bash
# Find the provisioner pods
kubectl get pods -n kube-system | grep -E 'csi|provisioner'

# Check logs
kubectl logs -n kube-system <provisioner-pod> --tail=100

Look for quota errors, permission issues, or backend connectivity problems.

6Recreate the PVC if needed

If the PVC is fundamentally broken, recreate it:

bash
# Backup the PVC spec
kubectl get pvc <pvc-name> -o yaml > pvc-backup.yaml

# Delete the broken PVC
kubectl delete pvc <pvc-name>

# Remove any claimRef and status from backup, then recreate
kubectl apply -f pvc-backup.yaml

Note: With Delete reclaim policy, deleting PVC also deletes the PV and data.

Advanced notes

PV reclaim policies determine what happens when a PVC is deleted:
- Delete: PV and underlying storage are deleted (default for dynamic provisioning)
- Retain: PV is kept but marked Released, requiring manual cleanup

For production workloads, consider using Retain to prevent accidental data loss:

yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: retain-storage
provisioner: kubernetes.io/aws-ebs
reclaimPolicy: Retain

Known issue: Kubernetes 1.22.0–1.22.8 and 1.23.0–1.23.5 have a race condition where pods can fail with "kube-root-ca.crt not registered" during termination. This manifests as a volume not found error for projected service account volumes. Upgrade to patched versions if you see this pattern.

Static provisioning requires manual PV creation and claimRef management. For simpler operations, use dynamic provisioning with appropriate storage classes.

Frequently asked questions

What does "MountVolume.SetUp failed: volume not found" mean?
The "volume not found" error indicates that the kubelet is trying to mount a volume for your pod, but the referenced storage resource doesn't exist or cannot be accessed. This happens after pod scheduling but before the container can start. Unlike attachment failures (which involve cloud provider operations), this error means the volume object itself is missing or in an invalid state.
How do I fix "MountVolume.SetUp failed: volume not found"?
This error occurs when a pod references a volume that doesn't exist, typically due to a deleted PersistentVolume, unbound PVC, or failed dynamic provisioning.
What causes "MountVolume.SetUp failed: volume not found"?
PersistentVolume was deleted while PVC still references it PVC not bound to any PV (stuck in Pending) Dynamic provisioning failed (quota exceeded, provisioner error)
Is the "MountVolume.SetUp failed: volume not found" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading