How to fix FailedAttachVolume: Multi-Attach error for volume, volume already exclusively attached to one node and can't be attached to another in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 198 views

A PersistentVolume with ReadWriteOnce access mode is already exclusively attached to one node, preventing a new pod on a different node from mounting it. This commonly occurs after node failures, failed pod restarts, or Deployment rolling updates. Fix by cleaning up stale VolumeAttachments, scaling the Deployment, or switching to StatefulSets.

Quick fix

Fixes FailedAttachVolume: Multi-Attach error for volume, volume already exclusively attached to one node and can't be attached to another

kubectl get pod <pod-name> -n <namespace> -o wide
kubectl get pvc -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Check the pod and PVC status
Identify and delete stale VolumeAttachment objects
Force-delete the stuck pod
Scale Deployment to zero and back up

kubernetes — error

$kubectl get pod <pod-name> -n <namespace> -o wide
kubectl get pvc -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
FailedAttachVolume: Multi-Attach error for volume, volume already exclusively attached to one node and can't be attached to another

What this error means

ReadWriteOnce (RWO) volumes in Kubernetes can only be mounted by one pod at a time, and only pods on the same node where the volume is attached. When Kubernetes tries to schedule a new pod on a different node but the volume is still attached to the old node (because the old pod hasn't cleanly terminated or the node failed), the attach controller refuses to detach and reattach the volume. This multi-attach protection exists to prevent data corruption from simultaneous writes.

Typical symptoms

Pods remain in Pending or ContainerCreating state indefinitely
kubectl describe pod shows FailedAttachVolume or FailedMount events
Deployment rolling updates hang: old replicas don't terminate, new replicas can't start
Error message mentions "already exclusively attached to one node and can't be attached to another"
Node failure scenarios leave volumes orphaned and unavailable to new pods
PVC shows bound to a volume, but pod can't use it from a different node

Common causes

Pod on node A still running or stuck in termination, while new pod scheduled on node B tries to use same RWO volume
Node crashed or became unreachable, leaving volume marked as attached to dead node
Stale VolumeAttachment resource pointing to deleted or non-existent node blocking cleanup
Deployment with rolling update strategy creating deadlock: old pod won't die until new pod starts, new pod can't start because volume still attached to old pod's node
Zone/availability zone mismatch: volume provisioned in zone A but pod scheduled in zone B
Graceful termination timeout expired, leaving volume in attached state while pod forcefully kills

How to fix "FailedAttachVolume: Multi-Attach error for volume, volume already exclusively attached to one node and can't be attached to another"

1Check the pod and PVC status

First, understand what's happening:

bash

kubectl get pod <pod-name> -n <namespace> -o wide
kubectl get pvc -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Look for which node the pod is trying to use, and which node the volume is attached to (visible in events).

2Identify and delete stale VolumeAttachment objects

VolumeAttachment resources track which nodes have volumes attached. Stale ones block reattachment:

bash

kubectl get volumeattachments

For each attachment pointing to a dead or non-existent node, delete it:

bash

kubectl delete volumeattachment <attachment-name>

If deletion hangs with finalizers, force-remove them:

bash

kubectl patch volumeattachment <attachment-name> -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl delete volumeattachment <attachment-name>

3Force-delete the stuck pod

If the old pod is stuck in termination (Terminating state for >5 minutes), force-delete it:

bash

kubectl delete pod <pod-name> -n <namespace> --grace-period=0 --force

This immediately removes the pod object from the cluster, allowing the volume controller to detach the volume from the old node and attach it to the new pod.

4Scale Deployment to zero and back up

If a Deployment is stuck with rolling updates, reset it:

bash

kubectl scale deployment <deployment-name> -n <namespace> --replicas=0

Wait 30 seconds for all pods to terminate and volumes to detach:

bash

kubectl get pod -n <namespace> | grep <deployment-name>

Then scale back up:

bash

kubectl scale deployment <deployment-name> -n <namespace> --replicas=<desired-count>

This forces fresh pod scheduling and volume attachment.

5Switch from Deployment to StatefulSet for stateful workloads

If using a Deployment with RWO volumes, this is the root cause. StatefulSets guarantee ordered termination and startup, preventing the deadlock:

Convert Deployment to StatefulSet:

yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-app
spec:
  serviceName: my-app  # Requires headless service
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-image
        volumeMounts:
        - name: data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      storageClassName: standard
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

StatefulSets handle termination and attachment sequentially, eliminating multi-attach errors.

6Use WaitForFirstConsumer binding mode to prevent zone mismatches

If using cloud storage (AWS EBS, GCP PD, Azure Disk), configure the StorageClass with zone-aware binding:

yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-gp2
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - us-east-1a
    - us-east-1b
parameters:
  type: gp2
  iops: "100"

This ensures volumes are provisioned in the same zone as the pod, preventing cross-zone attachment failures.

7Verify the volume is now attached and pod can run

Check that the pod is now Running and the PVC is Bound:

bash

kubectl get pod,pvc -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

If still Pending, check pod events and VolumeAttachment status again. If the node is dead, Kubernetes may need 5-10 minutes to mark it as NotReady before allowing volume reattachment.

Advanced notes

For cloud providers: AWS EBS volumes cannot attach to multiple instances; use multi-attach EBS volumes (io1/io2) only if your application truly supports concurrent writes. GCP Persistent Disks are zone-locked; use allowedTopologies in StorageClass to enforce zone affinity. Azure Disk supports ReadWriteOnce only by default; for multi-writer scenarios, use Azure Shared Disks or NFS instead. For on-premises storage (Longhorn, Ceph), the controller may auto-recover after 6 minutes; manual VolumeAttachment cleanup is faster. Kubernetes 1.25+ includes fixes for non-graceful node shutdown that automatically detach volumes from failed nodes more reliably. For CI/CD pipelines, set appropriate pod termination grace periods (terminationGracePeriodSeconds) to allow clean shutdown before force-kill.

Frequently asked questions

What does "FailedAttachVolume: Multi-Attach error for volume, volume already excl" mean?: ReadWriteOnce (RWO) volumes in Kubernetes can only be mounted by one pod at a time, and only pods on the same node where the volume is attached. When Kubernetes tries to schedule a new pod on a different node but the volume is still attached to the old node (because the old pod hasn't cleanly terminated or the node failed), the attach controller refuses to detach and reattach the volume. This multi-attach protection exists to prevent data corruption from simultaneous writes.
How do I fix "FailedAttachVolume: Multi-Attach error for volume, volume already excl"?: A PersistentVolume with ReadWriteOnce access mode is already exclusively attached to one node, preventing a new pod on a different node from mounting it. This commonly occurs after node failures, failed pod restarts, or Deployment rolling updates. Fix by cleaning up stale VolumeAttachments, scaling the Deployment, or switching to StatefulSets.
What causes "FailedAttachVolume: Multi-Attach error for volume, volume already excl"?: Pod on node A still running or stuck in termination, while new pod scheduled on node B tries to use same RWO volume Node crashed or became unreachable, leaving volume marked as attached to dead node Stale VolumeAttachment resource pointing to deleted or non-existent node blocking cleanup
Is the "FailedAttachVolume: Multi-Attach error for volume, volume already excl" 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

📚Kubernetes Official Documentation
📖
Kubernetes Docs: persistent volumes(Official Docs)
📝
kubernetes.io: read write once pod access mode alpha
🔗
discuss.kubernetes.io: 18951
💬
Stack Overflow: kubernetes multi attach error for volume pvc volume is already exclusively att(Stack Overflow)

How to fix FailedAttachVolume: Multi-Attach error for volume, volume already exclusively attached to one node and can't be attached to another in Kubernetes

Quick fix

What this error means

Typical symptoms

Common causes

How to fix "FailedAttachVolume: Multi-Attach error for volume, volume already exclusively attached to one node and can't be attached to another"

Advanced notes

Frequently asked questions

Related errors

Official resources & further reading