Fix Linux Read-Only File System EROFS Errors (2026)

The EROFS error means the kernel tried to write to a filesystem that it can only read from, and it’s failing because the underlying storage is fundamentally immutable.

This usually happens when a container or application expects to modify files within a read-only mount point, but the filesystem itself, or a layer above it, has been explicitly configured or is inherently read-only. The most common culprit is overlay filesystems used in container runtimes like Docker or Podman, where the read-only layer is being written to instead of the writable upper layer.

Here are the common causes and how to fix them:

1. Incorrect OverlayFS Configuration in Container Runtimes:

   • Diagnosis: Check your container runtime’s configuration for how it mounts volumes. For Docker, examine the output of docker inspect <container_id>. Look for Mounts where Type is overlay or bind and ReadOnly is true for the container’s view of the mount point, but the underlying host path is expected to be writable. For Podman, use podman inspect <container_id>.
   • Fix: If a specific volume is intended to be writable, ensure it’s not mounted as read-only within the container.
     • Docker: When running a container, remove the :ro flag from the volume mount: docker run -v /host/path:/container/path ... instead of docker run -v /host/path:/container/path:ro .... If the volume is managed by Docker (e.g., named volumes), ensure it’s not explicitly set to read-only in docker-compose.yml or the docker run command.
     • Podman: Similar to Docker, avoid the :ro suffix: podman run -v /host/path:/container/path ....
   • Why it works: Container runtimes often use overlay filesystems. The base image layers are read-only. If you try to write to these, the kernel returns EROFS. By mounting a writable volume or ensuring the top layer of the overlay is writable, writes are directed to the correct, mutable storage.

2. Read-Only Root Filesystem in Containers:

   • Diagnosis: If the error occurs on files within the container’s root filesystem (e.g., /etc, /app), the container’s root filesystem itself might be read-only. Check the container’s run command or orchestration configuration.
   • Fix:
     • Docker: Use docker run --read-only=false ... or remove the --read-only flag entirely if it was present.
     • Kubernetes: In your Pod definition, remove readOnly: true from the relevant volumeMounts or ensure the Pod spec doesn’t have securityContext.readOnlyRootFilesystem: true if it’s intended to be writable.
   • Why it works: Many container images are designed with a read-only root filesystem for security. If an application needs to write logs or temporary files, this setting must be disabled or specific writable directories must be explicitly mounted.

3. Immutable tmpfs Mounts:

   • Diagnosis: Applications often write to /tmp or other temporary directories. If these are mounted as tmpfs and the tmpfs itself has been configured as read-only (less common, but possible via specific systemd or mount options), EROFS can occur. Check mount output inside the container or on the host if the tmpfs is directly mounted.
   • Fix: Ensure the tmpfs mount is not explicitly marked as read-only.
     • Docker: Remove :ro from tmpfs mounts: docker run --tmpfs /tmp:rw ....
     • Kubernetes: In Pod spec, for emptyDir volumes, ensure no readOnly field is set within volumeMounts that would propagate this. For tmpfs mounts in volume definitions, ensure readOnly: false or it’s omitted.
   • Why it works: tmpfs is a memory-based filesystem, inherently writable. If it appears read-only, it’s due to an explicit mount option preventing writes.

4. Read-Only Host Mounts:

   • Diagnosis: If you’re mounting a directory from the host machine into a container using docker run -v /host/path:/container/path or podman run -v /host/path:/container/path, and /host/path is actually a read-only filesystem on the host (e.g., mounted from an NFS share with ro options, or a partition that’s read-only), the container will inherit this. Check mount output on the host for /host/path.
   • Fix: Remount the host directory as read-write or ensure it’s on a writable filesystem.
     • On the host: If /host/path is on an NFS mount, check /etc/fstab or the NFS server’s export options. If it’s a local partition, check mount output for ro flags and remount if necessary: sudo mount -o remount,rw /host/path.
   • Why it works: The container’s view of the mounted volume is a direct reflection of the host’s filesystem permissions and mount options. If the host path is read-only, the container sees it as read-only.

5. System-Level Read-Only Filesystem:

   • Diagnosis: In some hardened Linux environments, the root filesystem (/) or critical system directories might be intentionally mounted as read-only for security. If an application is trying to write to these system-level directories outside of a container context, or if a container is misconfigured to try and write to host system files directly, this error will occur. Check mount | grep ' / ' on the host.
   • Fix: This is usually a design choice. If an application must write to these locations, the system’s read-only configuration needs to be revisited, or the application needs to be reconfigured to write to a different, writable location (e.g., /var/log or a dedicated data volume). For containers, this would mean not trying to bind-mount host system directories that are read-only.
   • Why it works: The kernel enforces the read-only flag at the filesystem level. Writes are blocked at the VFS layer before they even reach the block device.

6. Corrupted Filesystem or Disk Issues:

   • Diagnosis: While less common for EROFS specifically (which implies a configured read-only state), a severely corrupted filesystem can sometimes present as read-only or cause write operations to fail in ways that might manifest as EROFS if the kernel can’t even establish a writable state. Check dmesg for disk errors or filesystem corruption messages. Run fsck on the relevant partition (when unmounted).
   • Fix: If fsck finds errors, it will attempt to repair them. If the underlying disk is failing, it will need replacement.
   • Why it works: Filesystem corruption can lead to unpredictable behavior, including the inability to open files for writing or to modify metadata, which the kernel might interpret as a read-only condition.

The next error you’ll likely encounter if you’ve fixed the EROFS issue but haven’t addressed the underlying application logic is a ENOENT (No such file or directory) if the application was trying to create a file that it expected to exist or be created in a writable location.