Remount a busy disk to read-only mode











up vote
16
down vote

favorite
3












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?










share|improve this question




















  • 2




    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 8 '15 at 9: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 8 '15 at 9: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 7 '17 at 11:40










  • 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 at 21:19

















up vote
16
down vote

favorite
3












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?










share|improve this question




















  • 2




    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 8 '15 at 9: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 8 '15 at 9: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 7 '17 at 11:40










  • 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 at 21:19















up vote
16
down vote

favorite
3









up vote
16
down vote

favorite
3






3





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?










share|improve this question















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?







linux filesystems mount readonly






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 8 '15 at 21:10









Gilles

525k12710501578




525k12710501578










asked Apr 8 '15 at 9:21









AdithyaCS

81114




81114








  • 2




    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 8 '15 at 9: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 8 '15 at 9: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 7 '17 at 11:40










  • 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 at 21:19
















  • 2




    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 8 '15 at 9: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 8 '15 at 9: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 7 '17 at 11:40










  • 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 at 21:19










2




2




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 8 '15 at 9:30




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 8 '15 at 9: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 8 '15 at 9:59




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 8 '15 at 9: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 7 '17 at 11:40




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 7 '17 at 11:40












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 at 21:19






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 at 21:19












2 Answers
2






active

oldest

votes

















up vote
12
down vote













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.






share|improve this answer

















  • 2




    Unfortunately, this is not portable solution. On raspberry I get: "Permission denied" when I run echo 1 | sudo tee /sys/block/mmcblk0/mmcblk0p2/ro
    – Piotr Findeisen
    May 7 '17 at 14:11










  • .. and echo u > /proc/sysrq-trigger is not only extreme, but can also force you to reboot if you want to remount back RW. When I tried this and then remount (with mount..) dmesg said "Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead"
    – Piotr Findeisen
    May 7 '17 at 14:14










  • @PiotrFindeisen did you run that as root?
    – hanshenrik
    Sep 14 at 10:01










  • @hanshenrik i guess so
    – Piotr Findeisen
    Sep 14 at 20:02


















up vote
2
down vote













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.






share|improve this answer



















  • 1




    @psusi no. It allowed me remount my ext4 / partition.
    – Piotr Findeisen
    May 7 '17 at 10:58








  • 2




    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 8 '17 at 0: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 9 '17 at 6:32








  • 8




    man 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








  • 2




    BSD and, therefore, macOS mounts' -f does indeed mean "force".
    – terdon
    Sep 17 at 8:45











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f195010%2fremount-a-busy-disk-to-read-only-mode%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
12
down vote













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.






share|improve this answer

















  • 2




    Unfortunately, this is not portable solution. On raspberry I get: "Permission denied" when I run echo 1 | sudo tee /sys/block/mmcblk0/mmcblk0p2/ro
    – Piotr Findeisen
    May 7 '17 at 14:11










  • .. and echo u > /proc/sysrq-trigger is not only extreme, but can also force you to reboot if you want to remount back RW. When I tried this and then remount (with mount..) dmesg said "Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead"
    – Piotr Findeisen
    May 7 '17 at 14:14










  • @PiotrFindeisen did you run that as root?
    – hanshenrik
    Sep 14 at 10:01










  • @hanshenrik i guess so
    – Piotr Findeisen
    Sep 14 at 20:02















up vote
12
down vote













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.






share|improve this answer

















  • 2




    Unfortunately, this is not portable solution. On raspberry I get: "Permission denied" when I run echo 1 | sudo tee /sys/block/mmcblk0/mmcblk0p2/ro
    – Piotr Findeisen
    May 7 '17 at 14:11










  • .. and echo u > /proc/sysrq-trigger is not only extreme, but can also force you to reboot if you want to remount back RW. When I tried this and then remount (with mount..) dmesg said "Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead"
    – Piotr Findeisen
    May 7 '17 at 14:14










  • @PiotrFindeisen did you run that as root?
    – hanshenrik
    Sep 14 at 10:01










  • @hanshenrik i guess so
    – Piotr Findeisen
    Sep 14 at 20:02













up vote
12
down vote










up vote
12
down vote









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.






share|improve this answer












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.







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 8 '15 at 23:00









Gilles

525k12710501578




