🚨 Linux Error Guide: 'Read-only file system' on Write-Protected Media — Clear the Protection

Overview

You plug in a USB stick or SD card, try to copy a file, and Linux refuses:

$ touch /mnt/usb/file
touch: cannot touch '/mnt/usb/file': Read-only file system

The kernel returns EROFS (error, read-only file system) for any write. The tricky part is that EROFS has two very different origins, and they need different fixes:

• The filesystem remounted itself read-only after detecting corruption or I/O errors. That is a software safety mechanism. If that is your situation — you saw EXT4-fs error and a Remounting filesystem read-only message in dmesg — read the companion guide: Read-only file system (EROFS) after filesystem errors.

• The media or block device is write-protected at a layer below the filesystem: a physical switch, a device-level read-only flag, a ro mount option, or flash hardware that has flipped itself to read-only because it is worn out. That is what this guide covers.

The distinction matters because a write-protected device will reject writes no matter how healthy the filesystem is. fsck won’t help, and in some cases the protection is the hardware telling you the media is dying and it is time to get your data off it.

Symptoms

• Any write fails with Read-only file system — touch, cp, mkdir, editors saving, package managers, log writes.
• mount -o remount,rw fails, often with mount: /mnt/usb: cannot remount ... read-write, is write-protected.
• dd or mkfs fails immediately or reports Operation not permitted / write errors on the raw device.
• The device mounts fine and reads perfectly — only writes fail.
• dmesg shows lines like Write Protect is on or protecting the mount.
• On a failing SSD/NVMe, the drive appears healthy for reads but every write errors, and SMART data shows exhausted endurance.

Common Root Causes

• Physical write-protect switch. Full-size SD cards and many USB sticks and adapters have a mechanical lock tab. If it is in the “lock” position, the card reader reports the media as write-protected to the OS. SD micro-to-full adapters are the usual culprit.
• Mounted read-only on purpose. The filesystem was mounted with -o ro (explicitly, via /etc/fstab, or by an automounter). Nothing is wrong with the hardware; the mount option is the whole story.
• Block device read-only flag set. Someone or something ran blockdev --setro on the device, or it was exported read-only. The kernel marks the whole block device read-only regardless of filesystem.
• hdparm read-only flag. hdparm -r1 sets a driver-level read-only flag on the device.
• Worn or failing flash forcing read-only. This is the important hardware case. USB flash controllers, SD cards, and SSDs use wear-leveling and spare blocks. When spare blocks are exhausted or the controller detects it can no longer safely write, many devices deliberately switch to a permanent read-only state so you can still recover existing data. The device is effectively end-of-life.
• Bad connector, cable, or card reader/adapter. A flaky reader or a cheap adapter can present the media as read-only or fail writes intermittently. Always rule out the adapter before condemning the media.

Diagnostic Workflow

Work from the mount layer down to the hardware. Replace /dev/sdb and /mnt/usb with your device and mount point.

1. Is it just a read-only mount?

mount | grep /mnt/usb
findmnt /mnt/usb
cat /proc/mounts | grep sdb

Look for ro in the options. If you see ro and the hardware is fine, a remount fixes it (covered below). findmnt is the clearest view:

findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS /mnt/usb

2. Is the block device itself read-only?

lsblk -o NAME,RO,RM,MOUNTPOINT
blockdev --getro /dev/sdb

In lsblk, the RO column is 1 when the device is read-only and RM is 1 for removable media. blockdev --getro returns 1 for read-only, 0 for read-write. A 1 here means the block layer is blocking writes above the filesystem entirely.

3. Check the driver-level hdparm flag.

hdparm -r /dev/sdb

This prints readonly = 0 (off) or readonly = 1 (on).

4. Ask the kernel what it saw.

dmesg | grep -iE 'write protect|read-only|protected|sdb'

On write-protected removable media you will often see:

sd 2:0:0:0: [sdb] Write Protect is on
sd 2:0:0:0: [sdb] Mode Sense: 23 00 80 00

The Write Protect is on line is the storage device reporting protection to the SCSI/USB layer — a strong signal the media or its switch, not Linux, is the source.

5. For SSD/NVMe, check wear and read-only mode with SMART.

smartctl -a /dev/sda

Watch for a media/wear indicator at or near end of life (for NVMe, Percentage Used at or above 100, Available Spare below the threshold, or Media and Data Integrity Errors). A drive that has entered read-only end-of-life protection has effectively no remaining endurance. For NVMe you can also use:

nvme smart-log /dev/nvme0

Example Root Cause Analysis

