read-only file system: The process tried to write somewhere it cannot

EROFS means the target path is mounted read-only — usually because readOnlyRootFilesystem is set, or because the write is aimed at a ConfigMap or Secret volume, which are always read-only.

Applies to: All Kubernetes versions

What it means

Several Kubernetes mechanisms produce read-only paths, and the resulting error is identical for all of them. readOnlyRootFilesystem: true in a security context makes the container's own filesystem immutable, which is a valuable hardening measure and one that many applications are not prepared for — they expect to write temporary files, caches, or PID files. Separately, ConfigMap and Secret volumes are mounted read-only by design and cannot be made writable. And a PersistentVolume can be mounted read-only either by the claim's access mode or by the mount's own readOnly flag.

Most common causes

• readOnlyRootFilesystem: true with an application that writes to its own filesystem.
• An application writing to a ConfigMap or Secret volume, which is never writable.
• A volume mount with readOnly: true set.
• A PersistentVolume bound with a read-only access mode.
• The node's own filesystem having been remounted read-only after a disk error — this affects everything on the node, not one container.
• An application writing temporary files to a path with no writable volume behind it.

How to diagnose it

1. Find the path from the application's error, then check how it is mounted: kubectl exec POD -- mount | grep PATH.
2. Check the security context: kubectl get pod POD -o jsonpath='{.spec.containers[*].securityContext.readOnlyRootFilesystem}'.
3. Check the volume mounts for a readOnly flag: kubectl get pod POD -o jsonpath='{.spec.containers[*].volumeMounts}'.
4. If everything on the node is failing to write, check the node's kernel log for a filesystem error that caused a read-only remount.
5. Identify what the application actually needs to write — often it is only a temporary directory.

How to fix it

1. Mount an emptyDir at the paths the application writes, keeping the root filesystem read-only. This is the intended pattern and preserves the hardening.
2. Configure the application to write to a designated writable path rather than wherever it defaults to.
3. Copy ConfigMap or Secret contents into a writable location at startup if the application insists on modifying them.
4. Remove readOnly: true from a mount that genuinely needs writing, or use a read-write access mode.
5. For a node remounted read-only by a disk error, drain the node and replace it — that is hardware failure, not configuration.

Notes

readOnlyRootFilesystem is worth keeping. The usual objection is that the application writes temporary files, and the usual answer is an emptyDir mounted at /tmp, which takes one block of YAML and preserves the property that a compromised process cannot modify its own binaries.

Related

• permission denied on a mounted volume — The container's user cannot write the volume
• operation not permitted — A syscall was blocked by a security layer

Sources

• Kubernetes documentation — Configure a Security Context for a Pod or Container
• Kubernetes documentation — Volumes
• Kubernetes documentation — Pod Security Standards