Everything is working as usual except the disk is read-only and don't want to change back.


root@NODE02:/tmp# df .
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda5            461490504 179502128 258545928  41% /

root@NODE02:/tmp# mount -o rw,remount /dev/sda5
mount: cannot remount block device /dev/sda5 read-write, is write-protected

root@NODE02:/tmp# touch helll
touch: cannot touch `helll': Read-only file system

It's not multipath. It's nothing special. Just a server with ubuntu 9.10.

makes no sense for me, does it?


Selinux is not active.

There is no RAID. There are 2 discs, 500Gb each one. First one for OS and some homes. The second one for distributed FS, HPC high performance.

Dmesg was not updated since 2 days ago. Nothing on its last lines related to disc or errors.

Rebooted, and no hard drive found. From bios, the hard drive is dead, not responding even to name queries.

New hard drive is needed. thanks.

  • Not selinux getting in the way?
    – Jason Tan
    Feb 8, 2011 at 14:58
  • I'm affected with a different scenario: A VM using a loop-mounted sparse disk image had write errors when the host's underlying filesystem went full. Two things interesting: 1) Filesystem was set read-only even though the filesystem error-behavior was set to "continue" 2) remount read-write fails with the same message ("is write-protected") even after the host's filesystem had been extended.
    – U. Windl
    Nov 3, 2021 at 7:58

4 Answers 4


I'm afraid this is due to corruption on the filesystem or problems on the underlying hardware, since it's the root filesystem my recommendation is to boot the server again with a rescue disc (or in single user mode) and try to repair the disk through fsck.

  • Check what dmesg says to confirm the corruption
  • Run fsck to repair the hard drive, as soon as fsck is run reboot immediately to avoid any issues

Hola Marc,

Em temo que aixo es un sintoma de corrupcio al sistema de fitxers o de problemes del hardware subjacent, com es el / lo que et recomano es de rebotar el servidor amb un CD de rescat e intentar reparar el disc amb fsck.

  • Mira que diu la comanda dmesg nomes per corroborar que hi ha corrupcio
  • Executa fsck per reparar el teu disc, en quan acabi rebota inmediatament per preveure qualsevol altre tipus de problema

Bona sort!

  • How did you know I speak catalan? Did we met?
    – Marc Riera
    Feb 9, 2011 at 12:51
  • 1
    It's just your name, I'm named Marc as well :)
    – lynxman
    Feb 9, 2011 at 13:11
  • I just came back to see a new respose, and then I saw this again. How are you doing?
    – Marc Riera
    Feb 29, 2016 at 9:06
  • 1
    @marc.riera I'm not fine, because of this error. but thanks though Jul 13, 2016 at 21:49

I've seen this before when a RAID card went bad, and the ext3 journal file couldn't be written to. At that point, the kernel marked the root FS read-only and wouldn't allow it to go back.

Nothing was logged about this, because of course the /var FS was on the same disc, and also RO. dmesg, however, was pleased to tell us about the problem. So, can you do a dmesg and tell us about the output?

In our case, the only fix was to power-cycle to wake up the RAID card, then reboot from rescue media and fsck the file system.


I had this, and it was an OOM (Out Of Memory / Kernel Panic), I found this when I checked dmesg for any issues with the volume after already trying 'mount -o remount,rw /' and getting an error saying the disk was write-protected, when I found the OOM in dmesg, I rebooted and the volume was read-write once again.


I solved this problem in Arch Linux by installing "NTFS filesystem driver and utilities" using this:

sudo yaourt ntfs-3g
  • wat. ntfs is a different file system than ext-fs which I have. Jul 13, 2016 at 21:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .