ext4 enters emergency read-only protection · Linux Fix Lab

Symptoms & scope

Applications suddenly receive Read-only file system when saving.
ext4 reports filesystem errors or a read-only transition.

Relevant environment

ext4 filesystems using errors=remount-ro or forced journal error handling; behavior varies with kernel version.

Recognizable messages (synthetic examples)

EXT4-fs error (device sda2): ext4_lookup:1850: inode #41: comm app: deleted inode referenced: 52

Investigate the first error and preserve data; one line cannot distinguish software, memory and storage causes.

EXT4-fs (sda2): Remounting filesystem read-only

Later write failures are expected consequences. Visible mount flags can lag the internal emergency state on relevant kernels.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

Metadata inconsistency or failed journal I/O can trigger protection; earlier block-device errors may reveal the underlying cause.
An intentionally read-only mount is a separate configuration case unless ext4 error handling is also recorded.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read the current-boot kernel log with journal privileges if required. Locate the first ext4 and block I/O failure.

journalctl -k -b --no-pager -n 400

Interpret the result: The first metadata or journal error is more useful than later EROFS messages. Repeated SATA/NVMe faults require storage-path repair before filesystem repair.

Check 2

Replace /affected/path with an existing path on the affected filesystem. This reads mount information without changing it.

findmnt -T /affected/path -o TARGET,SOURCE,FSTYPE,OPTIONS

Interpret the result: Confirm ext4 and the source device. Some kernels maintain internal emergency read-only protection while rw remains visible; journal evidence must accompany the flags.

Evidence-guided next steps

Stop writes and investigate the backing device

If ext4 activated protection, stop affected applications and preserve readable data to another device. Resolve recurring drive, power or transport failures before any metadata-changing repair.

Precautions: Do not use errors=continue or repeated remount-rw attempts to bypass a protective failure. A normal ro mount may replay a journal; recovery copies need deliberate handling.

Recovery / rollback: Restore services only after device stability and filesystem consistency have been established. Recover damaged files from a known-good backup.

Did this solution help you?

Share this solution #

Plan an offline ext4 check

Once data is secured and the storage path is stable, use recovery media to unmount the affected filesystem and review an e2fsck no-modify assessment before approving repairs. Root filesystems need a separate boot environment.

Precautions: Never repair a mounted filesystem. Verify the device or mapper path, and work on an image first when data is irreplaceable.

Recovery / rollback: Filesystem repair is not reliably reversible; retain the image or backup and restore from it if recovery produces unacceptable results.