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

KubernetesINTERMEDIATEHIGH

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 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).

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.

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

What this error means

Typical symptoms

Common causes

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

Advanced notes

Related errors

Official resources & further reading