What access modes can a PersistentVolume have, and why does this matter?
Quick Answer
**ReadWriteOnce (RWO)** allows the volume to be mounted as read-write by a single node at a time (as of Kubernetes 1.22+, actually restricted per-node rather than per-Pod, so multiple Pods on the same node can share it). **ReadOnlyMany (ROX)** allows many nodes to mount it simultaneously, but only read-only. **ReadWriteMany (RWX)** allows many nodes to mount it simultaneously with read-write access — but this is only supported by certain storage backends (typically network file systems like NFS or cloud file-share services), not by most block-storage-backed volumes (like standard cloud disks), which is a common source of confusion when a Deployment with multiple replicas tries to share one volume.
Detailed Answer
The three access modes
| Mode | Meaning |
|---|---|
| ReadWriteOnce (RWO) | Can be mounted read-write, but only by one node at a time (multiple Pods on that same node can still share it) |
| ReadOnlyMany (ROX) | Can be mounted read-only, simultaneously, by many nodes |
| ReadWriteMany (RWX) | Can be mounted read-write, simultaneously, by many nodes |
(A newer, more granular ReadWriteOncePod mode further restricts RWO to exactly one Pod — not just one node — for storage backends and use cases needing that stricter guarantee.)
Why most cloud block storage only supports RWO
Standard cloud block storage (AWS EBS, GCP Persistent Disk, Azure Disk) is fundamentally built like an attached hard drive — it can only be attached to one virtual machine (node) at a time, which is why these are backed by PVs that only support ReadWriteOnce. This is perfectly fine for a single-replica database, or for a StatefulSet where each replica gets its own separate RWO volume via volumeClaimTemplates (see that question) — the "many replicas" case is handled by giving each replica its own distinct RWO volume, not by sharing one.
The common mistake this causes
# A Deployment with 3 replicas, all referencing the SAME PVC
spec:
replicas: 3
template:
spec:
volumes:
- name: shared-data
persistentVolumeClaim:
claimName: shared-pvc # backed by a standard cloud disk (RWO)
If shared-pvc is backed by a typical cloud block-storage PV (RWO only), and the 3 replicas get scheduled across 3 different nodes, at most one of them will actually be able to mount the volume — the other two Pods will get stuck Pending or fail to start, unable to attach a volume that's already attached (read-write) elsewhere. This is a frequent source of confusion for engineers newer to Kubernetes storage, who reasonably assume "a PVC is just shared storage" without realizing the access mode of the underlying storage backend fundamentally limits this.
What actually supports ReadWriteMany
Network file systems and cloud file-share services are what genuinely support simultaneous multi-node read-write access: NFS, AWS EFS, Azure Files, GCP Filestore, and certain distributed storage systems (Ceph, GlusterFS) configured appropriately. If a workload genuinely needs multiple Pods across multiple nodes to read and write the same shared storage concurrently (a shared upload directory, a shared cache multiple services write to), the StorageClass/PV must specifically be backed by one of these RWX-capable systems — not standard cloud block storage.
Before designing a multi-replica workload that needs shared storage, explicitly check: does each replica actually need its own independent storage (→ use a StatefulSet with volumeClaimTemplates, RWO is fine), or do they genuinely need to concurrently read/write the same files (→ requires an RWX-capable storage backend, a real architectural decision with real performance/consistency tradeoffs of its own, not just a checkbox to enable). Assuming "any PVC can just be shared across replicas" without checking the access mode and underlying storage backend's actual capability is one of the more common Kubernetes storage misconceptions that only surfaces once Pods start failing to schedule or attach.