ProvisioningFailed: The provisioner tried to create a volume and the storage backend refused

ProvisioningFailed means dynamic provisioning was attempted and the storage system said no. The backend's own error is passed through in the event, and it is usually specific about why.

Applies to: All Kubernetes versions with dynamic provisioning

What it means

When a claim names a StorageClass with a provisioner, the CSI external-provisioner calls the storage backend to create a volume. A failure produces a ProvisioningFailed event on the claim with the backend's error attached. Because the error comes from outside Kubernetes, it is usually more precise than most cluster errors — a quota name, a permission, an unsupported parameter. The provisioner retries with backoff, so the event count climbs while the claim stays Pending. The two things worth checking before anything else are whether the provisioner is running at all, and whether the StorageClass's parameters are valid for the backend, since an invalid parameter fails deterministically and no amount of retrying will help.

Most common causes

• The CSI driver's credentials lack permission to create volumes.
• A storage quota at the cloud provider or storage array has been reached.
• A parameter in the StorageClass is invalid or unsupported by the driver — a wrong volume type name, an unsupported IOPS value.
• The requested size is below the backend's minimum or above its maximum.
• The requested access mode is not supported by the driver.
• The provisioner pod is not running, so nothing is servicing the claim.
• No capacity in the requested zone or storage pool.

How to diagnose it

1. Read the event on the claim: kubectl describe pvc CLAIM -n NAMESPACE. The backend's message is quoted verbatim.
2. Check the provisioner is running: kubectl get pods -n kube-system | grep csi.
3. Read the external-provisioner sidecar's logs, which carry more detail than the event: kubectl logs -n kube-system POD -c csi-provisioner.
4. Validate the StorageClass parameters against the driver's documentation: kubectl get storageclass NAME -o yaml.
5. Check the backend's own quota and capacity through its console or API.

How to fix it

1. Grant the CSI driver the permissions it needs at the cloud or storage layer.
2. Raise the storage quota, or free capacity by deleting volumes that are no longer needed.
3. Correct invalid StorageClass parameters. Note that changing a StorageClass does not retroactively fix claims already bound to it.
4. Adjust the requested size into the backend's supported range.
5. Restart or repair the provisioner if it is not running.

Notes

Retries continue indefinitely, so a claim that failed for a transient reason recovers on its own, while one that failed for a deterministic reason produces an event count in the thousands and never binds. The count itself is a useful signal about which kind you have.

Related

• PersistentVolumeClaim Pending — The claim has not bound to a volume
• CSI driver not found — The named CSI driver is not registered

Sources

• Kubernetes documentation — Dynamic Volume Provisioning
• Kubernetes documentation — Storage Classes
• Container Storage Interface specification