Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

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

On my Arch Linux system (Linux Kernel 3.14.2) bind mounts do not respect the read only option

# mkdir test
# mount --bind -o ro test/ /mnt
# touch /mnt/foo

creates the file /mnt/foo. The relevant entry in /proc/mounts is

/dev/sda2 /mnt ext4 rw,noatime,data=ordered 0 0

The mount options do not match my requested options, but do match both the read/write behaviour of the bind mount and the options used to originally mount /dev/sda2 on /

/dev/sda2 / ext4 rw,noatime,data=ordered 0 0

If, however, I remount the mount then it respects the read only option

# mount --bind -o remount,ro test/ /mnt
# touch /mnt/bar
touch: cannot touch ‘/mnt/bar’: Read-only file system

and the relevant entry in /proc/mounts/

/dev/sda2 /mnt ext4 ro,relatime,data=ordered 0 0

looks like what I might expect (although in truth I would expect to see the full path of the test directory). The entry in /proc/mounts/ for the orignal mount of /dev/sda2/ on / is also unchanged and remains read/write

/dev/sda2 / ext4 rw,noatime,data=ordered 0 0

This behaviour and the work around have been known since at least 2008 and are documented in the man page of mount

Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed by passing the -o option along with --bind/--rbind. The mount options can be changed by a separate remount command

Not all distributions behave the same. Arch seems to silently fail to respect the options while Debian generates a warning when the bind mount does not get mount read-only

mount: warning: /mnt seems to be mounted read-write.

There are reports that this behaviour was "fixed" in Debian Lenny and Squeeze although it does not appear to be a universal fix nor does it still work in Debian Wheezy. What is the difficultly associated with making bind mount respect the read only option on the initial mount?

share|improve this question
Do you have an /etc/mtab? – eyoung100 May 7 '14 at 15:58
See also thread.gmane.org/gmane.linux.utilities.util-linux-ng/2979 and a workaround by using mount -t bind and a helper script at bugs.launchpad.net/ubuntu/+source/mountall/+bug/519380 – Stéphane Chazelas May 7 '14 at 16:06
@ECarterYoung yes I have an /etc/mtab. After the initial mount the entry says the mount is rw and after the remount it says ro, so it is reporting the state of the mount correctly. It is just the mount command that fails. – StrongBad May 7 '14 at 16:10
I tested on two Debian testing/unstable machines, one running a Debian kernel and one running a kernel.org kernel, neither work with mount --bind -o ro, they both spit out a message mount: warning: «mountpoint» seems to be mounted read-write. So it seems Debian dropped or lost the patch at some point... Remount works, though. – derobert May 7 '14 at 16:50
@StrongBad Tested that as requested, and it doesn't work either. – derobert May 7 '14 at 17:09

Bind mount is just... well... a bind mount. I.e. it's not a new mount. It just "links"/"exposes"/"considers" a subdirectory as a new mount point. As such it cannot alter the mount parameters. That's why you're getting complaints:

# mount /mnt/1/lala /mnt/2 -o bind,ro
mount: warning: /mnt/2 seems to be mounted read-write.

But as you said a normal bind mount works:

# mount /mnt/1/lala /mnt/2 -o bind

And then a ro remount also works:

# mount /mnt/1/lala /mnt/2 -o bind,remount,ro 

However what happens is that you're changing the whole mount and not just this bind mount. If you take a look at /proc/mounts you'll see that both bind mount and the original mount change to read-only:

/dev/loop0 /mnt/1 ext2 ro,relatime,errors=continue,user_xattr,acl 0 0
/dev/loop0 /mnt/2 ext2 ro,relatime,errors=continue,user_xattr,acl 0 0

So what you're doing is like changing the initial mount to a read-only mount and then doing a bind mount which will of course be read-only.

share|improve this answer
Yes, but no. IIRC there is some support in the kernel for different mount points (not filesystems) to have different options. Debian used to have a patch that made mount -o bind,ro create a read-only view of a read-write filesystem (but it no longer seems to be there in wheezy). – Gilles May 7 '14 at 23:07
I don't see how this contradicts the above. Hacks can allow all sorts of stuff, including things that don't make much sense. Currently the read-only remount on 3.14 kernel is eventually handled by this call: mnt_make_readonly(real_mount(mnt)), which as you can see uses real_mount(), so it practically affects the real mount and that causes bind mounts to reflect the new (read-only) mount flag. At least that's my understanding. – V13 May 7 '14 at 23:21
mount --bind /tmp/ /mnt/tmp/; mount -o remount,bind,ro /mnt/tmp/ ... then touch /tmp/a is OK, but touch /mnt/tmp/b gives touch: cannot touch ‘/mnt/tmp/b’: Read-only file system. That works on both Debian 3.13 and kernel.org 3.14.2. So it doesn't just change the whole mount. At least not with recent kernels. – derobert May 8 '14 at 5:46
On Arch the original mount remains read/write. I have edited the question to include the entries from /proc/mounts. – StrongBad May 8 '14 at 11:58
Presumably the statement that a "Bind mount is just... well... a bind mount." is really important but means nothing to me. I also don't understand why it then works the second time with the remount option. – StrongBad May 8 '14 at 12:00

The proper solution is really to mount it twice. On the command line:

mount -t none -o bind /source/dir /destination/dir
mount -t none -o bind,remount,ro /source/dir /destination/dir

In /etc/fstab:

/source/dir            /destination/dir    none  bind            0 0
/source/dir            /destination/dir    none  remount,bind,ro 0 0

The manual (man mount) states it that way:

   The bind mounts.
          Since Linux 2.4.0 it is possible to remount part of the file hierarchy somewhere else. The call is
                 mount --bind olddir newdir
          Note that the filesystem mount options will remain the same as those on the original mount point, and cannot be changed  by  passing  the  -o  option
          along with --bind/--rbind. The mount options can be changed by a separate remount command, for example:
                 mount --bind olddir newdir
                 mount -o remount,ro newdir
          Note  that  behavior  of  the remount operation depends on the /etc/mtab file. The first command stores the 'bind' flag to the /etc/mtab file and the
          second command reads the flag from the file.  If you have a system without the /etc/mtab file or if you explicitly define source and target  for  the
          remount command (then mount(8) does not read /etc/mtab), then you have to use bind flag (or option) for the remount command too. For example:
                 mount --bind olddir newdir
                 mount -o remount,ro,bind olddir newdir
share|improve this answer
This does seem to work with at least Ubuntu 14.04 LTS and kernel 3.19.0-51-lowlatency. Nice! – Mikko Rantalainen Jun 2 at 6:42

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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