CI "Read-only file system" (EROFS) - Why Writes Fail on Runners
A write failed with EROFS - the target filesystem is read-only. Either you wrote to a path that is mounted read-only by design, or the kernel remounted a filesystem read-only after detecting disk errors, which is the more serious case.
What this error means
A step fails with Read-only file system when creating or modifying a file. Sometimes the path was always read-only (a read-only volume or container layer); sometimes a previously-writable disk flipped to read-only mid-job after an I/O error.
cp: cannot create regular file '/opt/app/config': Read-only file system
# or, after a disk error, dmesg shows:
EXT4-fs error ... Remounting filesystem read-onlyCommon causes
Writing to a read-only mount or layer
A container’s image layer, a read-only volume, or a path like /usr mounted read-only rejects writes by design. The fix is to write to a writable path (a mounted volume, $RUNNER_TEMP, the workspace).
The kernel remounted the filesystem read-only after an I/O error
On detecting filesystem corruption or a failing disk, the kernel remounts read-only to prevent further damage. This is a transient infrastructure fault - a fresh runner with a healthy disk recovers.
How to fix it
Determine why it is read-only
Check the mount flags and the kernel log to tell a by-design read-only mount from a fault remount.
mount | grep -E ' ro,| ro '
dmesg -T | grep -i -E 'remounting filesystem read-only|ext4-fs error|i/o error'Act on the cause
- By-design read-only path: write to a writable location (workspace,
$RUNNER_TEMP, a mounted volume). - Fault remount (dmesg shows I/O errors): retry on a fresh runner - the disk is unhealthy, not your code.
- For containers, mount a writable volume for paths the job must write.
How to prevent it
- Write only to known-writable paths (workspace, temp, mounted volumes).
- Treat a mid-job read-only remount as a hardware/infra fault and move runners.
- Mount writable volumes for any container path the job updates.