1MOUNT_NAMESPACES(7) Linux Programmer's Manual MOUNT_NAMESPACES(7)
2
6 mount_namespaces - overview of Linux mount namespaces
7
9 For an overview of namespaces, see namespaces(7).
10 Mount namespaces provide isolation of the list of mount points seen by
12 the processes in each namespace instance. Thus, the processes in each
13 of the mount namespace instances will see distinct single-directory hi‐
14 erarchies.
15 The views provided by the /proc/[pid]/mounts, /proc/[pid]/mountinfo,
17 and /proc/[pid]/mountstats files (all described in proc(5)) correspond
18 to the mount namespace in which the process with the PID [pid] resides.
19 (All of the processes that reside in the same mount namespace will see
20 the same view in these files.)
21 A new mount namespace is created using either clone(2) or unshare(2)
23 with the CLONE_NEWNS flag. When a new mount namespace is created, its
24 mount point list is initialized as follows:
25 * If the namespace is created using clone(2), the mount point list of
27 the child's namespace is a copy of the mount point list in the par‐
28 ent's namespace.
29 * If the namespace is created using unshare(2), the mount point list
31 of the new namespace is a copy of the mount point list in the
32 caller's previous mount namespace.
33 Subsequent modifications to the mount point list (mount(2) and
35 umount(2)) in either mount namespace will not (by default) affect the
36 mount point list seen in the other namespace (but see the following
37 discussion of shared subtrees).
38 Restrictions on mount namespaces
40 Note the following points with respect to mount namespaces:
41 * Each mount namespace has an owner user namespace. As explained
43 above, when a new mount namespace is created, its mount point list
44 is initialized as a copy of the mount point list of another mount
45 namespace. If the new namespace and the namespace from which the
46 mount point list was copied are owned by different user namespaces,
47 then the new mount namespace is considered less privileged.
48 * When creating a less privileged mount namespace, shared mounts are
50 reduced to slave mounts. (Shared and slave mounts are discussed be‐
51 low.) This ensures that mappings performed in less privileged mount
52 namespaces will not propagate to more privileged mount namespaces.
53 * Mounts that come as a single unit from a more privileged mount name‐
55 space are locked together and may not be separated in a less privi‐
56 leged mount namespace. (The unshare(2) CLONE_NEWNS operation brings
57 across all of the mounts from the original mount namespace as a sin‐
58 gle unit, and recursive mounts that propagate between mount name‐
59 spaces propagate as a single unit.)
60 * The mount(2) flags MS_RDONLY, MS_NOSUID, MS_NOEXEC, and the "atime"
62 flags (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) settings become
63 locked when propagated from a more privileged to a less privileged
64 mount namespace, and may not be changed in the less privileged mount
65 namespace.
66 * A file or directory that is a mount point in one namespace that is
68 not a mount point in another namespace, may be renamed, unlinked, or
69 removed (rmdir(2)) in the mount namespace in which it is not a mount
70 point (subject to the usual permission checks). Consequently, the
71 mount point is removed in the mount namespace where it was a mount
72 point.
73 Previously (before Linux 3.18), attempting to unlink, rename, or re‐
75 move a file or directory that was a mount point in another mount
76 namespace would result in the error EBUSY. That behavior had tech‐
77 nical problems of enforcement (e.g., for NFS) and permitted denial-
78 of-service attacks against more privileged users. (i.e., preventing
79 individual files from being updated by bind mounting on top of
80 them).
81
83 After the implementation of mount namespaces was completed, experience
84 showed that the isolation that they provided was, in some cases, too
85 great. For example, in order to make a newly loaded optical disk
86 available in all mount namespaces, a mount operation was required in
87 each namespace. For this use case, and others, the shared subtree fea‐
88 ture was introduced in Linux 2.6.15. This feature allows for auto‐
89 matic, controlled propagation of mount and unmount events between name‐
90 spaces (or, more precisely, between the members of a peer group that
91 are propagating events to one another).
92 Each mount point is marked (via mount(2)) as having one of the follow‐
94 ing propagation types:
95 MS_SHARED
97 This mount point shares events with members of a peer group.
98 Mount and unmount events immediately under this mount point will
99 propagate to the other mount points that are members of the peer
100 group. Propagation here means that the same mount or unmount
101 will automatically occur under all of the other mount points in
102 the peer group. Conversely, mount and unmount events that take
103 place under peer mount points will propagate to this mount
104 point.
105 MS_PRIVATE
107 This mount point is private; it does not have a peer group.
108 Mount and unmount events do not propagate into or out of this
109 mount point.
110 MS_SLAVE
112 Mount and unmount events propagate into this mount point from a
113 (master) shared peer group. Mount and unmount events under this
114 mount point do not propagate to any peer.
115 Note that a mount point can be the slave of another peer group
117 while at the same time sharing mount and unmount events with a
118 peer group of which it is a member. (More precisely, one peer
119 group can be the slave of another peer group.)
120 MS_UNBINDABLE
122 This is like a private mount, and in addition this mount can't
123 be bind mounted. Attempts to bind mount this mount (mount(2)
124 with the MS_BIND flag) will fail.
125 When a recursive bind mount (mount(2) with the MS_BIND and
127 MS_REC flags) is performed on a directory subtree, any bind
128 mounts within the subtree are automatically pruned (i.e., not
129 replicated) when replicating that subtree to produce the target
130 subtree.
131 For a discussion of the propagation type assigned to a new mount, see
133 NOTES.
134 The propagation type is a per-mount-point setting; some mount points
136 may be marked as shared (with each shared mount point being a member of
137 a distinct peer group), while others are private (or slaved or unbind‐
138 able).
139 Note that a mount's propagation type determines whether mounts and un‐
141 mounts of mount points immediately under the mount point are propa‐
142 gated. Thus, the propagation type does not affect propagation of
143 events for grandchildren and further removed descendant mount points.
144 What happens if the mount point itself is unmounted is determined by
145 the propagation type that is in effect for the parent of the mount
146 point.
147 Members are added to a peer group when a mount point is marked as
149 shared and either:
150 * the mount point is replicated during the creation of a new mount
152 namespace; or
153 * a new bind mount is created from the mount point.
155 In both of these cases, the new mount point joins the peer group of
157 which the existing mount point is a member.
158 A new peer group is also created when a child mount point is created
160 under an existing mount point that is marked as shared. In this case,
161 the new child mount point is also marked as shared and the resulting
162 peer group consists of all the mount points that are replicated under
163 the peers of parent mount.
164 A mount ceases to be a member of a peer group when either the mount is
166 explicitly unmounted, or when the mount is implicitly unmounted because
167 a mount namespace is removed (because it has no more member processes).
168 The propagation type of the mount points in a mount namespace can be
170 discovered via the "optional fields" exposed in /proc/[pid]/mountinfo.
171 (See proc(5) for details of this file.) The following tags can appear
172 in the optional fields for a record in that file:
173 shared:X
175 This mount point is shared in peer group X. Each peer group has
176 a unique ID that is automatically generated by the kernel, and
177 all mount points in the same peer group will show the same ID.
178 (These IDs are assigned starting from the value 1, and may be
179 recycled when a peer group ceases to have any members.)
180 master:X
182 This mount is a slave to shared peer group X.
183 propagate_from:X (since Linux 2.6.26)
185 This mount is a slave and receives propagation from shared peer
186 group X. This tag will always appear in conjunction with a mas‐
187 ter:X tag. Here, X is the closest dominant peer group under the
188 process's root directory. If X is the immediate master of the
189 mount, or if there is no dominant peer group under the same
190 root, then only the master:X field is present and not the propa‐
191 gate_from:X field. For further details, see below.
192 unbindable
194 This is an unbindable mount.
195 If none of the above tags is present, then this is a private mount.
197 MS_SHARED and MS_PRIVATE example
199 Suppose that on a terminal in the initial mount namespace, we mark one
200 mount point as shared and another as private, and then view the mounts
201 in /proc/self/mountinfo:
202 sh1# mount --make-shared /mntS
204 sh1# mount --make-private /mntP
205 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
206 77 61 8:17 / /mntS rw,relatime shared:1
207 83 61 8:15 / /mntP rw,relatime
208 From the /proc/self/mountinfo output, we see that /mntS is a shared
210 mount in peer group 1, and that /mntP has no optional tags, indicating
211 that it is a private mount. The first two fields in each record in
212 this file are the unique ID for this mount, and the mount ID of the
213 parent mount. We can further inspect this file to see that the parent
214 mount point of /mntS and /mntP is the root directory, /, which is
215 mounted as private:
216 sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
218 61 0 8:2 / / rw,relatime
219 On a second terminal, we create a new mount namespace where we run a
221 second shell and inspect the mounts:
222 $ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
224 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
225 222 145 8:17 / /mntS rw,relatime shared:1
226 225 145 8:15 / /mntP rw,relatime
227 The new mount namespace received a copy of the initial mount name‐
229 space's mount points. These new mount points maintain the same propa‐
230 gation types, but have unique mount IDs. (The --propagation unchanged
231 option prevents unshare(1) from marking all mounts as private when cre‐
232 ating a new mount namespace, which it does by default.)
233 In the second terminal, we then create submounts under each of /mntS
235 and /mntP and inspect the set-up:
236 sh2# mkdir /mntS/a
238 sh2# mount /dev/sdb6 /mntS/a
239 sh2# mkdir /mntP/b
240 sh2# mount /dev/sdb7 /mntP/b
241 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
242 222 145 8:17 / /mntS rw,relatime shared:1
243 225 145 8:15 / /mntP rw,relatime
244 178 222 8:22 / /mntS/a rw,relatime shared:2
245 230 225 8:23 / /mntP/b rw,relatime
246 From the above, it can be seen that /mntS/a was created as shared (in‐
248 heriting this setting from its parent mount) and /mntP/b was created as
249 a private mount.
250 Returning to the first terminal and inspecting the set-up, we see that
252 the new mount created under the shared mount point /mntS propagated to
253 its peer mount (in the initial mount namespace), but the new mount cre‐
254 ated under the private mount point /mntP did not propagate:
255 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
257 77 61 8:17 / /mntS rw,relatime shared:1
258 83 61 8:15 / /mntP rw,relatime
259 179 77 8:22 / /mntS/a rw,relatime shared:2
260 MS_SLAVE example
262 Making a mount point a slave allows it to receive propagated mount and
263 unmount events from a master shared peer group, while preventing it
264 from propagating events to that master. This is useful if we want to
265 (say) receive a mount event when an optical disk is mounted in the mas‐
266 ter shared peer group (in another mount namespace), but want to prevent
267 mount and unmount events under the slave mount from having side effects
268 in other namespaces.
269 We can demonstrate the effect of slaving by first marking two mount
271 points as shared in the initial mount namespace:
272 sh1# mount --make-shared /mntX
274 sh1# mount --make-shared /mntY
275 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
276 132 83 8:23 / /mntX rw,relatime shared:1
277 133 83 8:22 / /mntY rw,relatime shared:2
278 On a second terminal, we create a new mount namespace and inspect the
280 mount points:
281 sh2# unshare -m --propagation unchanged sh
283 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
284 168 167 8:23 / /mntX rw,relatime shared:1
285 169 167 8:22 / /mntY rw,relatime shared:2
286 In the new mount namespace, we then mark one of the mount points as a
288 slave:
289 sh2# mount --make-slave /mntY
291 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
292 168 167 8:23 / /mntX rw,relatime shared:1
293 169 167 8:22 / /mntY rw,relatime master:2
294 From the above output, we see that /mntY is now a slave mount that is
296 receiving propagation events from the shared peer group with the ID 2.
297 Continuing in the new namespace, we create submounts under each of
299 /mntX and /mntY:
300 sh2# mkdir /mntX/a
302 sh2# mount /dev/sda3 /mntX/a
303 sh2# mkdir /mntY/b
304 sh2# mount /dev/sda5 /mntY/b
305 When we inspect the state of the mount points in the new mount name‐
307 space, we see that /mntX/a was created as a new shared mount (inherit‐
308 ing the "shared" setting from its parent mount) and /mntY/b was created
309 as a private mount:
310 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
312 168 167 8:23 / /mntX rw,relatime shared:1
313 169 167 8:22 / /mntY rw,relatime master:2
314 173 168 8:3 / /mntX/a rw,relatime shared:3
315 175 169 8:5 / /mntY/b rw,relatime
316 Returning to the first terminal (in the initial mount namespace), we
318 see that the mount /mntX/a propagated to the peer (the shared /mntX),
319 but the mount /mntY/b was not propagated:
320 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
322 132 83 8:23 / /mntX rw,relatime shared:1
323 133 83 8:22 / /mntY rw,relatime shared:2
324 174 132 8:3 / /mntX/a rw,relatime shared:3
325 Now we create a new mount point under /mntY in the first shell:
327 sh1# mkdir /mntY/c
329 sh1# mount /dev/sda1 /mntY/c
330 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
331 132 83 8:23 / /mntX rw,relatime shared:1
332 133 83 8:22 / /mntY rw,relatime shared:2
333 174 132 8:3 / /mntX/a rw,relatime shared:3
334 178 133 8:1 / /mntY/c rw,relatime shared:4
335 When we examine the mount points in the second mount namespace, we see
337 that in this case the new mount has been propagated to the slave mount
338 point, and that the new mount is itself a slave mount (to peer group
339 4):
340 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
342 168 167 8:23 / /mntX rw,relatime shared:1
343 169 167 8:22 / /mntY rw,relatime master:2
344 173 168 8:3 / /mntX/a rw,relatime shared:3
345 175 169 8:5 / /mntY/b rw,relatime
346 179 169 8:1 / /mntY/c rw,relatime master:4
347 MS_UNBINDABLE example
349 One of the primary purposes of unbindable mounts is to avoid the "mount
350 point explosion" problem when repeatedly performing bind mounts of a
351 higher-level subtree at a lower-level mount point. The problem is il‐
352 lustrated by the following shell session.
353 Suppose we have a system with the following mount points:
355 # mount | awk '{print $1, $2, $3}'
357 /dev/sda1 on /
358 /dev/sdb6 on /mntX
359 /dev/sdb7 on /mntY
360 Suppose furthermore that we wish to recursively bind mount the root di‐
362 rectory under several users' home directories. We do this for the
363 first user, and inspect the mount points:
364 # mount --rbind / /home/cecilia/
366 # mount | awk '{print $1, $2, $3}'
367 /dev/sda1 on /
368 /dev/sdb6 on /mntX
369 /dev/sdb7 on /mntY
370 /dev/sda1 on /home/cecilia
371 /dev/sdb6 on /home/cecilia/mntX
372 /dev/sdb7 on /home/cecilia/mntY
373 When we repeat this operation for the second user, we start to see the
375 explosion problem:
376 # mount --rbind / /home/henry
378 # mount | awk '{print $1, $2, $3}'
379 /dev/sda1 on /
380 /dev/sdb6 on /mntX
381 /dev/sdb7 on /mntY
382 /dev/sda1 on /home/cecilia
383 /dev/sdb6 on /home/cecilia/mntX
384 /dev/sdb7 on /home/cecilia/mntY
385 /dev/sda1 on /home/henry
386 /dev/sdb6 on /home/henry/mntX
387 /dev/sdb7 on /home/henry/mntY
388 /dev/sda1 on /home/henry/home/cecilia
389 /dev/sdb6 on /home/henry/home/cecilia/mntX
390 /dev/sdb7 on /home/henry/home/cecilia/mntY
391 Under /home/henry, we have not only recursively added the /mntX and
393 /mntY mounts, but also the recursive mounts of those directories under
394 /home/cecilia that were created in the previous step. Upon repeating
395 the step for a third user, it becomes obvious that the explosion is ex‐
396 ponential in nature:
397 # mount --rbind / /home/otto
399 # mount | awk '{print $1, $2, $3}'
400 /dev/sda1 on /
401 /dev/sdb6 on /mntX
402 /dev/sdb7 on /mntY
403 /dev/sda1 on /home/cecilia
404 /dev/sdb6 on /home/cecilia/mntX
405 /dev/sdb7 on /home/cecilia/mntY
406 /dev/sda1 on /home/henry
407 /dev/sdb6 on /home/henry/mntX
408 /dev/sdb7 on /home/henry/mntY
409 /dev/sda1 on /home/henry/home/cecilia
410 /dev/sdb6 on /home/henry/home/cecilia/mntX
411 /dev/sdb7 on /home/henry/home/cecilia/mntY
412 /dev/sda1 on /home/otto
413 /dev/sdb6 on /home/otto/mntX
414 /dev/sdb7 on /home/otto/mntY
415 /dev/sda1 on /home/otto/home/cecilia
416 /dev/sdb6 on /home/otto/home/cecilia/mntX
417 /dev/sdb7 on /home/otto/home/cecilia/mntY
418 /dev/sda1 on /home/otto/home/henry
419 /dev/sdb6 on /home/otto/home/henry/mntX
420 /dev/sdb7 on /home/otto/home/henry/mntY
421 /dev/sda1 on /home/otto/home/henry/home/cecilia
422 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
423 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
424 The mount explosion problem in the above scenario can be avoided by
426 making each of the new mounts unbindable. The effect of doing this is
427 that recursive mounts of the root directory will not replicate the un‐
428 bindable mounts. We make such a mount for the first user:
429 # mount --rbind --make-unbindable / /home/cecilia
431 Before going further, we show that unbindable mounts are indeed unbind‐
433 able:
434 # mkdir /mntZ
436 # mount --bind /home/cecilia /mntZ
437 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
438 missing codepage or helper program, or other error
439 In some cases useful info is found in syslog - try
441 dmesg | tail or so.
442 Now we create unbindable recursive bind mounts for the other two users:
444 # mount --rbind --make-unbindable / /home/henry
446 # mount --rbind --make-unbindable / /home/otto
447 Upon examining the list of mount points, we see there has been no ex‐
449 plosion of mount points, because the unbindable mounts were not repli‐
450 cated under each user's directory:
451 # mount | awk '{print $1, $2, $3}'
453 /dev/sda1 on /
454 /dev/sdb6 on /mntX
455 /dev/sdb7 on /mntY
456 /dev/sda1 on /home/cecilia
457 /dev/sdb6 on /home/cecilia/mntX
458 /dev/sdb7 on /home/cecilia/mntY
459 /dev/sda1 on /home/henry
460 /dev/sdb6 on /home/henry/mntX
461 /dev/sdb7 on /home/henry/mntY
462 /dev/sda1 on /home/otto
463 /dev/sdb6 on /home/otto/mntX
464 /dev/sdb7 on /home/otto/mntY
465 Propagation type transitions
467 The following table shows the effect that applying a new propagation
468 type (i.e., mount --make-xxxx) has on the existing propagation type of
469 a mount point. The rows correspond to existing propagation types, and
470 the columns are the new propagation settings. For reasons of space,
471 "private" is abbreviated as "priv" and "unbindable" as "unbind".
472 make-shared make-slave make-priv make-unbind
474 ─────────────┬───────────────────────────────────────────────────────
475 shared │shared slave/priv [1] priv unbind
476 slave │slave+shared slave [2] priv unbind
477 slave+shared │slave+shared slave priv unbind
478 private │shared priv [2] priv unbind
479 unbindable │shared unbind [2] priv unbind
480 Note the following details to the table:
482 [1] If a shared mount is the only mount in its peer group, making it a
484 slave automatically makes it private.
485 [2] Slaving a nonshared mount has no effect on the mount.
487 Bind (MS_BIND) semantics
489 Suppose that the following command is performed:
490 mount --bind A/a B/b
492 Here, A is the source mount point, B is the destination mount point, a
494 is a subdirectory path under the mount point A, and b is a subdirectory
495 path under the mount point B. The propagation type of the resulting
496 mount, B/b, depends on the propagation types of the mount points A and
497 B, and is summarized in the following table.
498 source(A)
500 shared private slave unbind
501 ──────────────────┬──────────────────────────────────────────
502 dest(B) shared │shared shared slave+shared invalid
503 nonshared│shared private slave invalid
504 Note that a recursive bind of a subtree follows the same semantics as
506 for a bind operation on each mount in the subtree. (Unbindable mounts
507 are automatically pruned at the target mount point.)
508 For further details, see Documentation/filesystems/sharedsubtree.txt in
510 the kernel source tree.
511 Move (MS_MOVE) semantics
513 Suppose that the following command is performed:
514 mount --move A B/b
516 Here, A is the source mount point, B is the destination mount point,
518 and b is a subdirectory path under the mount point B. The propagation
519 type of the resulting mount, B/b, depends on the propagation types of
520 the mount points A and B, and is summarized in the following table.
521 source(A)
523 shared private slave unbind
524 ──────────────────┬─────────────────────────────────────────────
525 dest(B) shared │shared shared slave+shared invalid
526 nonshared│shared private slave unbindable
527 Note: moving a mount that resides under a shared mount is invalid.
529 For further details, see Documentation/filesystems/sharedsubtree.txt in
531 the kernel source tree.
532 Mount semantics
534 Suppose that we use the following command to create a mount point:
535 mount device B/b
537 Here, B is the destination mount point, and b is a subdirectory path
539 under the mount point B. The propagation type of the resulting mount,
540 B/b, follows the same rules as for a bind mount, where the propagation
541 type of the source mount is considered always to be private.
542 Unmount semantics
544 Suppose that we use the following command to tear down a mount point:
545 unmount A
547 Here, A is a mount point on B/b, where B is the parent mount and b is a
549 subdirectory path under the mount point B. If B is shared, then all
550 most-recently-mounted mounts at b on mounts that receive propagation
551 from mount B and do not have submounts under them are unmounted.
552 The /proc/[pid]/mountinfo propagate_from tag
554 The propagate_from:X tag is shown in the optional fields of a
555 /proc/[pid]/mountinfo record in cases where a process can't see a
556 slave's immediate master (i.e., the pathname of the master is not
557 reachable from the filesystem root directory) and so cannot determine
558 the chain of propagation between the mounts it can see.
559 In the following example, we first create a two-link master-slave chain
561 between the mounts /mnt, /tmp/etc, and /mnt/tmp/etc. Then the ch‐
562 root(1) command is used to make the /tmp/etc mount point unreachable
563 from the root directory, creating a situation where the master of
564 /mnt/tmp/etc is not reachable from the (new) root directory of the
565 process.
566 First, we bind mount the root directory onto /mnt and then bind mount
568 /proc at /mnt/proc so that after the later chroot(1) the proc(5)
569 filesystem remains visible at the correct location in the chroot-ed en‐
570 vironment.
571 # mkdir -p /mnt/proc
573 # mount --bind / /mnt
574 # mount --bind /proc /mnt/proc
575 Next, we ensure that the /mnt mount is a shared mount in a new peer
577 group (with no peers):
578 # mount --make-private /mnt # Isolate from any previous peer group
580 # mount --make-shared /mnt
581 # cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
582 239 61 8:2 / /mnt ... shared:102
583 248 239 0:4 / /mnt/proc ... shared:5
584 Next, we bind mount /mnt/etc onto /tmp/etc:
586 # mkdir -p /tmp/etc
588 # mount --bind /mnt/etc /tmp/etc
589 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
590 239 61 8:2 / /mnt ... shared:102
591 248 239 0:4 / /mnt/proc ... shared:5
592 267 40 8:2 /etc /tmp/etc ... shared:102
593 Initially, these two mount points are in the same peer group, but we
595 then make the /tmp/etc a slave of /mnt/etc, and then make /tmp/etc
596 shared as well, so that it can propagate events to the next slave in
597 the chain:
598 # mount --make-slave /tmp/etc
600 # mount --make-shared /tmp/etc
601 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
602 239 61 8:2 / /mnt ... shared:102
603 248 239 0:4 / /mnt/proc ... shared:5
604 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
605 Then we bind mount /tmp/etc onto /mnt/tmp/etc. Again, the two mount
607 points are initially in the same peer group, but we then make
608 /mnt/tmp/etc a slave of /tmp/etc:
609 # mkdir -p /mnt/tmp/etc
611 # mount --bind /tmp/etc /mnt/tmp/etc
612 # mount --make-slave /mnt/tmp/etc
613 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
614 239 61 8:2 / /mnt ... shared:102
615 248 239 0:4 / /mnt/proc ... shared:5
616 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
617 273 239 8:2 /etc /mnt/tmp/etc ... master:105
618 From the above, we see that /mnt is the master of the slave /tmp/etc,
620 which in turn is the master of the slave /mnt/tmp/etc.
621 We then chroot(1) to the /mnt directory, which renders the mount with
623 ID 267 unreachable from the (new) root directory:
624 # chroot /mnt
626 When we examine the state of the mounts inside the chroot-ed environ‐
628 ment, we see the following:
629 # cat /proc/self/mountinfo | sed 's/ - .*//'
631 239 61 8:2 / / ... shared:102
632 248 239 0:4 / /proc ... shared:5
633 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
634 Above, we see that the mount with ID 273 is a slave whose master is the
636 peer group 105. The mount point for that master is unreachable, and so
637 a propagate_from tag is displayed, indicating that the closest dominant
638 peer group (i.e., the nearest reachable mount in the slave chain) is
639 the peer group with the ID 102 (corresponding to the /mnt mount point
640 before the chroot(1) was performed.
641
643 Mount namespaces first appeared in Linux 2.4.19.
644
646 Namespaces are a Linux-specific feature.
647
649 The propagation type assigned to a new mount point depends on the prop‐
650 agation type of the parent mount. If the mount point has a parent
651 (i.e., it is a non-root mount point) and the propagation type of the
652 parent is MS_SHARED, then the propagation type of the new mount is also
653 MS_SHARED. Otherwise, the propagation type of the new mount is MS_PRI‐
654 VATE.
655 Notwithstanding the fact that the default propagation type for new
657 mount points is in many cases MS_PRIVATE, MS_SHARED is typically more
658 useful. For this reason, systemd(1) automatically remounts all mount
659 points as MS_SHARED on system startup. Thus, on most modern systems,
660 the default propagation type is in practice MS_SHARED.
661 Since, when one uses unshare(1) to create a mount namespace, the goal
663 is commonly to provide full isolation of the mount points in the new
664 namespace, unshare(1) (since util-linux version 2.27) in turn reverses
665 the step performed by systemd(1), by making all mount points private in
666 the new namespace. That is, unshare(1) performs the equivalent of the
667 following in the new mount namespace:
668 mount --make-rprivate /
670 To prevent this, one can use the --propagation unchanged option to un‐
672 share(1).
673 An application that creates a new mount namespace directly using
675 clone(2) or unshare(2) may desire to prevent propagation of mount
676 events to other mount namespaces (as is done by unshare(1)). This can
677 be done by changing the propagation type of mount points in the new
678 namespace to either MS_SLAVE or MS_PRIVATE. using a call such as the
679 following:
680 mount(NULL, "/", MS_SLAVE | MS_REC, NULL);
682 For a discussion of propagation types when moving mounts (MS_MOVE) and
684 creating bind mounts (MS_BIND), see Documentation/filesystems/shared‐
685 subtree.txt.
686
688 See pivot_root(2).
689
691 unshare(1), clone(2), mount(2), pivot_root(2), setns(2), umount(2), un‐
692 share(2), proc(5), namespaces(7), user_namespaces(7), findmnt(8),
693 mount(8), pivot_root(8), umount(8)
694 Documentation/filesystems/sharedsubtree.txt in the kernel source tree.
696
698 This page is part of release 5.10 of the Linux man-pages project. A
699 description of the project, information about reporting bugs, and the
700 latest version of this page, can be found at
701 https://www.kernel.org/doc/man-pages/.
702Linux 2020-11-01 MOUNT_NAMESPACES(7)