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
14 hierarchies.
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 When a process creates a new mount namespace using clone(2) or
23 unshare(2) with the CLONE_NEWNS flag, the mount point list for the new
24 namespace is a copy of the caller's mount point list. Subsequent modi‐
25 fications to the mount point list (mount(2) and umount(2)) in either
26 mount namespace will not (by default) affect the mount point list seen
27 in the other namespace (but see the following discussion of shared sub‐
28 trees).
29 Restrictions on mount namespaces
31 Note the following points with respect to mount namespaces:
32 * A mount namespace has an owner user namespace. A mount namespace
34 whose owner user namespace is different from the owner user names‐
35 pace of its parent mount namespace is considered a less privileged
36 mount namespace.
37 * When creating a less privileged mount namespace, shared mounts are
39 reduced to slave mounts. (Shared and slave mounts are discussed
40 below.) This ensures that mappings performed in less privileged
41 mount namespaces will not propagate to more privileged mount names‐
42 paces.
43 * Mounts that come as a single unit from more privileged mount are
45 locked together and may not be separated in a less privileged mount
46 namespace. (The unshare(2) CLONE_NEWNS operation brings across all
47 of the mounts from the original mount namespace as a single unit,
48 and recursive mounts that propagate between mount namespaces propa‐
49 gate as a single unit.)
50 * The mount(2) flags MS_RDONLY, MS_NOSUID, MS_NOEXEC, and the "atime"
52 flags (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) settings become
53 locked when propagated from a more privileged to a less privileged
54 mount namespace, and may not be changed in the less privileged mount
55 namespace.
56 * A file or directory that is a mount point in one namespace that is
58 not a mount point in another namespace, may be renamed, unlinked, or
59 removed (rmdir(2)) in the mount namespace in which it is not a mount
60 point (subject to the usual permission checks).
61 Previously, attempting to unlink, rename, or remove a file or direc‐
63 tory that was a mount point in another mount namespace would result
64 in the error EBUSY. That behavior had technical problems of
65 enforcement (e.g., for NFS) and permitted denial-of-service attacks
66 against more privileged users. (i.e., preventing individual files
67 from being updated by bind mounting on top of them).
68
70 After the implementation of mount namespaces was completed, experience
71 showed that the isolation that they provided was, in some cases, too
72 great. For example, in order to make a newly loaded optical disk
73 available in all mount namespaces, a mount operation was required in
74 each namespace. For this use case, and others, the shared subtree fea‐
75 ture was introduced in Linux 2.6.15. This feature allows for auto‐
76 matic, controlled propagation of mount and unmount events between
77 namespaces (or, more precisely, between the members of a peer group
78 that are propagating events to one another).
79 Each mount point is marked (via mount(2)) as having one of the follow‐
81 ing propagation types:
82 MS_SHARED
84 This mount point shares events with members of a peer group.
85 Mount and unmount events immediately under this mount point will
86 propagate to the other mount points that are members of the peer
87 group. Propagation here means that the same mount or unmount
88 will automatically occur under all of the other mount points in
89 the peer group. Conversely, mount and unmount events that take
90 place under peer mount points will propagate to this mount
91 point.
92 MS_PRIVATE
94 This mount point is private; it does not have a peer group.
95 Mount and unmount events do not propagate into or out of this
96 mount point.
97 MS_SLAVE
99 Mount and unmount events propagate into this mount point from a
100 (master) shared peer group. Mount and unmount events under this
101 mount point do not propagate to any peer.
102 Note that a mount point can be the slave of another peer group
104 while at the same time sharing mount and unmount events with a
105 peer group of which it is a member. (More precisely, one peer
106 group can be the slave of another peer group.)
107 MS_UNBINDABLE
109 This is like a private mount, and in addition this mount can't
110 be bind mounted. Attempts to bind mount this mount (mount(2)
111 with the MS_BIND flag) will fail.
112 When a recursive bind mount (mount(2) with the MS_BIND and
114 MS_REC flags) is performed on a directory subtree, any bind
115 mounts within the subtree are automatically pruned (i.e., not
116 replicated) when replicating that subtree to produce the target
117 subtree.
118 For a discussion of the propagation type assigned to a new mount, see
120 NOTES.
121 The propagation type is a per-mount-point setting; some mount points
123 may be marked as shared (with each shared mount point being a member of
124 a distinct peer group), while others are private (or slaved or unbind‐
125 able).
126 Note that a mount's propagation type determines whether mounts and
128 unmounts of mount points immediately under the mount point are propa‐
129 gated. Thus, the propagation type does not affect propagation of
130 events for grandchildren and further removed descendant mount points.
131 What happens if the mount point itself is unmounted is determined by
132 the propagation type that is in effect for the parent of the mount
133 point.
134 Members are added to a peer group when a mount point is marked as
136 shared and either:
137 * the mount point is replicated during the creation of a new mount
139 namespace; or
140 * a new bind mount is created from the mount point.
142 In both of these cases, the new mount point joins the peer group of
144 which the existing mount point is a member. A mount ceases to be a
145 member of a peer group when either the mount is explicitly unmounted,
146 or when the mount is implicitly unmounted because a mount namespace is
147 removed (because it has no more member processes).
148 The propagation type of the mount points in a mount namespace can be
150 discovered via the "optional fields" exposed in /proc/[pid]/mountinfo.
151 (See proc(5) for details of this file.) The following tags can appear
152 in the optional fields for a record in that file:
153 shared:X
155 This mount point is shared in peer group X. Each peer group has
156 a unique ID that is automatically generated by the kernel, and
157 all mount points in the same peer group will show the same ID.
158 (These IDs are assigned starting from the value 1, and may be
159 recycled when a peer group ceases to have any members.)
160 master:X
162 This mount is a slave to shared peer group X.
163 propagate_from:X (since Linux 2.6.26)
165 This mount is a slave and receives propagation from shared peer
166 group X. This tag will always appear in conjunction with a mas‐
167 ter:X tag. Here, X is the closest dominant peer group under the
168 process's root directory. If X is the immediate master of the
169 mount, or if there is no dominant peer group under the same
170 root, then only the master:X field is present and not the propa‐
171 gate_from:X field. For further details, see below.
172 unbindable
174 This is an unbindable mount.
175 If none of the above tags is present, then this is a private mount.
177 MS_SHARED and MS_PRIVATE example
179 Suppose that on a terminal in the initial mount namespace, we mark one
180 mount point as shared and another as private, and then view the mounts
181 in /proc/self/mountinfo:
182 sh1# mount --make-shared /mntS
184 sh1# mount --make-private /mntP
185 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
186 77 61 8:17 / /mntS rw,relatime shared:1
187 83 61 8:15 / /mntP rw,relatime
188 From the /proc/self/mountinfo output, we see that /mntS is a shared
190 mount in peer group 1, and that /mntP has no optional tags, indicating
191 that it is a private mount. The first two fields in each record in
192 this file are the unique ID for this mount, and the mount ID of the
193 parent mount. We can further inspect this file to see that the parent
194 mount point of /mntS and /mntP is the root directory, /, which is
195 mounted as private:
196 sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
198 61 0 8:2 / / rw,relatime
199 On a second terminal, we create a new mount namespace where we run a
201 second shell and inspect the mounts:
202 $ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
204 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
205 222 145 8:17 / /mntS rw,relatime shared:1
206 225 145 8:15 / /mntP rw,relatime
207 The new mount namespace received a copy of the initial mount names‐
209 pace's mount points. These new mount points maintain the same propaga‐
210 tion types, but have unique mount IDs. (The --propagation unchanged
211 option prevents unshare(1) from marking all mounts as private when cre‐
212 ating a new mount namespace, which it does by default.)
213 In the second terminal, we then create submounts under each of /mntS
215 and /mntP and inspect the set-up:
216 sh2# mkdir /mntS/a
218 sh2# mount /dev/sdb6 /mntS/a
219 sh2# mkdir /mntP/b
220 sh2# mount /dev/sdb7 /mntP/b
221 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
222 222 145 8:17 / /mntS rw,relatime shared:1
223 225 145 8:15 / /mntP rw,relatime
224 178 222 8:22 / /mntS/a rw,relatime shared:2
225 230 225 8:23 / /mntP/b rw,relatime
226 From the above, it can be seen that /mntS/a was created as shared
228 (inheriting this setting from its parent mount) and /mntP/b was created
229 as a private mount.
230 Returning to the first terminal and inspecting the set-up, we see that
232 the new mount created under the shared mount point /mntS propagated to
233 its peer mount (in the initial mount namespace), but the new mount cre‐
234 ated under the private mount point /mntP did not propagate:
235 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
237 77 61 8:17 / /mntS rw,relatime shared:1
238 83 61 8:15 / /mntP rw,relatime
239 179 77 8:22 / /mntS/a rw,relatime shared:2
240 MS_SLAVE example
242 Making a mount point a slave allows it to receive propagated mount and
243 unmount events from a master shared peer group, while preventing it
244 from propagating events to that master. This is useful if we want to
245 (say) receive a mount event when an optical disk is mounted in the mas‐
246 ter shared peer group (in another mount namespace), but want to prevent
247 mount and unmount events under the slave mount from having side effects
248 in other namespaces.
249 We can demonstrate the effect of slaving by first marking two mount
251 points as shared in the initial mount namespace:
252 sh1# mount --make-shared /mntX
254 sh1# mount --make-shared /mntY
255 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
256 132 83 8:23 / /mntX rw,relatime shared:1
257 133 83 8:22 / /mntY rw,relatime shared:2
258 On a second terminal, we create a new mount namespace and inspect the
260 mount points:
261 sh2# unshare -m --propagation unchanged sh
263 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
264 168 167 8:23 / /mntX rw,relatime shared:1
265 169 167 8:22 / /mntY rw,relatime shared:2
266 In the new mount namespace, we then mark one of the mount points as a
268 slave:
269 sh2# mount --make-slave /mntY
271 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
272 168 167 8:23 / /mntX rw,relatime shared:1
273 169 167 8:22 / /mntY rw,relatime master:2
274 From the above output, we see that /mntY is now a slave mount that is
276 receiving propagation events from the shared peer group with the ID 2.
277 Continuing in the new namespace, we create submounts under each of
279 /mntX and /mntY:
280 sh2# mkdir /mntX/a
282 sh2# mount /dev/sda3 /mntX/a
283 sh2# mkdir /mntY/b
284 sh2# mount /dev/sda5 /mntY/b
285 When we inspect the state of the mount points in the new mount names‐
287 pace, we see that /mntX/a was created as a new shared mount (inheriting
288 the "shared" setting from its parent mount) and /mntY/b was created as
289 a private mount:
290 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 173 168 8:3 / /mntX/a rw,relatime shared:3
295 175 169 8:5 / /mntY/b rw,relatime
296 Returning to the first terminal (in the initial mount namespace), we
298 see that the mount /mntX/a propagated to the peer (the shared /mntX),
299 but the mount /mntY/b was not propagated:
300 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
302 132 83 8:23 / /mntX rw,relatime shared:1
303 133 83 8:22 / /mntY rw,relatime shared:2
304 174 132 8:3 / /mntX/a rw,relatime shared:3
305 Now we create a new mount point under /mntY in the first shell:
307 sh1# mkdir /mntY/c
309 sh1# mount /dev/sda1 /mntY/c
310 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
311 132 83 8:23 / /mntX rw,relatime shared:1
312 133 83 8:22 / /mntY rw,relatime shared:2
313 174 132 8:3 / /mntX/a rw,relatime shared:3
314 178 133 8:1 / /mntY/c rw,relatime shared:4
315 When we examine the mount points in the second mount namespace, we see
317 that in this case the new mount has been propagated to the slave mount
318 point, and that the new mount is itself a slave mount (to peer group
319 4):
320 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
322 168 167 8:23 / /mntX rw,relatime shared:1
323 169 167 8:22 / /mntY rw,relatime master:2
324 173 168 8:3 / /mntX/a rw,relatime shared:3
325 175 169 8:5 / /mntY/b rw,relatime
326 179 169 8:1 / /mntY/c rw,relatime master:4
327 MS_UNBINDABLE example
329 One of the primary purposes of unbindable mounts is to avoid the "mount
330 point explosion" problem when repeatedly performing bind mounts of a
331 higher-level subtree at a lower-level mount point. The problem is
332 illustrated by the following shell session.
333 Suppose we have a system with the following mount points:
335 # mount | awk '{print $1, $2, $3}'
337 /dev/sda1 on /
338 /dev/sdb6 on /mntX
339 /dev/sdb7 on /mntY
340 Suppose furthermore that we wish to recursively bind mount the root
342 directory under several users' home directories. We do this for the
343 first user, and inspect the mount points:
344 # mount --rbind / /home/cecilia/
346 # mount | awk '{print $1, $2, $3}'
347 /dev/sda1 on /
348 /dev/sdb6 on /mntX
349 /dev/sdb7 on /mntY
350 /dev/sda1 on /home/cecilia
351 /dev/sdb6 on /home/cecilia/mntX
352 /dev/sdb7 on /home/cecilia/mntY
353 When we repeat this operation for the second user, we start to see the
355 explosion problem:
356 # mount --rbind / /home/henry
358 # mount | awk '{print $1, $2, $3}'
359 /dev/sda1 on /
360 /dev/sdb6 on /mntX
361 /dev/sdb7 on /mntY
362 /dev/sda1 on /home/cecilia
363 /dev/sdb6 on /home/cecilia/mntX
364 /dev/sdb7 on /home/cecilia/mntY
365 /dev/sda1 on /home/henry
366 /dev/sdb6 on /home/henry/mntX
367 /dev/sdb7 on /home/henry/mntY
368 /dev/sda1 on /home/henry/home/cecilia
369 /dev/sdb6 on /home/henry/home/cecilia/mntX
370 /dev/sdb7 on /home/henry/home/cecilia/mntY
371 Under /home/henry, we have not only recursively added the /mntX and
373 /mntY mounts, but also the recursive mounts of those directories under
374 /home/cecilia that were created in the previous step. Upon repeating
375 the step for a third user, it becomes obvious that the explosion is
376 exponential in nature:
377 # mount --rbind / /home/otto
379 # mount | awk '{print $1, $2, $3}'
380 /dev/sda1 on /
381 /dev/sdb6 on /mntX
382 /dev/sdb7 on /mntY
383 /dev/sda1 on /home/cecilia
384 /dev/sdb6 on /home/cecilia/mntX
385 /dev/sdb7 on /home/cecilia/mntY
386 /dev/sda1 on /home/henry
387 /dev/sdb6 on /home/henry/mntX
388 /dev/sdb7 on /home/henry/mntY
389 /dev/sda1 on /home/henry/home/cecilia
390 /dev/sdb6 on /home/henry/home/cecilia/mntX
391 /dev/sdb7 on /home/henry/home/cecilia/mntY
392 /dev/sda1 on /home/otto
393 /dev/sdb6 on /home/otto/mntX
394 /dev/sdb7 on /home/otto/mntY
395 /dev/sda1 on /home/otto/home/cecilia
396 /dev/sdb6 on /home/otto/home/cecilia/mntX
397 /dev/sdb7 on /home/otto/home/cecilia/mntY
398 /dev/sda1 on /home/otto/home/henry
399 /dev/sdb6 on /home/otto/home/henry/mntX
400 /dev/sdb7 on /home/otto/home/henry/mntY
401 /dev/sda1 on /home/otto/home/henry/home/cecilia
402 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
403 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
404 The mount explosion problem in the above scenario can be avoided by
406 making each of the new mounts unbindable. The effect of doing this is
407 that recursive mounts of the root directory will not replicate the
408 unbindable mounts. We make such a mount for the first user:
409 # mount --rbind --make-unbindable / /home/cecilia
411 Before going further, we show that unbindable mounts are indeed unbind‐
413 able:
414 # mkdir /mntZ
416 # mount --bind /home/cecilia /mntZ
417 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
418 missing codepage or helper program, or other error
419 In some cases useful info is found in syslog - try
421 dmesg | tail or so.
422 Now we create unbindable recursive bind mounts for the other two users:
424 # mount --rbind --make-unbindable / /home/henry
426 # mount --rbind --make-unbindable / /home/otto
427 Upon examining the list of mount points, we see there has been no
429 explosion of mount points, because the unbindable mounts were not
430 replicated under each user's directory:
431 # mount | awk '{print $1, $2, $3}'
433 /dev/sda1 on /
434 /dev/sdb6 on /mntX
435 /dev/sdb7 on /mntY
436 /dev/sda1 on /home/cecilia
437 /dev/sdb6 on /home/cecilia/mntX
438 /dev/sdb7 on /home/cecilia/mntY
439 /dev/sda1 on /home/henry
440 /dev/sdb6 on /home/henry/mntX
441 /dev/sdb7 on /home/henry/mntY
442 /dev/sda1 on /home/otto
443 /dev/sdb6 on /home/otto/mntX
444 /dev/sdb7 on /home/otto/mntY
445 Propagation type transitions
447 The following table shows the effect that applying a new propagation
448 type (i.e., mount --make-xxxx) has on the existing propagation type of
449 a mount point. The rows correspond to existing propagation types, and
450 the columns are the new propagation settings. For reasons of space,
451 "private" is abbreviated as "priv" and "unbindable" as "unbind".
452 make-shared make-slave make-priv make-unbind
454 shared shared slave/priv [1] priv unbind
455 slave slave+shared slave [2] priv unbind
456 slave+shared slave+shared slave priv unbind
457 private shared priv [2] priv unbind
458 unbindable shared unbind [2] priv unbind
459 Note the following details to the table:
461 [1] If a shared mount is the only mount in its peer group, making it a
463 slave automatically makes it private.
464 [2] Slaving a nonshared mount has no effect on the mount.
466 Bind (MS_BIND) semantics
468 Suppose that the following command is performed:
469 mount --bind A/a B/b
471 Here, A is the source mount point, B is the destination mount point, a
473 is a subdirectory path under the mount point A, and b is a subdirectory
474 path under the mount point B. The propagation type of the resulting
475 mount, B/b, depends on the propagation types of the mount points A and
476 B, and is summarized in the following table.
477 source(A)
479 shared private slave unbind
480 ───────────────────────────────────────────────────────────────
481 dest(B) shared | shared shared slave+shared invalid
482 nonshared | shared private slave invalid
483 Note that a recursive bind of a subtree follows the same semantics as
485 for a bind operation on each mount in the subtree. (Unbindable mounts
486 are automatically pruned at the target mount point.)
487 For further details, see Documentation/filesystems/sharedsubtree.txt in
489 the kernel source tree.
490 Move (MS_MOVE) semantics
492 Suppose that the following command is performed:
493 mount --move A B/b
495 Here, A is the source mount point, B is the destination mount point,
497 and b is a subdirectory path under the mount point B. The propagation
498 type of the resulting mount, B/b, depends on the propagation types of
499 the mount points A and B, and is summarized in the following table.
500 source(A)
502 shared private slave unbind
503 ──────────────────────────────────────────────────────────────────
504 dest(B) shared | shared shared slave+shared invalid
505 nonshared | shared private slave unbindable
506 Note: moving a mount that resides under a shared mount is invalid.
508 For further details, see Documentation/filesystems/sharedsubtree.txt in
510 the kernel source tree.
511 Mount semantics
513 Suppose that we use the following command to create a mount point:
514 mount device B/b
516 Here, B is the destination mount point, and b is a subdirectory path
518 under the mount point B. The propagation type of the resulting mount,
519 B/b, follows the same rules as for a bind mount, where the propagation
520 type of the source mount is considered always to be private.
521 Unmount semantics
523 Suppose that we use the following command to tear down a mount point:
524 unmount A
526 Here, A is a mount point on B/b, where B is the parent mount and b is a
528 subdirectory path under the mount point B. If B is shared, then all
529 most-recently-mounted mounts at b on mounts that receive propagation
530 from mount B and do not have submounts under them are unmounted.
531 The /proc/[pid]/mountinfo propagate_from tag
533 The propagate_from:X tag is shown in the optional fields of a
534 /proc/[pid]/mountinfo record in cases where a process can't see a
535 slave's immediate master (i.e., the pathname of the master is not
536 reachable from the filesystem root directory) and so cannot determine
537 the chain of propagation between the mounts it can see.
538 In the following example, we first create a two-link master-slave chain
540 between the mounts /mnt, /tmp/etc, and /mnt/tmp/etc. Then the
541 chroot(1) command is used to make the /tmp/etc mount point unreachable
542 from the root directory, creating a situation where the master of
543 /mnt/tmp/etc is not reachable from the (new) root directory of the
544 process.
545 First, we bind mount the root directory onto /mnt and then bind mount
547 /proc at /mnt/proc so that after the later chroot(1) the proc(5)
548 filesystem remains visible at the correct location in the chroot-ed
549 environment.
550 # mkdir -p /mnt/proc
552 # mount --bind / /mnt
553 # mount --bind /proc /mnt/proc
554 Next, we ensure that the /mnt mount is a shared mount in a new peer
556 group (with no peers):
557 # mount --make-private /mnt # Isolate from any previous peer group
559 # mount --make-shared /mnt
560 # cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
561 239 61 8:2 / /mnt ... shared:102
562 248 239 0:4 / /mnt/proc ... shared:5
563 Next, we bind mount /mnt/etc onto /tmp/etc:
565 # mkdir -p /tmp/etc
567 # mount --bind /mnt/etc /tmp/etc
568 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
569 239 61 8:2 / /mnt ... shared:102
570 248 239 0:4 / /mnt/proc ... shared:5
571 267 40 8:2 /etc /tmp/etc ... shared:102
572 Initially, these two mount points are in the same peer group, but we
574 then make the /tmp/etc a slave of /mnt/etc, and then make /tmp/etc
575 shared as well, so that it can propagate events to the next slave in
576 the chain:
577 # mount --make-slave /tmp/etc
579 # mount --make-shared /tmp/etc
580 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
581 239 61 8:2 / /mnt ... shared:102
582 248 239 0:4 / /mnt/proc ... shared:5
583 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
584 Then we bind mount /tmp/etc onto /mnt/tmp/etc. Again, the two mount
586 points are initially in the same peer group, but we then make
587 /mnt/tmp/etc a slave of /tmp/etc:
588 # mkdir -p /mnt/tmp/etc
590 # mount --bind /tmp/etc /mnt/tmp/etc
591 # mount --make-slave /mnt/tmp/etc
592 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
593 239 61 8:2 / /mnt ... shared:102
594 248 239 0:4 / /mnt/proc ... shared:5
595 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
596 273 239 8:2 /etc /mnt/tmp/etc ... master:105
597 From the above, we see that /mnt is the master of the slave /tmp/etc,
599 which in turn is the master of the slave /mnt/tmp/etc.
600 We then chroot(1) to the /mnt directory, which renders the mount with
602 ID 267 unreachable from the (new) root directory:
603 # chroot /mnt
605 When we examine the state of the mounts inside the chroot-ed environ‐
607 ment, we see the following:
608 # cat /proc/self/mountinfo | sed 's/ - .*//'
610 239 61 8:2 / / ... shared:102
611 248 239 0:4 / /proc ... shared:5
612 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
613 Above, we see that the mount with ID 273 is a slave whose master is the
615 peer group 105. The mount point for that master is unreachable, and so
616 a propagate_from tag is displayed, indicating that the closest dominant
617 peer group (i.e., the nearest reachable mount in the slave chain) is
618 the peer group with the ID 102 (corresponding to the /mnt mount point
619 before the chroot(1) was performed.
620
622 Mount namespaces first appeared in Linux 2.4.19.
623
625 Namespaces are a Linux-specific feature.
626
628 The propagation type assigned to a new mount point depends on the prop‐
629 agation type of the parent directory. If the mount point has a parent
630 (i.e., it is a non-root mount point) and the propagation type of the
631 parent is MS_SHARED, then the propagation type of the new mount is also
632 MS_SHARED. Otherwise, the propagation type of the new mount is MS_PRI‐
633 VATE. But see also NOTES.
634 Notwithstanding the fact that the default propagation type for new
636 mount points is in many cases MS_PRIVATE, MS_SHARED is typically more
637 useful. For this reason, systemd(1) automatically remounts all mount
638 points as MS_SHARED on system startup. Thus, on most modern systems,
639 the default propagation type is in practice MS_SHARED.
640 Since, when one uses unshare(1) to create a mount namespace, the goal
642 is commonly to provide full isolation of the mount points in the new
643 namespace, unshare(1) (since util-linux version 2.27) in turn reverses
644 the step performed by systemd(1), by making all mount points private in
645 the new namespace. That is, unshare(1) performs the equivalent of the
646 following in the new mount namespace:
647 mount --make-rprivate /
649 To prevent this, one can use the --propagation unchanged option to
651 unshare(1).
652 For a discussion of propagation types when moving mounts (MS_MOVE) and
654 creating bind mounts (MS_BIND), see Documentation/filesystems/shared‐
655 subtree.txt.
656
658 unshare(1), clone(2), mount(2), setns(2), umount(2), unshare(2),
659 proc(5), namespaces(7), user_namespaces(7)
660 Documentation/filesystems/sharedsubtree.txt in the kernel source tree.
662
664 This page is part of release 4.15 of the Linux man-pages project. A
665 description of the project, information about reporting bugs, and the
666 latest version of this page, can be found at
667 https://www.kernel.org/doc/man-pages/.
668Linux 2017-09-15 MOUNT_NAMESPACES(7)