Read-Only File System
Production Risk
HIGH — can indicate disk failure when the kernel auto-remounts ro. Check dmesg immediately.
EROFS (errno 30) is returned when a write operation is attempted on a filesystem that is mounted read-only. This can also occur when trying to write to files in a container with a read-only root filesystem.
- 1The filesystem was mounted with the ro option
- 2The disk is failing and the kernel automatically remounted it read-only to prevent corruption
- 3Container has a read-only root filesystem (common in production containers)
- 4Writing to a CD-ROM or other read-only media
Writing to a filesystem mounted read-only.
# Write to a read-only mount: echo "data" > /mnt/readonly/file.txt # bash: /mnt/readonly/file.txt: Read-only file system
expected output
write: Read-only file system (EROFS)
Fix 1
Remount the filesystem read-write
WHEN When the filesystem should be writable and was not intentionally mounted read-only
sudo mount -o remount,rw /mnt/myfs # Or check if disk errors triggered automatic ro remount: dmesg | grep -i "remount|read-only|error"
Why this works
Disk errors cause automatic ro remounting to prevent corruption. Check dmesg for I/O errors before remounting — the underlying disk may need fsck.
Fix 2
Use a writable overlay or volume in containers
WHEN When running in a container with read-only rootfs
# Docker: mount a writable volume for mutable data docker run -v /host/data:/app/data myimage # Or use tmpfs for ephemeral writes: docker run --tmpfs /tmp myimage
Why this works
Read-only rootfs containers need writable volumes for any mutable state. Use named volumes or tmpfs mounts for paths that need write access.
✕ Remount a disk read-write after I/O errors without running fsck first
Mounting a corrupted filesystem read-write can worsen corruption. Always run fsck on an unmounted filesystem first.
Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev