How to fix FailedAttachVolume in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 5, 2025· 273 views

The FailedAttachVolume error occurs when Kubernetes cannot attach a persistent volume to a node, typically because the volume is already attached elsewhere or the cloud provider operation failed.

Quick fix

Fixes FailedAttachVolume

kubectl describe pod <pod-name>
  1. Check pod events and identify the volume
  2. Check VolumeAttachments
  3. Verify the old node status
  4. Force detach via cloud provider CLI
kubernetes — error
kubectl describe pod <pod-name>
FailedAttachVolume

What this error means

The FailedAttachVolume error indicates that Kubernetes cannot attach a PersistentVolume to the node where your pod is scheduled. This is a cloud provider or storage backend operation that must complete before the volume can be mounted. The most common cause (~90% of cases) is the volume being attached to another node. Cloud provider volumes (AWS EBS, Azure Disk, GCP Persistent Disk) can only attach to one node at a time. If a previous pod crashed or its node failed, the volume may still be attached to the old node. Kubernetes waits up to 6 minutes for attachment before giving up. It does not automatically force-detach volumes to prevent data corruption.

Typical symptoms

  • Pod stuck in ContainerCreating or Pending
  • kubectl describe pod shows FailedAttachVolume warning
  • Volume attachment timeout after several minutes
  • Same PVC works on one node but fails on another
  • Pod rescheduled after node failure cannot start

Common causes

  1. Volume already attached to another node (most common)
  2. Previous node failed and volume stuck in attached state
  3. VolumeAttachment resource stuck in deleting state
  4. Cloud provider API rate limiting or errors
  5. Wrong availability zone (volume and node in different AZs)

How to fix "FailedAttachVolume"

1Check pod events and identify the volume

Get details about the attachment failure:

bash
kubectl describe pod <pod-name>

Look for:

bash
Warning  FailedAttachVolume  AttachVolume.Attach failed for volume "pvc-xxx"
  : rpc error: volume is already attached to another node
2Check VolumeAttachments

See which node the volume thinks it's attached to:

bash
kubectl get volumeattachments

# Get details
kubectl describe volumeattachment <attachment-name>

The output shows the node name in the spec.

3Verify the old node status

Check if the node the volume is attached to still exists:

bash
kubectl get nodes
kubectl describe node <old-node-name>

If the node is NotReady or doesn't exist, the volume is orphaned.

4Force detach via cloud provider CLI

If the old node is confirmed down, force detach using your cloud provider:

AWS:

bash
aws ec2 detach-volume --volume-id vol-xxx --force

Azure:

bash
az disk update --name <disk> --resource-group <rg> --set diskState=Unattached

GCP:

bash
gcloud compute instances detach-disk <instance> --disk=<disk-name>
5Delete stuck VolumeAttachment

If the VolumeAttachment is stuck, remove its finalizers:

bash
# Edit and remove finalizers
kubectl edit volumeattachment <attachment-name>

Remove the finalizers section:

yaml
finalizers:
- external-attacher/xxx-csi-driver  # Remove this

Or delete the attachment directly:

bash
kubectl delete volumeattachment <attachment-name>
6Delete the failed node object (last resort)

If the node is truly gone and nothing else works:

bash
# This releases all volumes from the dead node
kubectl delete node <dead-node-name>

Warning: Only do this after confirming the node will not come back.

Advanced notes

Kubernetes has a 6-minute timeout for volume attachment. It won't force-detach because doing so risks data corruption if the volume is being written to.

Managed Kubernetes services (GKE, EKS, AKS) handle this better through out-of-band health checks that can confirm a node is truly down and safely detach volumes.

For self-managed clusters, consider enabling the VolumeAttachment garbage collection controller. You can also adjust the attach-detach controller's reconciliation:

bash
--attach-detach-reconcile-sync-period=1m

ReadWriteMany (RWX) volumes don't have this problem since they support multiple attachments. Consider using RWX storage classes (EFS, NFS, CephFS) for workloads that may need to reschedule quickly.

If you frequently see this issue after node failures, implement Pod Disruption Budgets and use StatefulSets with proper terminationGracePeriodSeconds to ensure clean detachment before pod termination.

Frequently asked questions

What does "FailedAttachVolume" mean?
The FailedAttachVolume error indicates that Kubernetes cannot attach a PersistentVolume to the node where your pod is scheduled. This is a cloud provider or storage backend operation that must complete before the volume can be mounted. The most common cause (~90% of cases) is the volume being attached to another node.
How do I fix "FailedAttachVolume"?
The FailedAttachVolume error occurs when Kubernetes cannot attach a persistent volume to a node, typically because the volume is already attached elsewhere or the cloud provider operation failed.
What causes "FailedAttachVolume"?
Volume already attached to another node (most common) Previous node failed and volume stuck in attached state VolumeAttachment resource stuck in deleting state
Is the "FailedAttachVolume" 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