You hit save and the terminal fights back
You are editing a configuration file. You type sudo nano /etc/hostname. You save. The terminal prints Read-only file system. You try dnf upgrade. It aborts with Error: Could not open lock file /var/lib/rpm/.rpm.lock: Read-only file system. The system is locked down. Your hands freeze.
The system isn't broken yet. The kernel has drawn a line in the sand. It detected something wrong with the storage and switched the filesystem to read-only mode to prevent further corruption. This is a safety feature. The kernel is the guardian. It saw a problem and closed the door to protect your data.
Run journalctl -xe first. Read the actual error before guessing.
What the kernel is doing
The kernel mounts filesystems when the system boots. It reads the superblock, checks the journal, and maps the data structures. If the kernel sees an inconsistency, it can no longer guarantee that writes will land where they should. Writing to a corrupted filesystem can destroy metadata, orphan files, or wipe the journal.
The kernel remounts the filesystem as read-only. This stops all writes. You can still read files. You can still run commands. You just cannot modify anything on that partition. This state is often called "read-only remount."
The trigger is usually one of three things:
- The filesystem journal detected an error during replay after a crash.
- The kernel encountered a hardware I/O error while reading or writing.
- A filesystem driver found corruption during a routine operation.
The kernel logs the reason. The log entry tells you whether the issue is a software glitch, a filesystem bug, or a failing disk.
Convention aside: Fedora Workstation defaults to Btrfs. Btrfs handles errors differently than Ext4 or XFS. Btrfs uses checksums for both data and metadata. If a checksum fails, Btrfs may remount read-only or attempt to heal the data from a duplicate copy. Check the filesystem type before choosing a repair tool.
Check the logs for the trigger
The kernel prints the reason for the remount in the system log. The message usually appears right before the Read-only file system errors start.
Here's how to find the kernel messages that explain the switch.
# Show recent kernel messages to locate the error that triggered the remount
journalctl -k --no-pager | tail -n 30
Look for lines containing EXT4-fs error, XFS: Corruption detected, Btrfs: error, or I/O error. The message often includes the device name, like sda2 or nvme0n1p3.
If you see I/O error, the storage hardware is likely failing. If you see journal recovery failed or inconsistency detected, the filesystem metadata is damaged.
Here's how to check the full journal for context around the boot time.
# Display the journal from the current boot with explanatory text
journalctl -b -xe
The x flag adds explanatory text for priority messages. The e flag jumps to the end. Scroll up to find the first error. The first error is usually the cause. Later errors are symptoms.
Run dmesg to see kernel ring buffer messages that might not be in the journal.
# Print the kernel ring buffer to catch low-level storage errors
dmesg | grep -i error
Check the logs before you touch the filesystem. Repairing a healthy filesystem can introduce errors.
Try the remount command
If the error appeared after a minor glitch, the filesystem might be clean but stuck in a read-only state. A remount command can restore write access without a reboot.
Here's how to remount the root filesystem as read-write.
# Remount the root filesystem with write permissions
sudo mount -o remount,rw /
The -o remount,rw option tells the kernel to change the mount options without unmounting. If the command succeeds, the filesystem is writable again. Save your work and reboot. A reboot forces a clean mount and clears transient states.
If the command fails, the kernel refuses the remount. The filesystem is marked dirty or corrupted. You need a filesystem check.
Remount first. If the kernel refuses, the damage is deeper than a flag.
When remount fails: Rescue and repair
A filesystem check requires the filesystem to be unmounted. You cannot run a check on the root filesystem while the system is running. You need a rescue environment.
Fedora provides a rescue target. The rescue target boots the system but drops you to a root shell. The root filesystem is mounted read-only by default.
Here's how to enter rescue mode.
# Reboot into rescue mode to access a root shell with the filesystem unmounted
sudo systemctl rescue
The system reboots. You get a login prompt. Log in as root. No password is required in rescue mode.
If systemctl rescue doesn't work because the root filesystem is read-only and you can't run commands, edit the GRUB boot entry.
Here's how to interrupt the boot process for manual repair.
# Add rd.break to the linux line in GRUB to drop to a shell before root mounts
linux /vmlinuz-6.8.0-... root=UUID=... ro rd.break
Press e at the GRUB menu. Find the line starting with linux. Add rd.break at the end. Press Ctrl+X to boot. You get a shell with the root filesystem not yet mounted.
Once you are in the rescue shell, identify the root device.
# List block devices to find the root partition device name
lsblk -f
Note the device name, like /dev/vda2 or /dev/nvme0n1p3. Run the filesystem check tool for that filesystem type.
Backup before repair. A repair tool can make a bad filesystem worse.
Filesystem checks by type
Fedora supports multiple filesystems. Each filesystem has its own repair tool. Using the wrong tool can destroy data.
Ext4
Ext4 is common on servers and older Workstation installs. The tool is fsck.ext4 or e2fsck.
Here's how to check and repair an Ext4 partition.
# Run a filesystem check on the Ext4 partition, automatically fixing errors
sudo fsck.ext4 -y /dev/vda2
The -y flag answers yes to all prompts. This fixes errors automatically. Review the output for warnings. If fsck reports it cannot fix errors, the damage is severe.
XFS
XFS is the default for Fedora Server. The tool is xfs_repair. XFS does not have a simple fsck wrapper.
Here's how to repair an XFS partition.
# Repair the XFS filesystem on the specified device
sudo xfs_repair /dev/vda2
If xfs_repair finds a corrupted log, it may need the -L flag to force log zeroing. This can lose recent data. Only use -L if the standard repair fails and you have no other option.
Btrfs
Btrfs is the default for Fedora Workstation. Btrfs uses btrfs scrub for integrity checks and btrfs check for deep repairs.
Here's how to run a scrub to verify data integrity.
# Start a scrub to check all data and metadata against checksums
sudo btrfs scrub start /dev/vda2
The scrub reads every block and compares it to the stored checksum. If a mismatch is found and a duplicate copy exists, Btrfs heals the data automatically.
Here's how to check the scrub status.
# Show the results of the last scrub operation
sudo btrfs scrub status /dev/vda2
If the scrub reports errors, run btrfs check for deeper analysis. btrfs check is read-only by default. It does not modify the filesystem.
Trust the checksums. Btrfs scrub fixes silent bit rot automatically.
Check the hardware
If filesystem errors recur after repair, the storage hardware is likely failing. A bad disk causes I/O errors. The kernel sees the errors and remounts read-only. Repairing the filesystem won't help. The disk will cause more errors.
Here's how to check the SMART health status of the drive.
# Check SMART health to detect failing disk hardware
sudo smartctl -H /dev/vda
The -H flag prints a simple PASSED or FAILED status. If the status is FAILED, replace the drive immediately.
Here's how to view detailed SMART attributes.
# Display detailed SMART attributes to spot reallocated sectors or pending errors
sudo smartctl -a /dev/vda
Look for Reallocated_Sector_Ct, Current_Pending_Sector, or Offline_Uncorrectable. Non-zero values indicate physical damage.
Replace the drive when SMART reports failing health or errors recur after repair.
Common pitfalls
SELinux denials look like permission errors, not read-only errors. SELinux prints Permission denied or AVC messages. The filesystem remains writable. Check journalctl -t setroubleshoot for SELinux issues. Do not disable SELinux for a read-only filesystem error.
Docker and Podman use overlay filesystems. If the overlay storage driver fails, containers may report read-only filesystem errors. The host filesystem is fine. Check the container runtime logs.
Forcing writes on a corrupted filesystem destroys data. Never use mount -o remount,rw to bypass errors and continue working. The kernel locked the filesystem for a reason. Fix the root cause.
Editing /etc/fstab does not fix a runtime read-only error. fstab controls boot-time mounts. The kernel has already mounted the filesystem. Changes to fstab take effect on the next reboot.
Decision matrix
Use mount -o remount,rw when the error appeared after a minor glitch and the system is otherwise stable.
Use fsck.ext4 or e2fsck when the remount fails and the filesystem is Ext4.
Use xfs_repair when the remount fails and the filesystem is XFS.
Use btrfs scrub when you suspect silent data corruption on a Btrfs volume.
Use btrfs check when the scrub reports errors and you need a deep analysis.
Replace the drive when SMART reports failing health or errors recur after repair.
Use rd.break when the system cannot boot into rescue mode due to root filesystem errors.