Server Fault is a question and answer site for system and network administrators. 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

I use mount -o bind to mount directories inside chroots, which works really well. The problem is that I'd like some of these bind-mounted directories to be read only in chroot.

Is it possible? If not - any other way to achieve it?

I was thinking about using NFS for localhost mounts, but it looks like overkill.

share|improve this question
up vote 4 down vote accepted

Accourding to this is it is possible. You do need a recent kernel.

share|improve this answer
Thanks. Mount + remount fixed it. – user13185 Apr 28 '10 at 7:51

Direct answer from the LWN article:

mount --bind /vital_data /untrusted_container/vital_data
mount -o remount,ro /untrusted_container/vital_data

Supported since Linux 2.6.26.

share|improve this answer

mount --bind /vital_data /untrusted_container/vital_data

mount -o remount,ro,bind /untrusted_container/vital_data

in the second mount you have to use "remount,ro,bind" otherwise all other instances of /vital_data will got read-only right too.

share|improve this answer
No, you don't (at least not on Linux 3.19). Where did you experience the necessity of adding the bind option? – Karl Richter Feb 12 '15 at 7:14

In Squeeze it used to work with only:

mount --bind /src /dst


mount -o remount,ro /dst

Now in Debian Wheezy you have to do:

mount -o remount,ro,bind /dst

to get rid of the: resource busy message.

Edit: Now in Debian Jessie, mount tries to be smart and mounts sub dirs, which if already mounted with bind, gets recursive and bad things happens :)

There is a special option that forces util-linux to be 'stupid' again. Solutions is this:

mount --bind --make-rprivate /sbin/ $prefix/sbin/
mount -o remount,ro,bind $prefix/sbin/

Afterwards you can mount --bind $prefix/sbin to another dir.

From the man page:

The shared subtree operations. Since Linux 2.6.15 it is possible to mark a mount and its submounts as shared, private, slave or unbindable. A shared mount provides the ability to create mirrors of that mount such that mounts and unmounts within any of the mirrors propagate to the other mirror. A slave mount receives propagation from its master, but not vice versa. A private mount carries no propagation abilities. An unbindable mount is a private mount which cannot be cloned through a bind operation. The detailed semantics are documented in Documentation/filesystems/sharedsubtree.txt file in the kernel source tree. Supported operations are:

     mount --make-shared mountpoint
     mount --make-slave mountpoint
     mount --make-private mountpoint
     mount --make-unbindable mountpoint

The following commands allow one to recursively change the type of all the mounts under a given mountpoint.

     mount --make-rshared mountpoint
     mount --make-rslave mountpoint
     mount --make-rprivate mountpoint
     mount --make-runbindable mountpoint

mount(8) does not read fstab(5) when a --make-* operation is requested. All necessary information has to be specified on the command line. Note that the Linux kernel does not allow to change multiple propagation flags with a single mount(2) syscall, and the flags cannot be mixed with other mount options.

Since util-linux 2.23 the mount command allows to use several propagation flags together and also together with other mount operations. This feature is EXPERIMENTAL. The propagation flags are applied by additional mount(2) syscalls when the preceeding mount operations were successful. Note that this use case is not atomic. It is possible to specify the propagation flags in fstab(5) as mount options (private, slave, shared, unbindable, rprivate, rslave, rshared, runbindable).

share|improve this answer
Thanks :) the wheezy thing saved me. – Wyatt8740 Aug 5 '14 at 21:49

Your Answer


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