When Your USB Drive Refuses to Let You Write
I know that sinking feeling. You plug in a USB drive, drag a file over, and get hit with a wall of text about a read-only file system. Maybe it worked on Windows yesterday. Maybe it worked on this machine last week. Either way, you're stuck. Let's fix it right now.
The Fix: Remount with Write Permissions
This is almost always a mount flag issue. The drive is mounted read-only because of a dirty filesystem or a forced safe mode. Here's the command that works 9 times out of 10:
sudo mount -o remount,rw /dev/sdb1 /media/yourusername/DRIVELABELReplace /dev/sdb1 with your actual device and /media/yourusername/DRIVELABEL with the mount point shown when you run lsblk or mount. If you don't know the mount point, just run this first:
lsblk -fThat lists all drives with their filesystem types and mount points. Look for your USB drive—usually sdb1, sdc1, or similar. Then run the remount command above.
If that fails with a message saying the device is busy, unmount it first and remount with write permissions from scratch:
sudo umount /dev/sdb1
sudo mount -o rw /dev/sdb1 /media/yourusername/DRIVELABELWhy Linux Does This (and It's Not Broken)
Linux mounts USB drives read-only when it detects a potential filesystem issue—like the drive wasn't ejected properly from Windows or macOS, or it's formatted with NTFS and didn't fully unmount. This is a safety feature, not a bug. The system assumes you'd rather lose write ability than lose data from a corrupted drive.
But that assumption is annoying when the drive is fine. The remount,rw flag tells the kernel to switch the mount from read-only to read-write without losing the active file handles. It works for ext4, NTFS, FAT32, exFAT—any filesystem supported by the kernel.
When the Simple Remount Fails
If the remount command gives you an error like mount: /mountpoint: cannot remount ... is busy, you have a process actively using the drive. Find it with:
sudo lsof +D /media/yourusername/DRIVELABELClose the offending program (often a file manager window or terminal open inside that folder), then try again.
Another variation: NTFS drives with Windows's Fast Startup enabled. Windows leaves the filesystem in a state Linux respects as dirty. You can bypass this with:
sudo mount -t ntfs-3g -o rw,uid=1000,gid=1000 /dev/sdb1 /media/yourusername/DRIVELABELThis forces NTFS-3G to write even if the drive appears dirty. It works, but it's a slight risk—if Windows really did leave something hanging, you could corrupt the filesystem. I've done this hundreds of times without issue on drives that were cleanly unmounted on Windows.
For exFAT drives, a similar approach works:
sudo mount -t exfat -o rw,uid=1000,gid=1000 /dev/sdb1 /media/yourusername/DRIVELABELIf none of that works, the drive might genuinely have physical errors or a corrupted partition table. Run sudo dmesg | tail after plugging it in. If you see I/O errors, the drive is failing. Time to recover data, not fight permissions.
Preventing This Next Time
Three things you can do right now to stop the read-only lock from coming back:
- Always eject safely — use the eject button in your file manager or run
sudo umount /dev/sdb1before unplugging. Yanking the USB while files are open triggers the dirty flag on the next plug. - Disable Fast Startup on Windows — if you dual-boot or share drives with Windows machines, turn off Fast Startup in Windows Power Options. It's a checkbox labeled "Turn on fast startup" under "Choose what the power buttons do." Kill it.
- Check the filesystem once in a while — run
sudo fsck /dev/sdb1on unmounted ext4 drives, orsudo ntfsfix /dev/sdb1for NTFS. This clears minor corruption that triggers the read-only mode.
One last thing: if you're using a cheap USB stick that's a few years old, it might just be dying. I've replaced four Sandisk Cruzer Blades over the past year that started showing this exact behavior. If the remount works but the problem keeps coming back, buy a new drive. It's not worth the hours of troubleshooting.