Multi-Attach error: A ReadWriteOnce volume is already attached to a different node

Multi-Attach error for volume means a pod needs a volume that is still attached to another node. Access mode ReadWriteOnce permits exactly one node, so the new pod waits until the old one lets go.

Applies to: All Kubernetes versions using ReadWriteOnce volumes

What it means

The event reads Multi-Attach error for volume "pvc-…" Volume is already exclusively attached to one node and can't be attached to another. This is the access-mode contract being enforced. ReadWriteOnce means the volume may be mounted read-write by a single node — not a single pod, a single node, which is why several pods on the same node can share it while one pod on a different node cannot. The situation arises constantly during rolling updates of a workload with a persistent volume: the new pod is scheduled to a different node and starts waiting before the old pod on the original node has finished terminating.

Most common causes

• A rolling update placing the replacement pod on a different node while the original is still terminating.
• A pod stuck in Terminating, so the volume is never detached.
• A node that has become unreachable, leaving the attachment in place with nothing to release it.
• A Deployment with more than one replica sharing a ReadWriteOnce claim — this can never work across nodes.
• A previous force-deleted pod whose container is still running and still holding the volume.

How to diagnose it

1. Find which node holds the volume. The attachment lists the PersistentVolume name, not the claim name, so resolve the claim first: kubectl get pvc CLAIM -n NAMESPACE -o jsonpath='{.spec.volumeName}', then kubectl get volumeattachment | grep THAT_PV_NAME.
2. Find the pod on that node still using the claim: kubectl get pods --all-namespaces -o wide and match the node.
3. Check whether that pod is stuck terminating, and if so why — a finalizer, an unmount failure, or an unreachable node.
4. Check the node's status: an unreachable node explains why nothing is detaching.
5. Check the replica count and strategy of the workload — more than one replica on a ReadWriteOnce claim is a design problem, not a transient one.

How to fix it

1. Wait, if a rollout is in progress. It usually resolves in under a minute once the old pod terminates.
2. For workloads with a single persistent volume, use the Recreate deployment strategy so the old pod is fully gone before the new one is created.
3. Resolve the stuck terminating pod rather than force-deleting it, since force-deleting does not stop the container that is holding the volume.
4. Use a StatefulSet with per-replica volume claim templates instead of several replicas sharing one claim.
5. If multiple pods across nodes genuinely need the same volume, use a storage backend that supports ReadWriteMany. Most block storage does not.

Notes

ReadWriteOnce restricts to one node, not one pod. ReadWriteOncePod, added later, is the access mode that restricts to a single pod, and it is the right choice when two pods sharing a volume would corrupt data.

Related

• FailedAttachVolume — The volume could not be attached to the node
• Terminating — Pod stuck in deletion

Sources

• Kubernetes documentation — Persistent Volumes: access modes
• Kubernetes documentation — Deployments: strategy
• Kubernetes documentation — StatefulSets