A PersistentVolumeClaim in Kubernetes declares accessModes such as ReadWriteOnce, ReadOnlyMany, ReadWriteMany or ReadWriteOncePod. What does each of those mean, and what is the unit they are scoped to?

## What access modes describe A `PersistentVolume` advertises the access modes its backend can support; a `PersistentVolumeClaim` requests one (a list is allowed, but binding uses one mode). The binding logic pairs a claim with a PV - or a StorageClass provisioner - that can satisfy the requested mode and size. If nothing can, the PVC sits in `Pending` and the pod that references it never starts. The key thing to internalise: **the unit is the node**, not the pod, for three of the four modes. That is a consequence of how storage is attached - a cloud disk or SAN LUN is attached to a *machine*, and once it is attached, everything on that machine can use it. ## The four modes **ReadWriteOnce (RWO)** - the volume may be attached read-write to a single node. Any number of pods scheduled on that node can mount it simultaneously and all can write. This surprises people who read "Once" as "one pod". It is the mode almost all block storage supports: AWS EBS, GCE Persistent Disk, Azure Disk, Ceph RBD, iSCSI LUNs, most local volumes. **ReadOnlyMany (ROX)** - the volume may be attached to many nodes, but only read-only. Typical for a pre-populated dataset, a model file or static content shared by many replicas. Support is backend-specific: some block backends allow multi-attach in read-only mode, and file backends generally do. **ReadWriteMany (RWX)** - many nodes, all read-write, at the same time. This requires a backend that implements a distributed or network filesystem with its own locking: NFS, CephFS, GlusterFS, AWS EFS, Azure Files, Google Filestore, Portworx, Longhorn (which serves RWX through an NFS layer). A plain block device cannot do it: two nodes writing to one block device with independent, non-cluster-aware filesystems corrupt it, because each node caches metadata it believes it owns exclusively. **ReadWriteOncePod (RWOP)** - read-write by exactly one **pod** cluster-wide. Alpha in 1.22, beta in 1.27, stable in 1.29. It exists precisely because RWO's node scope surprised people and offered no way to guarantee a single writer. Kubernetes enforces it at admission and mount time, and it requires a CSI driver reporting the `SINGLE_NODE_SINGLE_WRITER` capability. Use it for single-writer databases where two concurrent writers would corrupt data. ## Requested, matched - and only partly enforced An access mode is a **matchmaking attribute plus an attach-layer constraint**. Two frequent misunderstandings: - *Requesting a mode does not create the capability.* Ask for RWX from a StorageClass backed by cloud block storage and the claim never binds; you see a Pending PVC and a pod stuck in `ContainerCreating`. The volume type has to support it. - *It is not a file-permission setting.* Binding with `ReadOnlyMany` does not, by itself, make writes fail inside a container in every implementation; what reliably makes a mount read-only is `readOnly: true` on the pod's `volumeMounts` entry (or `persistentVolumeClaim.readOnly`). Treat the access mode as "how many machines may attach, and how", and the pod spec as "what this container may do". The attach layer *does* enforce the important part: with RWO, the external attach machinery will refuse to attach the same volume to a second node while the first still holds it - the origin of the `Multi-Attach error for volume ...` event. ## Choosing Start with RWO: it is universally supported, fastest, and correct for anything with a single writer per instance - which includes every StatefulSet replica that has its own volume. Reach for RWX only when several pods genuinely must write to the *same* filesystem at once, and know the price: a network filesystem in the data path, weaker POSIX semantics (especially locking), and lower throughput. Many apparent RWX needs are better served by object storage, a database, or giving each replica its own RWO volume. Use RWOP when a single writer is a correctness requirement rather than an expectation, and your CSI driver supports it. Use ROX for read-only shared datasets, remembering that some backends implement it as a genuine multi-attach and others by simply mounting read-only. ## Where you see it go wrong The standard incident: a Deployment with `strategy: RollingUpdate` and an RWO PVC. The new pod is scheduled to a different node, the volume cannot detach from the old node until the old pod terminates, and the rollout wedges with a `Multi-Attach` event. The mode was doing exactly what it promised; the workload shape was wrong for it.