1

I am confused about --make-shared, --make-slave, --make-private and --make-unbindable flags of the mount command.

Can someone please explain in simple words , what each flag do ? and what is the difference between them ?

Raffa
  • 32,237
Noah5CE
  • 33
  • This should explain it all clearly for you... https://linux.die.net/man/1/make – graham May 28 '23 at 14:43
  • 1
    Does the full documentation hidden away at https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt help? – Martin Thornton May 28 '23 at 15:39
  • You don’t usually need to set these unless in special situations that involve using the same mount points interchably to mount different filesystems in different user spaces utilizing e.g. pivot_root or chroot during a single system boot session like in system maintenance situations … See an example of that here: https://askubuntu.com/a/1416932 … @MartinThornton other than this missing piece of info, your linked resource seems on target and I encourage you to make an answer in layman’s terms from all that so folks like me can easily find and understand it :-) – Raffa May 28 '23 at 16:06
  • Folks voting to close this question as unclear or unfocused .., Please, don’t … This is as clear and focused as it ever going to be … It’s clear about mount and focused on four of it’s options that happen to be rarely discussed and IMO is worth its own Q&A on this site. – Raffa May 28 '23 at 16:20
  • I see you edited your question which initially had examples of those options with r recursive in them like --make-rshared and so on … Well that is what it means i.e. recursively apply that option to already existing sub-mounts under the source argument for mount. – Raffa May 28 '23 at 16:35

1 Answers1

3

These flags to the mount command are advanced features which modify the way bind-mounts work. They also have the same effects on mount-namespaces, and this is sometimes used by systemd to allow a process to have its own private mounts.

The --make-unbindable flag prevents any later bind-mounting of either part or the whole of a mount:

mount --make-unbindable /master

#Both of these will fail mount --rbind /master /slave mount --rbind /master/subdir /slave

The other flags effect how changes to submounts within a mount are synchronized between future bind-mounts and namespaces. The use of --rbind instead of --bind is still needed to recursively share all existing submounts with the bind mount, except those made unbindable as above.

Like --bind, all these flags also have variants with an r prefix which are recursively applied to all contained mounts.

The --make-[r]shared flag (the initial state with systemd) enables synchronisation between a master mount and future copies. By example, for an existing mount at /master, both master-submount and slave-submount will be mounted under both /master and /slave:

mount --make-rshared /master
mount --rbind /master /slave
mount /dev/$DEVICE /master/master-submount
mount /dev/$DEVICE /slave/slave-submount

The --make-[r]private flag stops further synchronisation. This is irreversible for any existing shares. Continuing the above example below, unmounting /master/master-submount and /slave/slave-submount will not now unmount the copies at /slave/master-submount and /master/slave-submount:

mount --make-rprivate /slave
umount /master/master-submount
umount /slave/slave-submount

The --make-[r]slave flag can be used to break only updates to others, but still receive them. If rslave had been used instead of rprivate above, /master/slave-submount would still not be unmounted by /slave, but /slave/master-submount would also have been unmounted by /master.


The full documentation for these flags is not in the man page, but is available at https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt.

  • Nicely done ... Although I would (in addition to VFS namespaces of course) emphasize switching between userspaces in a running system as without the latter, the former will almost have no practical applicable challenge cases IMHO ... The VFS(Virtual FileSystem) is the kernels implementation of a software layer to present the Actual FileSystem(low-level on disk) to userspace(s) as vfsmount ... So, unless switching between userspaces, I hardly can think of user need to set such vfsmount's attributes. – Raffa May 29 '23 at 11:34