A 64 GB USB stick used for shipping backups suddenly rejects writes. The filesystem mounts and reads fine, but cp fails with Read-only file system.

Check the mount and the device flags:

$ findmnt /mnt/usb
TARGET   SOURCE    FSTYPE OPTIONS
/mnt/usb /dev/sdb1 vfat   ro,nosuid,nodev,relatime,...

$ lsblk -o NAME,RO,RM,MOUNTPOINT
NAME   RO RM MOUNTPOINT
sdb     1  1
└─sdb1  1  1 /mnt/usb

$ blockdev --getro /dev/sdb
1

The whole device shows RO=1. This is not a filesystem error — the block device is read-only. Two explanations remain: a physical switch, or the flash controller flipped itself read-only.

Rule out the easy one first. Unmount, check the physical lock switch on the stick or SD adapter, reseat it in a different reader, and re-plug:

$ umount /mnt/usb
# flip the lock tab off, reinsert
$ blockdev --getro /dev/sdb
1

Still 1, with the switch off and a known-good reader. Now check the kernel and SMART-style signals:

$ dmesg | grep -iE 'write protect|sdb'
sd 6:0:0:0: [sdb] Write Protect is on

The device itself is asserting write protection even with no physical switch engaged. For a USB stick with no lock and no blockdev/hdparm flag set by us, that means the flash controller has entered its end-of-life read-only mode after wear. Attempting blockdev --setrw /dev/sdb will either be rejected or the very next write will fail again, because the protection is enforced in the device firmware, not by Linux.

Conclusion: the media is worn out. The correct action is data recovery, not repair — read everything off it now while reads still work, then replace it:

# pull a full image while the device is still readable
dd if=/dev/sdb of=/backup/sdb-recovery.img bs=4M conv=noerror,sync status=progress

Then retire the stick. If instead blockdev --getro had returned 1 only because someone ran --setro, or hdparm -r showed readonly = 1, clearing the flag (below) would have restored writes cleanly — that is the benign case.

Prevention Best Practices

• Check switches first. Before assuming failure, verify the physical lock tab on SD cards and adapters. It is the single most common cause of surprise write protection.
• Buy quality media. Cheap no-name USB sticks and SD cards wear out fast and are the most likely to flip read-only. Use reputable brands with real endurance ratings for anything you write to repeatedly.
• Don’t rely on flash for durable writes. USB sticks and SD cards are transfer and boot media, not primary storage. Keep the authoritative copy on redundant, monitored disks and treat flash as disposable.
• Back up flash proactively. Because worn flash often gives no warning before going read-only (and read-only means you can still recover), image important cards/sticks periodically rather than after a failure.
• Monitor SSD/NVMe wear. Track Percentage Used, Available Spare, and reallocated/wear counters with smartctl or nvme smart-log, and replace drives before they hit end-of-life read-only protection. Wire it into your monitoring so you get alerted, not surprised.

Quick Command Reference

# Inspect
findmnt /mnt/usb                          # show mount options (look for ro)
lsblk -o NAME,RO,RM,MOUNTPOINT            # RO=1 means block device is read-only
blockdev --getro /dev/sdb                 # 1 = read-only, 0 = read-write
hdparm -r /dev/sdb                        # show driver read-only flag
dmesg | grep -iE 'write protect|read-only'

# Clear a *software* read-only flag (only when hardware is healthy)
blockdev --setrw /dev/sdb                 # clear block-device read-only flag
hdparm -r0 /dev/sdb                       # clear hdparm read-only flag

# Remount a read-only mount as read-write
mount -o remount,rw /mnt/usb

# If protection is in firmware (worn flash) — recover, don't repair
dd if=/dev/sdb of=/backup/sdb-recovery.img bs=4M conv=noerror,sync status=progress

Conclusion

When Linux says Read-only file system on removable or flash media, resist the urge to reach for fsck. Diagnose which layer is blocking writes: a mount option (findmnt shows ro), a block-device flag (blockdev --getro / lsblk RO=1), an hdparm flag (hdparm -r), or the hardware itself (dmesg Write Protect is on, exhausted SMART endurance). Software flags clear cleanly with blockdev --setrw, hdparm -r0, or mount -o remount,rw. But when the protection is a physical switch you can’t override in software, or firmware-enforced read-only on worn flash, the device is telling you the truth — flip the switch or, for end-of-life flash, recover your data and replace the media.

If your filesystem instead went read-only because the kernel detected corruption or disk errors, that is a different failure mode — see Read-only file system (EROFS) after filesystem errors for the recovery path.