30

I want to force a disk partition to read only mode and keep it read-only for more than 30 minutes.

What I have tried:

  1. mount -o remount,ro (partition-identifier) (mount-point) -t (filesystem)

    Issue: This gave device busy error as some processes were using the partition. I don't want to kill the processes using the disk. I want to simulate the disk suddenly going read-only when the processes are still using it.

  2. Used magic sysrq key, like below

    echo u > /proc/sysrq-trigger
    

    Issue: This will make all the disk partitions read-only (although device is busy). But after 20-30 minutes the machine is rebooting itself. Some machines are rebooting immediately once this command is executed. Not sure what is causing this reboot yet. I don't want the machine to reboot itself and need to keep the disk in read-only mode for 30+ minutes.

Question: Is there any better way I can force a single disk partition to read-only and sustain it in that state for half an hour and bring it back to read-write mode without causing any reboot in the process?

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
AdithyaCS
  • 401
  • 1
  • 4
  • 4
  • 4
    Have you considered `fsfreeze -f`? It doesn't exactly remount the filesystem read-only. Instead, it blocks all writers until `fsfreeze -u`. But it's similar... – Celada Apr 08 '15 at 09:30
  • Thanks Celada! that's a good idea!.. Right now i don't have fsfreeze working in my machine but i will try this. – AdithyaCS Apr 08 '15 at 09:59
  • I tried `fsfreeze -f` and it my case it was more "os freeze". Maybe because writes were blocked instead of being rejected? – Piotr Findeisen May 07 '17 at 11:40
  • 1
    `fsfreeze` turned my system inaccessible and I could not enter the unfreeze command not being able to switch back to a terminal and had to hard-reboot my machine. **So be warned**! :) – Alex Aug 12 '18 at 21:19

2 Answers2

25

You normally can't remount a filesystem as read-only if processes have a file on it that's open for writing, or if it contains a file that's deleted but still open. Similarly, you can't unmount a filesystem that has any file open (or similar uses of files such as a process having its current directory there, a running executable, etc.).

You can use umount -l to release the mount point and prevent the opening of further files, but keep the filesystem mounted and keep processes that already have files open running normally.

I can't think of a generic way to force a filesystem to be remounted read-only when it shouldn't be. However, if the filesystem is backed by a block device, you can make the block device read-only, e.g.

echo 1 >/sys/block/dm-4/ro
echo 1 >/sys/block/sda/sda2/ro

echo u > /proc/sysrq-trigger is a rather extreme way to force remounting as read-only, because it affects all filesystems. It's meant as a last-ditch method to leave the filesystem in a clean state just before rebooting.

Remounting a filesystem as read-only does not cause a reboot. Whatever is causing the reboot is not directly related to remounting the partition as read-only. Maybe it's completely unrelated, or maybe this triggers a bug in the application which causes it to spin and make the processor overheat and your processor is defective or overclocked and eventually reboots. You need to track down the cause of the reboot.

Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
5

Use mount's force option (assuming your mount has one; GNU mount does not, but BSD and macOS for example do):

mount -f -o remount,ro /mount/point

Of course, your mileage may vary depending on actual file system, kernel version and situation, so this is just higher level option trying other lower-level tricks as e.g. mentioned by @Gilles.

Piotr Findeisen
  • 191
  • 1
  • 4
  • The force option only works with NFS. – psusi May 07 '17 at 02:59
  • 1
    @psusi no. It allowed me remount my ext4 `/` partition. – Piotr Findeisen May 07 '17 at 10:58
  • 3
    Turns out I was thinking of `umount -f`, but I just tried remounting to ro, and while the -f makes the command not return an error, the filesystem is in fact, not made read only. – psusi May 08 '17 at 00:29
  • 1
    @psusi, no surprise. I wouldn't expect any single approach to work in all cases. This worked for me repeatably (ext4 root partition on raspberry for the matter) -- and i mean _remounting_ to RO, not _ignoring_ errors -- so I guess will work for some, but not all, other cases. Sorry this didn't include yours. – Piotr Findeisen May 09 '17 at 06:32
  • Since it's the same kernel and filesystem, I highly doubt that you magically got different results.. you probably just did not try to write to the filesystem after the remount, or no files were open for write access at the time, in which case the -f was not needed. – psusi May 09 '17 at 21:43
  • Yea, that surely concludes the proof I'm wrong. Congratulations. – Piotr Findeisen May 11 '17 at 07:08
  • That would be done by you trying it again and seeing if you can actually touch a file after the remount. – psusi May 13 '17 at 01:46
  • 23
    [man mount](https://linux.die.net/man/8/mount) says `-f` is `--fake`. Quote: "Causes everything to be done except for the actual system call; if it's not obvious, this ''fakes'' mounting the filesystem. This option is useful in conjunction with the -v flag to determine what the mount command is trying to do. It can also be used to add entries for devices that were mounted earlier with the -n option. The -f option checks for existing record in /etc/mtab and fails when the record already exists (with regular non-fake mount, this check is done by kernel)." – Will Manley Dec 14 '17 at 19:38
  • 1
    @WillManley that's pity that `-f` is not consistent, but my `man mount` says `-f Forces the revocation of write access when trying to downgrade a filesystem mount status from read-write to read-only.` – Piotr Findeisen Jun 01 '18 at 11:09
  • 7
    BSD and, therefore, macOS mounts' `-f` [does indeed](https://www.freebsd.org/cgi/man.cgi?mount(8)) mean "force". – terdon Sep 17 '18 at 08:45