3

My home partition went read-only. I believe this was after trying to access a file that was damaged. I am trying to re-mount it as write with mount -o remount,rw /. But get the message: sudo: unable to open /var/lib/sudo/qfean/12: Read-only file system mount: cannot remount block device /dev/sda3 read-write, is write-protected

I also tried to change the file 12 above to +w, but I couldn't because the system was read-only.

In /etc/fstab home partition is mounted with the option errors=remount-ro.

2

The only way I know to remount / (root) partition is to restart the computer. But before this you should check what is the reason for this effect (/ to become r/o)

  • I am pretty sure it was after trying to access a damaged file. – Quora Feans Feb 4 '15 at 19:47
  • @QuoraFeans, for me this mean the harddisk probably have bad sector. Try to reboot, rename the file and restore it from backup – Romeo Ninov Feb 4 '15 at 19:48
1

Files rarely get damaged by themselves. Usually, damage in the filesystem is the result of an underlying hardware error. The message

mount: cannot remount block device /dev/sda3 read-write, is write-protected

indicates that the kernel detected a hardware error, and to prevent further data corruption, it marked the underlying device read-only. Making the filesystem read-only was a side effect of this.

You can't switch the filesystem back to being read-write because the block device is still read-only. You can make the block device read-write with blockdev --setrw /dev/sda3, and then remount the filesystem read-write. However this is a bad idea, as is rebooting and continuing to use the disk. Don't ignore this error: your hardware is failing and your data is going to get more and more corrupted.

Check the kernel logs for some clues about the error. You should be seeing a flurry of log messages. Kernel logs are often stored in /var/log/kern.log but the location depends on the distribution and on the system configuration, so check your distribution's documentation. You can call the command dmesg to print the kernel logs, but only for the current session, you'll need to view the log files for messages from before the latest reboot.

Common causes for disk failure include failure of the actual disk, a loose cable, or a RAM failure. Run smartctl -a /dev/sda to view disk diagnostics. If that doesn't indicate that anything is failing, run memtest86+ to check your RAM.

  • Checked these, but didn't find anything. The HDD is not that old (2 years) and damaged files only appeared twice, and both were big files that were transfered from a NTFS partition. I suppose the problem is more a Windows partition thing. – Quora Feans Feb 5 '15 at 18:20
  • Try booting the system with a live-cd (rescue system) and run a fschk on the failed partition in "read only first", afterward in full -mode to regain write access. Checking smartctl output at first (see gilles answer) is a good idea. – gerhard d. Aug 7 '15 at 11:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.