525k12710501578








  • 2




    Unfortunately, this is not portable solution. On raspberry I get: "Permission denied" when I run echo 1 | sudo tee /sys/block/mmcblk0/mmcblk0p2/ro
    – Piotr Findeisen
    May 7 '17 at 14:11










  • .. and echo u > /proc/sysrq-trigger is not only extreme, but can also force you to reboot if you want to remount back RW. When I tried this and then remount (with mount..) dmesg said "Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead"
    – Piotr Findeisen
    May 7 '17 at 14:14










  • @PiotrFindeisen did you run that as root?
    – hanshenrik
    Sep 14 at 10:01










  • @hanshenrik i guess so
    – Piotr Findeisen
    Sep 14 at 20:02














  • 2




    Unfortunately, this is not portable solution. On raspberry I get: "Permission denied" when I run echo 1 | sudo tee /sys/block/mmcblk0/mmcblk0p2/ro
    – Piotr Findeisen
    May 7 '17 at 14:11










  • .. and echo u > /proc/sysrq-trigger is not only extreme, but can also force you to reboot if you want to remount back RW. When I tried this and then remount (with mount..) dmesg said "Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead"
    – Piotr Findeisen
    May 7 '17 at 14:14










  • @PiotrFindeisen did you run that as root?
    – hanshenrik
    Sep 14 at 10:01










  • @hanshenrik i guess so
    – Piotr Findeisen
    Sep 14 at 20:02








2




2




Unfortunately, this is not portable solution. On raspberry I get: "Permission denied" when I run echo 1 | sudo tee /sys/block/mmcblk0/mmcblk0p2/ro
– Piotr Findeisen
May 7 '17 at 14:11




Unfortunately, this is not portable solution. On raspberry I get: "Permission denied" when I run echo 1 | sudo tee /sys/block/mmcblk0/mmcblk0p2/ro
– Piotr Findeisen
May 7 '17 at 14:11












.. and echo u > /proc/sysrq-trigger is not only extreme, but can also force you to reboot if you want to remount back RW. When I tried this and then remount (with mount..) dmesg said "Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead"
– Piotr Findeisen
May 7 '17 at 14:14




.. and echo u > /proc/sysrq-trigger is not only extreme, but can also force you to reboot if you want to remount back RW. When I tried this and then remount (with mount..) dmesg said "Couldn't remount RDWR because of unprocessed orphan inode list. Please umount/remount instead"
– Piotr Findeisen
May 7 '17 at 14:14












@PiotrFindeisen did you run that as root?
– hanshenrik
Sep 14 at 10:01




@PiotrFindeisen did you run that as root?
– hanshenrik
Sep 14 at 10:01












@hanshenrik i guess so
– Piotr Findeisen
Sep 14 at 20:02




@hanshenrik i guess so
– Piotr Findeisen
Sep 14 at 20:02












up vote
2
down vote













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.






share|improve this answer



















  • 1




    @psusi no. It allowed me remount my ext4 / partition.
    – Piotr Findeisen
    May 7 '17 at 10:58








  • 2




    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 8 '17 at 0: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 9 '17 at 6:32








  • 8




    man 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








  • 2




    BSD and, therefore, macOS mounts' -f does indeed mean "force".
    – terdon
    Sep 17 at 8:45















up vote
2
down vote













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.






share|improve this answer



















  • 1




    @psusi no. It allowed me remount my ext4 / partition.
    – Piotr Findeisen
    May 7 '17 at 10:58








  • 2




    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 8 '17 at 0: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 9 '17 at 6:32








  • 8




    man 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








  • 2




    BSD and, therefore, macOS mounts' -f does indeed mean "force".
    – terdon
    Sep 17 at 8:45













up vote
2
down vote










up vote
2
down vote









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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








edited yesterday

























answered May 6 '17 at 21:59









Piotr Findeisen

1454




1454








  • 1




    @psusi no. It allowed me remount my ext4 / partition.
    – Piotr Findeisen
    May 7 '17 at 10:58








  • 2




    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 8 '17 at 0: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 9 '17 at 6:32








  • 8




    man 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








  • 2




    BSD and, therefore, macOS mounts' -f does indeed mean "force".
    – terdon
    Sep 17 at 8:45














  • 1




    @psusi no. It allowed me remount my ext4 / partition.
    – Piotr Findeisen
    May 7 '17 at 10:58








  • 2




    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 8 '17 at 0: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 9 '17 at 6:32








  • 8




    man 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








  • 2




    BSD and, therefore, macOS mounts' -f does indeed mean "force".
    – terdon
    Sep 17 at 8:45








1




1




@psusi no. It allowed me remount my ext4 / partition.
– Piotr Findeisen
May 7 '17 at 10:58






@psusi no. It allowed me remount my ext4 / partition.
– Piotr Findeisen
May 7 '17 at 10:58






2




2




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 8 '17 at 0:29




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 8 '17 at 0:29




1




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 9 '17 at 6:32






@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 9 '17 at 6:32






8




8




man 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






man 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






2




2




BSD and, therefore, macOS mounts' -f does indeed mean "force".
– terdon
Sep 17 at 8:45




BSD and, therefore, macOS mounts' -f does indeed mean "force".
– terdon
Sep 17 at 8:45


















draft saved

draft discarded




















































Thanks for contributing an answer to Unix & Linux Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f195010%2fremount-a-busy-disk-to-read-only-mode%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Accessing regular linux commands in Huawei's Dopra Linux

Can't connect RFCOMM socket: Host is down

Kernel panic - not syncing: Fatal Exception in Interrupt