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?
answer
- RWO/ROX/RWX are node-scoped; RWOP is pod-scoped
- RWO = many pods OK if same node
- RWX needs a shared filesystem (NFS/CephFS/EFS/Azure Files)
- RWOP stable in 1.29, needs CSI SINGLE_NODE_SINGLE_WRITER
- mode is a match request + attach constraint, not file permissions
basics
~10 sReadWriteOnce: mounted read-write by one node. ReadOnlyMany: mounted read-only by many nodes. ReadWriteMany: mounted read-write by many nodes. ReadWriteOncePod: exactly one pod cluster-wide. Except for ReadWriteOncePod, the scope is the node, not the pod.
solid answer
~60 sAccess modes describe how many **nodes** may mount a volume and in which direction. - **ReadWriteOnce (RWO)** - mountable read-write by a single **node**. Multiple pods on that same node can all use it; a pod on a second node cannot. - **ReadOnlyMany (ROX)** - mountable read-only by many nodes at once. - **ReadWriteMany (RWX)** - mountable read-write by many nodes at once. Requires a shared-filesystem backend such as NFS, CephFS, EFS or Azure Files; block devices cannot offer it safely. - **ReadWriteOncePod (RWOP)** - mountable by exactly **one pod** in the whole cluster; the only pod-scoped mode. Stable since Kubernetes 1.29 and requires a CSI driver that supports it. Two things to stress. First, a mode is a **request matched against what the backend supports** - listing RWX does not make a block volume shareable; if no PV or StorageClass can satisfy it, the claim stays Pending. Second, the mode is not a per-mount permission: whether a container writes is governed by `readOnly` on the volume mount, not by the access mode.
code
yaml · 23 linesapiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: db-data
spec:
accessModes:
- ReadWriteOncePod
resources:
requests:
storage: 50Gi
storageClassName: fast-block
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: shared-uploads
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 200Gi
storageClassName: nfs-sharedgo deeper
List the four modes and state clearly that RWO/ROX/RWX count nodes while RWOP counts pods.
Add that the mode is matched against backend capability, that RWX needs a shared filesystem, and that readOnly on the mount is what governs writing.
Connect modes to workload shape: RWO plus RollingUpdate causes multi-attach stalls, RWOP guarantees a single writer, and RWX costs POSIX semantics and throughput.
Set the platform default (block RWO per replica), decide when shared filesystems are permitted at all, and weigh the operational cost of running an RWX backend versus pushing teams to object storage or a database.
## 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.
- Two pods on the same node both mount a PVC bound with ReadWriteOnce, and both write. Is that allowed?Yes. ReadWriteOnce is scoped to the node, so once the volume is attached there, any number of pods on that node may mount it read-write. Kubernetes will not stop them, and it will not arbitrate their writes - if the application cannot tolerate concurrent writers you must enforce that yourself, or use ReadWriteOncePod, which restricts the volume to a single pod cluster-wide.
- A PVC requesting ReadWriteMany stays Pending forever against a cloud block StorageClass. What is happening?The provisioner cannot satisfy the requested mode, because block devices such as EBS or Azure Disk cannot be safely mounted read-write from several nodes at once. No PV is created, the claim never binds, and any pod referencing it stays in ContainerCreating. Either switch to a file-based StorageClass that supports RWX (NFS, EFS, Azure Files, CephFS), or redesign so each replica gets its own ReadWriteOnce volume.
Think of a volume as a workshop key. RWO hands one key to a building (a node) - everyone inside can use the workshop. ROX makes many read-only copies for many buildings. RWX means every building can work in it at once, which only works if the workshop was designed for crowds. RWOP hands the key to exactly one person.
saying these in an interview costs you the question
- Reading ReadWriteOnce as 'one pod' rather than 'one node'.
- Assuming requesting ReadWriteMany makes any backend support it.
- Treating ReadOnlyMany as the way to make a mount read-only for a container (that is readOnly on the volumeMount).
- Thinking ReadWriteOncePod works on any driver, without the CSI capability.
- Believing Kubernetes coordinates concurrent writers for you once the mode allows multiple mounts.