Kubernetes PVC Stuck: CSI Driver Volume Not Mounting Fix

Your PVC shows Bound in kubectl get pvc, yet the pod sits in ContainerCreating forever. This is almost always a CSI driver problem. Here is how to find and fix it fast.

Step 1: Read the Pod Events

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

Scroll to the Events section. You will see something like:

Warning  FailedMount  2m  kubelet  MountVolume.SetUp failed for volume "pvc-abc123":
  rpc error: code = Internal desc = Could not attach volume "vol-0abc123def456" to node "i-0abc":
  VolumeInUse

or

Warning  FailedMount  90s  kubelet  Unable to attach or mount volumes:
  unmounted volumes=[data], unattached volumes=[data]:
  timed out waiting for the condition

Copy the exact error message — it tells you which layer is broken.

Step 2: Check CSI Driver Pods Are Running

kubectl get pods -n kube-system | grep csi

Expected output for AWS EBS CSI:

ebs-csi-controller-7d9f6b8c4-xk2pq   6/6   Running   0   2d
ebs-csi-controller-7d9f6b8c4-zr9wt   6/6   Running   0   2d
ebs-csi-node-4fnxp                   3/3   Running   0   2d
ebs-csi-node-7gkzm                   3/3   Running   0   2d

If any pod is in CrashLoopBackOff or Error, read its logs:

kubectl logs -n kube-system ebs-csi-controller-<id> -c ebs-plugin --previous

Step 3: Check VolumeAttachment

kubectl get volumeattachment

NAME                                                            ATTACHER                  PV                      NODE            ATTACHED   AGE
csi-abc123def456789...                                         ebs.csi.aws.com           pvc-0abc123def456       ip-10-0-1-200   false      8m

If ATTACHED is false and it has been more than 2 minutes, the CSI controller is not doing its job. Delete the stuck attachment and let it recreate:

kubectl delete volumeattachment csi-abc123def456789...

Common Errors and Fixes

Error 1: "driver name ebs.csi.aws.com not found in the list of registered CSI drivers"

The node CSI plugin is not running on that node. Check the daemonset:

kubectl get daemonset ebs-csi-node -n kube-system

If DESIRED does not match READY, look at why the node pod is not scheduling:

kubectl describe pod ebs-csi-node-<id> -n kube-system

A common cause is a node taint that the daemonset tolerations do not cover.

Error 2: IAM Permissions for EBS CSI Driver on EKS

This is the most common root cause on EKS. The CSI driver needs an IAM role with EBS permissions, wired via IRSA (IAM Roles for Service Accounts).

Check if the service account has the annotation:

kubectl describe serviceaccount ebs-csi-controller-sa -n kube-system

You need to see:

Annotations:  eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/AmazonEKS_EBS_CSI_DriverRole

If the annotation is missing, create the IRSA role:

eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve \
  --override-existing-serviceaccounts

Then restart the controller:

kubectl rollout restart deployment ebs-csi-controller -n kube-system

Error 3: StorageClass Provisioner Mismatch

Your StorageClass might still reference the old in-tree provisioner:

kubectl get storageclass gp2 -o yaml | grep provisioner

Old (broken on newer EKS):

provisioner: kubernetes.io/aws-ebs

New (correct):

provisioner: ebs.csi.aws.com

Create a new StorageClass with the correct provisioner:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete

Apply it and update your PVC to use storageClassName: gp3.

Error 4: Node Plugin CrashLoopBackOff Due to Missing nvme Tools

On some Amazon Linux 2 nodes the NVMe tooling is missing. Check logs:

kubectl logs -n kube-system ebs-csi-node-<id> -c ebs-plugin

If you see nvme: command not found, upgrade your node group AMI to Amazon Linux 2023 or the latest EKS-optimised AMI.

Quick Diagnostic Checklist

# 1. Pod events
kubectl describe pod <pod> -n <ns>
 
# 2. CSI pods health
kubectl get pods -n kube-system | grep csi
 
# 3. CSI driver registration
kubectl get csidriver
 
# 4. VolumeAttachment status
kubectl get volumeattachment
 
# 5. IRSA annotation on service account
kubectl describe sa ebs-csi-controller-sa -n kube-system
 
# 6. StorageClass provisioner
kubectl get storageclass -o wide

Work through this list top to bottom and you will find the culprit within five minutes. The most common fix on EKS is the missing IRSA annotation — add it, restart the controller, and the volume attaches within 30 seconds.

Need help with Kubernetes storage? Check our Kubernetes cheatsheet for quick reference commands.