Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a dualboot installation with Ubuntu 10.04 and Windows 7 Ultimate. I've got 2 drives with the following partitions set up:

500 GB drive
2 partitions:
    C:/   320GB NTFS (Has Win 7 on it)
    D:/   180GB NTFS

160 GB drive
1 main partition:
    1     160GB EXT4 (Has Ubuntu 10.04 in it)

In Ubuntu, I'm auto mounting the entire 500GB drive, using an /etc/fstab line. I've configured that line as the following:

UUID=XXXXXXXXXXXXXXXX /media/WinEmily         auto    ro,auto,user,exec 0 0

Where the UUID is the one of the 500GB drive and /media/WinEmily is my existing mount point.

Now my question is, is there any way for Ubuntu to still write to either of the partitions of the 500GB drive. I'm trying to prevent that so that it will have read access only, no matter what it tries. (Except of course unmounting and remounting with read/write access.)

I'm talking about normal file operations, editing and erasing files from the file system. Not destroying the entire file system using brute force.

So is there like a command like this, that would allow writing even though it's mounted as read-only.

supersuperuserdo rm --doitanyway /media/WinEmily/file.txt
share|improve this question
up vote 6 down vote accepted

If you mount a filesystem read-only, there is no way to modify it through filesystem operations. Not even if you're root. If you want to perform any modification (write to a file, remove a file, change permissions, update the access time, etc.), you have to remount the file system read-write (mount -o remount,rw /dev/foo).

You can still access the underlying device and write to it. (It's a very bad idea, of course.) Disks and partitions are only accessible by root unless you've explicitly changed this (usually a bad idea too).

One thing that doesn't come up very often is that the action of mounting itself might write to the disk. This can happen even with read-only mounts for journaled filesystems: if the filesystem was not cleanly unmounted, the action of mounting the filesystem may replay the journal and perform the queued actions (it does for ext3; I don't know about ntfs). This means you can't easily inspect the disk of a suspended machine (e.g. the disk image of a paused virtual machine viewed on the host, or a hibernating system from a rescue CD).

share|improve this answer
+1 for "mounting itself might write to the disk": I never thought about that (though it's logical in retrospect). – sleske Aug 20 '10 at 0:01
Actually you can mount ext3 without modifying it using options "ro,noload" (from Documentation/filesystems/ext3.txt in the Linux docs). The docs note, however, that this can lead to "various problems"... – sleske Aug 20 '10 at 0:04
@sleske Yet, I'm trying to mount an NTFS system, not an extended one ;) – BloodPhilia Aug 20 '10 at 0:19
@sleske: Thanks for the tip! I found that one the hard way, I wish noload had (existed|been documented) then... – Gilles Aug 20 '10 at 0:29
@sleske But will I need noload for NTFS too? – BloodPhilia Aug 20 '10 at 12:56

Under normal conditions:

If you want to protect it from yourself, meaning accidental operations, this is enough.

No decent command like supersuperuserdo rm --doitanyway /media/WinEmily/file.txt can possibly cause file.txt to be deleted.

To cause damage there must be two things: sudo, and either mount -o rw or /dev/sda1.

Now, if the problem is someone else that has access to your computer, you must either trust that they won't use the words mount -o rw and /dev/sda1, or not give them an admin account in first place. With an admin account they can do whatever they want. Another level of protection in this case is to enter BIOS setup, forbid booting from CD/USB, and password-protect the BIOS setup itself.

share|improve this answer
It is just for me, thanks! ;) – BloodPhilia Aug 20 '10 at 12:58
OK. So, keep in mind that it is not about root priviledges. The kernel simply will not turn a rm file.txt-like command into a device-writing operation unless the device is mounted accordingly. – user39559 Aug 20 '10 at 13:24

Well, you can always do dd if=/dev/zero of=/dev/sda.

share|improve this answer
Well I could, but it doesn't really answer my question... that would be a bit brute force on the entire disk... I'm talking about normal file operations. – BloodPhilia Aug 19 '10 at 23:02

"Is there a command"...well depends on how you define a

#!/bin/bash (in file 'mynewcommand' set executable in your PATH)
# temp remount fs rw, execute passed in command(s), remount again, ro sudo
mount  -o remount,rw UUID=xxx   /place 
eval $1 
sudo mount -o remount,ro UUID=xxx....

Is this the type of thing you were looking for?

For what it's worth .. the idea that a mount might 'change' the file system applies primarily to file systems that are 'journaled' (a form of drive-format protection). NTFS is journaled on Windows. I don't believe current versions of linux have journaling in them yet. Normally replaying a journal isn't a problem unless you are doing forensics on the file system or the file system is corrupt.

share|improve this answer
Linux has had journalled filesystems for nearly a decade, in the form of [ext3][1], ReiserFS, JFS and XFS. [1]: – user46838 Aug 20 '10 at 4:11
Linux has had journalled filesystems for nearly a decade, in the form of [ext3][1], ReiserFS, JFS and XFS. [1]: – user46838 Aug 20 '10 at 4:11
Linux has had journalled filesystems for nearly a decade, in the form of [ext3][1], ReiserFS, JFS and XFS. [1]: – user46838 Aug 20 '10 at 4:11

You must log in to answer this question.

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