Score:1

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

mu flag

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 ?

24601 avatar
in flag
This should explain it all clearly for you... https://linux.die.net/man/1/make
Martin Thornton avatar
cn flag
Does the full documentation hidden away at https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt help?
Raffa avatar
jp flag
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 avatar
jp flag
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 avatar
jp flag
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`.
Score:3
cn flag

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.

Raffa avatar
jp flag
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*)](https://www.kernel.org/doc/Documentation/filesystems/vfs.txt) 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.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.