Linux system errors
Read-Only Filesystem
Reviewed for reference consistency: August 11, 2026
the mount itself refuses writes, so permission changes cannot help
What 30 Means
The 30 error on the Linux system errors indicates read-only filesystem — the mount itself refuses writes, so permission changes cannot help. This typically occurs due to a filesystem mounted explicitly read-only (optical media, recovery mode, hardened containers).
Exit code 30 corresponds to EROFS, 'Read-only file system'. The refusal sits at the mount level, above any per-file permission: the whole filesystem was mounted without write access, so no ownership change, no chmod, and no correct user can write through it. The question is never 'who is allowed' but 'why is the mount read-only'.
How to fix 30
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Show the mount's options
findmnt prints the target's mount options directly; ro among them confirms the mount-level refusal.
findmnt -o TARGET,SOURCE,OPTIONS /path/to/mountCross-check the mount table
The classic mount listing shows the same read-only flag with source device context.
mount | grep ' /path/to/mount 'Look for error-driven remounts
The kernel log records I/O errors and any emergency read-only remount, revealing whether the flag was chosen or forced.
dmesg -T | grep -i remount
Technical Background
EROFS is decided at the mount, not at the file. Unix permissions form a per-file layer — owners, groups, mode bits — but above that sits the mount's own access mode. When a filesystem is mounted read-only, that setting outranks everything beneath it: root gets the same refusal as an anonymous user, and chmod becomes a no-op theater.
Some read-only mounts are deliberate architecture. Container image layers are immutable so many containers can share one base; recovery modes mount disks read-only to avoid worsening whatever went wrong. In these cases exit 30 is the design working, and the write belongs somewhere else by definition.
The unsettling variant is the surprise remount: a healthy write path starts failing system-wide because the kernel, after disk errors, scaled back to read-only to limit damage. Here EROFS is a symptom of hardware trouble, and the kernel log — not the mount table alone — tells the story.
Common Causes
- A filesystem mounted explicitly read-only (optical media, recovery mode, hardened containers)
- The kernel remounting a filesystem read-only after detecting disk errors
- A container's layered root filesystem, where image layers are read-only by architecture
Typical Scenarios
- A container process attempting to write into its image layers, which are read-only by design
- A system disk remounted read-only by the kernel after I/O errors, with writes failing system-wide
- A recovery or single-user mode where disks are intentionally mounted read-only for safety
What to Know
The mount table answers the state question in one line: which options the filesystem was mounted with. When the read-only flag appeared without anyone choosing it, the kernel log's error and remount entries supply the timeline.
Frequently Asked Questions
Common questions about Linux 30 error
Permissions are evaluated per file, below the mount's read-only flag (exit 30). When the mount itself refuses writes, no identity or mode bits change the outcome — the mount option is the decision that matters.
The usual trigger is the kernel's error response: on disk I/O errors it may remount the filesystem read-only to prevent further damage. The kernel log records both the errors and the remount decision with timestamps.
13 (EACCES) is a permission verdict on a writable filesystem — identity and mode bits decide. 30 (EROFS) is a mount-level property that outranks both. Same write, two entirely different ceilings.
Related Error Codes
No Space Left — the filesystem ran out of data blocks or of inodes
Permission Denied — the process does not have permission to access the resource
Resource Busy — the target exists, but another holder refuses to release it right now
No Such Device — the operation targets hardware or a driver that is not present
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Git paused the merge because it cannot automatically resolve overlapping changes.
Git aborted the merge to protect uncommitted changes in your working directory.
Git prevented a branch switch because it would overwrite unsaved changes in your working directory.
Git aborted the merge because it would overwrite untracked files in your working directory.