How to fix no persistent volumes available for this claim in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 214 views

This error occurs when a PersistentVolumeClaim cannot find any matching PersistentVolume in the cluster. Common causes include missing StorageClass configuration, no static PVs available, or mismatched capacity/access modes between PVC and PV.

Quick fix

Fixes no persistent volumes available for this claim

kubectl get pvc
kubectl describe pvc <pvc-name>
  1. Check PVC status and events
  2. Verify a default StorageClass exists
  3. Install a storage provisioner
  4. Create a matching static PV
kubernetes — error
kubectl get pvc
kubectl describe pvc <pvc-name>
no persistent volumes available for this claim

What this error means

When Kubernetes reports "no persistent volumes available for this claim," your PVC is stuck in Pending state because the cluster cannot find or create a suitable PersistentVolume. This is a blocking error—pods depending on this PVC will not start. This commonly happens when moving from managed Kubernetes (GKE, EKS, AKS) to self-hosted clusters (kubeadm, microk8s, k3s) where dynamic provisioning isn't automatically configured. Managed services provide default StorageClasses, but bare-metal or local clusters require manual setup. The Kubernetes storage controller needs either a dynamic provisioner to create PVs on-demand, or pre-created static PVs that match your PVC's requirements (storage class, capacity, access modes).

Typical symptoms

  • PVC remains in Pending state indefinitely
  • kubectl get pvc shows STATUS as Pending with no VOLUME bound
  • kubectl describe pvc shows "no persistent volumes available for this claim" in Events
  • Pods using the PVC are stuck in Pending state
  • StatefulSet or Deployment pods cannot start
  • Error appears after migrating from managed Kubernetes to self-hosted cluster
  • Helm charts fail during installation waiting for PVC to bind

Common causes

  1. No default StorageClass configured in the cluster
  2. PVC references a StorageClass that does not exist
  3. No static PersistentVolumes available that match PVC requirements
  4. PVC requests more storage capacity than any available PV provides
  5. Access mode mismatch—PVC requests ReadWriteMany but PVs only support ReadWriteOnce
  6. Storage provisioner pod is not running or not installed
  7. PVC created before StorageClass was marked as default (timing issue)
  8. StorageClass uses WaitForFirstConsumer but no pod has been scheduled yet

How to fix "no persistent volumes available for this claim"

1Check PVC status and events

Inspect why the PVC is pending:

bash
kubectl get pvc
kubectl describe pvc <pvc-name>

Look at the Events section for the specific error message. Also check if any PVs exist:

bash
kubectl get pv
kubectl get storageclass
2Verify a default StorageClass exists

Check if your cluster has a default StorageClass:

bash
kubectl get storageclass

The default should have (default) next to its name. If no default exists, create one or mark an existing class as default:

bash
kubectl patch storageclass <name> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
3Install a storage provisioner

For local/self-hosted clusters, install a storage provisioner:

Minikube:

bash
minikube addons enable storage-provisioner

microk8s:

bash
microk8s enable storage

K3s (local-path):

bash
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml

Kind:

bash
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
4Create a matching static PV

If using static provisioning, create a PV that matches your PVC:

yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi  # Must be >= PVC request
  accessModes:
    - ReadWriteOnce  # Must match PVC
  storageClassName: manual  # Must match PVC
  hostPath:
    path: /mnt/data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: manual
  resources:
    requests:
      storage: 5Gi
5Check for capacity and access mode mismatches

Ensure your PVC requirements can be satisfied:

bash
# Check what PVC is requesting
kubectl get pvc <name> -o yaml | grep -A5 "spec:"

# Check what PVs offer
kubectl get pv -o custom-columns=NAME:.metadata.name,CAPACITY:.spec.capacity.storage,ACCESS:.spec.accessModes,CLASS:.spec.storageClassName,STATUS:.status.phase

Common issues:
- PVC requests 10Gi but PV only has 5Gi
- PVC needs ReadWriteMany but PV only supports ReadWriteOnce
- PVC specifies storageClassName but PV has a different class

6Handle WaitForFirstConsumer binding mode

Some StorageClasses delay binding until a pod is scheduled:

bash
kubectl get storageclass <name> -o yaml | grep volumeBindingMode

If it shows WaitForFirstConsumer, the PVC will stay Pending until you create a pod that uses it. This is normal behavior for topology-aware storage.

Create a test pod to trigger binding:

yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pvc
spec:
  containers:
  - name: test
    image: busybox
    command: ["sleep", "3600"]
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: <your-pvc-name>
7Verify provisioner is running

Check that the storage provisioner pods are healthy:

bash
# Check for common provisioner pods
kubectl get pods -n kube-system | grep -E 'provisioner|csi|storage'

# For cloud providers
kubectl get pods -n kube-system | grep -E 'ebs-csi|gce-pd|azure-disk'

If the provisioner pod is crashing or not present, the storage controller cannot dynamically create volumes.

Advanced notes

Migrating from Managed to Self-Hosted Clusters:
When moving workloads from GKE/EKS/AKS to kubeadm or microk8s, you lose the automatic storage provisioning. You must either:
1. Install a CSI driver and StorageClass for your storage backend
2. Use local-path-provisioner for development
3. Set up NFS provisioner for shared storage

StorageClass Empty String vs Unset:
Kubernetes treats storageClassName: "" (empty string) differently from omitting the field entirely:
- Empty string: Explicitly requests no StorageClass (static binding only)
- Omitted: Uses the cluster's default StorageClass

Pre-binding with volumeName:
To force a specific PV-to-PVC binding, use the volumeName field:

yaml
spec:
  volumeName: my-specific-pv
  storageClassName: ""  # Required for pre-binding

NFS for ReadWriteMany:
If you need ReadWriteMany access mode, most local provisioners won't work. Consider NFS-based provisioners like nfs-subdir-external-provisioner.

Frequently asked questions

What does "no persistent volumes available for this claim" mean?
When Kubernetes reports "no persistent volumes available for this claim," your PVC is stuck in Pending state because the cluster cannot find or create a suitable PersistentVolume. This is a blocking error—pods depending on this PVC will not start. This commonly happens when moving from managed Kubernetes (GKE, EKS, AKS) to self-hosted clusters (kubeadm, microk8s, k3s) where dynamic provisioning isn't automatically configured.
How do I fix "no persistent volumes available for this claim"?
This error occurs when a PersistentVolumeClaim cannot find any matching PersistentVolume in the cluster. Common causes include missing StorageClass configuration, no static PVs available, or mismatched capacity/access modes between PVC and PV.
What causes "no persistent volumes available for this claim"?
No default StorageClass configured in the cluster PVC references a StorageClass that does not exist No static PersistentVolumes available that match PVC requirements
Is the "no persistent volumes available for this claim" 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