Fix "Read-only file system" on Linux

sudo dmesg -T | grep -iE 'read-only|remount|I/O error|EXT4-fs error|BTRFS'
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /
# no errors? remount:
sudo mount -o remount,rw /

The message usually looks like one of these:

touch: cannot touch 'file': Read-only file system
mkdir: cannot create directory 'x': Read-only file system
E: Could not open lock file /var/lib/dpkg/lock-frontend - open (30: Read-only file system)

What the error means

The filesystem holding that path is mounted read-only (EROFS). Either it was mounted that way on purpose (a live USB, a CD image, a snap's squashfs, an fstab entry with ro), or the kernel switched it to read-only at runtime because something went wrong. The second case is a warning sign: ext4's default errors=remount-ro behaviour protects your data when the disk or filesystem misbehaves. Check the current mount options:

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /

Example output:

TARGET SOURCE         FSTYPE OPTIONS
/      /dev/nvme0n1p2 ext4   ro,relatime,errors=remount-ro

If OPTIONS starts with ro on a filesystem that is normally writable, read the kernel log before doing anything else.

Cause 1: filesystem errors detected by the kernel

The most common cause. dmesg will contain lines like:

EXT4-fs error (device nvme0n1p2): ext4_lookup:1855: inode #2: comm ls: deleted inode referenced
EXT4-fs (nvme0n1p2): Remounting filesystem read-only

Fix it by running fsck on the unmounted filesystem. For the root filesystem that means booting a live USB of any distro, or the emergency shell (see emergency mode):

# from a live USB: identify the partition
lsblk -f
# ext2/3/4
sudo fsck -f /dev/nvme0n1p2
# XFS
sudo xfs_repair /dev/nvme0n1p2
# Btrfs: check first, read-only by default
sudo btrfs check /dev/nvme0n1p2

To force a check of the root filesystem at next boot instead, add fsck.mode=force to the kernel command line once (see kernel boot parameters).

Cause 2: the drive is failing

If dmesg shows I/O error, blk_update_request, critical medium error or NVMe resets, the hardware is the problem and fsck will only treat symptoms. Check SMART health (package smartmontools):

sudo smartctl -H /dev/nvme0n1
sudo smartctl -a /dev/sda | grep -iE 'reallocated|pending|uncorrect|crc'

Rising reallocated or pending sector counts mean: back up now and replace the drive. A rising UDMA_CRC_Error_Count on SATA usually points to a bad cable or port, not the disk. Loose USB enclosures and underpowered USB hubs cause the same symptom for external drives.

Cause 3: Windows partition (NTFS) locked by Fast Startup

For a dual-boot data partition, dmesg or the mount helper reports something like:

ntfs3: sda3: volume is dirty and "force" flag is not set!
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.

Boot Windows, turn off Fast Startup (Control Panel, Power Options, "Choose what the power buttons do") and shut down completely (hold Shift while clicking Shut down). If Windows is not available, sudo ntfsfix -d /dev/sda3 from the ntfs-3g package clears the dirty flag, but a Windows chkdsk is the proper repair.

Cause 4: mounted read-only on purpose

• fstab: an entry contains ro. Edit /etc/fstab and change it to defaults or rw.
• Emergency or recovery mode: root is mounted read-only so you can repair it. Use mount -o remount,rw / when you need to edit files.
• Snaps and images: paths under /snap, ISO files and squashfs are always read-only by design; copy files elsewhere to modify them.
• SD cards and USB sticks: some have a physical lock switch, and worn-out flash often switches itself permanently read-only. cat /sys/block/sdb/ro returning 1 means the device itself reports write protection.
• Immutable distros: Fedora Silverblue/Kinoite and other image-based systems keep /usr read-only. Use rpm-ostree, Flatpak or toolbox instead of writing there.

Cause 5: the disk filled up or a Btrfs went read-only

Btrfs switches to read-only when it hits a serious error, including running out of metadata space. Look for BTRFS: error ... forced readonly in dmesg. Check sudo btrfs filesystem usage / and sudo btrfs device stats /; if the cause was space, reboot (the filesystem stays read-only until remounted) and follow No space left on device.

Distro-specific notes

• Ubuntu, Debian, Mint: the installer sets errors=remount-ro on ext4 root. A failed check at boot drops you to an initramfs or emergency prompt; run fsck -y /dev/... there, then exit or reboot.
• Fedora: default Btrfs; use btrfs scrub and btrfs device stats rather than fsck, which is a no-op for Btrfs.
• openSUSE: Btrfs root with snapper. If the current snapshot is broken, boot an older one from the GRUB "snapshots" menu and run sudo snapper rollback.
• Arch: whatever you chose at install. The Arch Wiki page on fsck covers boot-time checks with systemd-fsck.

How to prevent it

• Keep backups so a read-only event is an inconvenience, not a disaster. See rsync home backup script.
• Enable smartd (sudo systemctl enable --now smartmontools on Debian/Ubuntu, smartd elsewhere) to get warnings before a drive fails.
• Always unmount or eject removable drives before unplugging them, and shut down instead of cutting power.
• On Btrfs, run a monthly scrub: sudo systemctl enable --now [email protected] on Arch (btrfs-progs), or the btrfsmaintenance package on openSUSE.

Still not working?

If remount fails with mount point is busy, see target is busy. If the remount succeeds but the filesystem goes read-only again within minutes, treat it as failing hardware: copy your data off with rsync or ddrescue and replace the drive. For partition-level work, see disk management.

Frequently asked questions