1MOUNT_NAMESPACES(7)        Linux Programmer's Manual       MOUNT_NAMESPACES(7)
2
3
4

NAME

6       mount_namespaces - overview of Linux mount namespaces
7

DESCRIPTION

9       For an overview of namespaces, see namespaces(7).
10
11       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
16       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
22       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
30   Restrictions on mount namespaces
31       Note the following points with respect to mount namespaces:
32
33       *  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
38       *  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
44       *  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
51       *  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
57       *  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
62          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

SHARED SUBTREES

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
80       Each mount point is marked (via mount(2)) as having one of the  follow‐
81       ing propagation types:
82
83       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
93       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
98       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
103              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
108       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
113              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
119       For  a  discussion of the propagation type assigned to a new mount, see
120       NOTES.
121
122       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
127       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
135       Members  are  added  to  a  peer  group when a mount point is marked as
136       shared and either:
137
138       *  the mount point is replicated during the creation  of  a  new  mount
139          namespace; or
140
141       *  a new bind mount is created from the mount point.
142
143       In  both  of  these  cases, the new mount point joins the peer group of
144       which the existing mount point is a member.
145
146       A new peer group is also created when a child mount  point  is  created
147       under  an existing mount point that is marked as shared.  In this case,
148       the new child mount point is also marked as shared  and  the  resulting
149       peer  group  consists of all the mount points that are replicated under
150       the peers of parent mount.
151
152       A mount ceases to be a member of a peer group when either the mount  is
153       explicitly unmounted, or when the mount is implicitly unmounted because
154       a mount namespace is removed (because it has no more member processes).
155
156       The propagation type of the mount points in a mount  namespace  can  be
157       discovered  via the "optional fields" exposed in /proc/[pid]/mountinfo.
158       (See proc(5) for details of this file.)  The following tags can  appear
159       in the optional fields for a record in that file:
160
161       shared:X
162              This mount point is shared in peer group X.  Each peer group has
163              a unique ID that is automatically generated by the  kernel,  and
164              all  mount  points in the same peer group will show the same ID.
165              (These IDs are assigned starting from the value 1,  and  may  be
166              recycled when a peer group ceases to have any members.)
167
168       master:X
169              This mount is a slave to shared peer group X.
170
171       propagate_from:X (since Linux 2.6.26)
172              This  mount is a slave and receives propagation from shared peer
173              group X.  This tag will always appear in conjunction with a mas‐
174              ter:X tag.  Here, X is the closest dominant peer group under the
175              process's root directory.  If X is the immediate master  of  the
176              mount,  or  if  there  is  no dominant peer group under the same
177              root, then only the master:X field is present and not the propa‐
178              gate_from:X field.  For further details, see below.
179
180       unbindable
181              This is an unbindable mount.
182
183       If none of the above tags is present, then this is a private mount.
184
185   MS_SHARED and MS_PRIVATE example
186       Suppose  that on a terminal in the initial mount namespace, we mark one
187       mount point as shared and another as private, and then view the  mounts
188       in /proc/self/mountinfo:
189
190           sh1# mount --make-shared /mntS
191           sh1# mount --make-private /mntP
192           sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
193           77 61 8:17 / /mntS rw,relatime shared:1
194           83 61 8:15 / /mntP rw,relatime
195
196       From  the  /proc/self/mountinfo  output,  we see that /mntS is a shared
197       mount in peer group 1, and that /mntP has no optional tags,  indicating
198       that  it  is  a  private mount.  The first two fields in each record in
199       this file are the unique ID for this mount, and the  mount  ID  of  the
200       parent  mount.  We can further inspect this file to see that the parent
201       mount point of /mntS and /mntP is  the  root  directory,  /,  which  is
202       mounted as private:
203
204           sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
205           61 0 8:2 / / rw,relatime
206
207       On  a  second  terminal, we create a new mount namespace where we run a
208       second shell and inspect the mounts:
209
210           $ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
211           sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
212           222 145 8:17 / /mntS rw,relatime shared:1
213           225 145 8:15 / /mntP rw,relatime
214
215       The new mount namespace received a copy of  the  initial  mount  names‐
216       pace's mount points.  These new mount points maintain the same propaga‐
217       tion types, but have unique mount  IDs.   (The  --propagation unchanged
218       option prevents unshare(1) from marking all mounts as private when cre‐
219       ating a new mount namespace, which it does by default.)
220
221       In the second terminal, we then create submounts under  each  of  /mntS
222       and /mntP and inspect the set-up:
223
224           sh2# mkdir /mntS/a
225           sh2# mount /dev/sdb6 /mntS/a
226           sh2# mkdir /mntP/b
227           sh2# mount /dev/sdb7 /mntP/b
228           sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
229           222 145 8:17 / /mntS rw,relatime shared:1
230           225 145 8:15 / /mntP rw,relatime
231           178 222 8:22 / /mntS/a rw,relatime shared:2
232           230 225 8:23 / /mntP/b rw,relatime
233
234       From  the  above,  it  can  be  seen that /mntS/a was created as shared
235       (inheriting this setting from its parent mount) and /mntP/b was created
236       as a private mount.
237
238       Returning  to the first terminal and inspecting the set-up, we see that
239       the new mount created under the shared mount point /mntS propagated  to
240       its peer mount (in the initial mount namespace), but the new mount cre‐
241       ated under the private mount point /mntP did not propagate:
242
243           sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
244           77 61 8:17 / /mntS rw,relatime shared:1
245           83 61 8:15 / /mntP rw,relatime
246           179 77 8:22 / /mntS/a rw,relatime shared:2
247
248   MS_SLAVE example
249       Making a mount point a slave allows it to receive propagated mount  and
250       unmount  events  from  a  master shared peer group, while preventing it
251       from propagating events to that master.  This is useful if we  want  to
252       (say) receive a mount event when an optical disk is mounted in the mas‐
253       ter shared peer group (in another mount namespace), but want to prevent
254       mount and unmount events under the slave mount from having side effects
255       in other namespaces.
256
257       We can demonstrate the effect of slaving by  first  marking  two  mount
258       points as shared in the initial mount namespace:
259
260           sh1# mount --make-shared /mntX
261           sh1# mount --make-shared /mntY
262           sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
263           132 83 8:23 / /mntX rw,relatime shared:1
264           133 83 8:22 / /mntY rw,relatime shared:2
265
266       On  a  second terminal, we create a new mount namespace and inspect the
267       mount points:
268
269           sh2# unshare -m --propagation unchanged sh
270           sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
271           168 167 8:23 / /mntX rw,relatime shared:1
272           169 167 8:22 / /mntY rw,relatime shared:2
273
274       In the new mount namespace, we then mark one of the mount points  as  a
275       slave:
276
277           sh2# mount --make-slave /mntY
278           sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
279           168 167 8:23 / /mntX rw,relatime shared:1
280           169 167 8:22 / /mntY rw,relatime master:2
281
282       From  the  above output, we see that /mntY is now a slave mount that is
283       receiving propagation events from the shared peer group with the ID 2.
284
285       Continuing in the new namespace, we  create  submounts  under  each  of
286       /mntX and /mntY:
287
288           sh2# mkdir /mntX/a
289           sh2# mount /dev/sda3 /mntX/a
290           sh2# mkdir /mntY/b
291           sh2# mount /dev/sda5 /mntY/b
292
293       When  we  inspect the state of the mount points in the new mount names‐
294       pace, we see that /mntX/a was created as a new shared mount (inheriting
295       the  "shared" setting from its parent mount) and /mntY/b was created as
296       a private mount:
297
298           sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
299           168 167 8:23 / /mntX rw,relatime shared:1
300           169 167 8:22 / /mntY rw,relatime master:2
301           173 168 8:3 / /mntX/a rw,relatime shared:3
302           175 169 8:5 / /mntY/b rw,relatime
303
304       Returning to the first terminal (in the initial  mount  namespace),  we
305       see  that  the mount /mntX/a propagated to the peer (the shared /mntX),
306       but the mount /mntY/b was not propagated:
307
308           sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
309           132 83 8:23 / /mntX rw,relatime shared:1
310           133 83 8:22 / /mntY rw,relatime shared:2
311           174 132 8:3 / /mntX/a rw,relatime shared:3
312
313       Now we create a new mount point under /mntY in the first shell:
314
315           sh1# mkdir /mntY/c
316           sh1# mount /dev/sda1 /mntY/c
317           sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
318           132 83 8:23 / /mntX rw,relatime shared:1
319           133 83 8:22 / /mntY rw,relatime shared:2
320           174 132 8:3 / /mntX/a rw,relatime shared:3
321           178 133 8:1 / /mntY/c rw,relatime shared:4
322
323       When we examine the mount points in the second mount namespace, we  see
324       that  in this case the new mount has been propagated to the slave mount
325       point, and that the new mount is itself a slave mount  (to  peer  group
326       4):
327
328           sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
329           168 167 8:23 / /mntX rw,relatime shared:1
330           169 167 8:22 / /mntY rw,relatime master:2
331           173 168 8:3 / /mntX/a rw,relatime shared:3
332           175 169 8:5 / /mntY/b rw,relatime
333           179 169 8:1 / /mntY/c rw,relatime master:4
334
335   MS_UNBINDABLE example
336       One of the primary purposes of unbindable mounts is to avoid the "mount
337       point explosion" problem when repeatedly performing bind  mounts  of  a
338       higher-level  subtree  at  a  lower-level  mount point.  The problem is
339       illustrated by the following shell session.
340
341       Suppose we have a system with the following mount points:
342
343           # mount | awk '{print $1, $2, $3}'
344           /dev/sda1 on /
345           /dev/sdb6 on /mntX
346           /dev/sdb7 on /mntY
347
348       Suppose furthermore that we wish to recursively  bind  mount  the  root
349       directory  under  several  users' home directories.  We do this for the
350       first user, and inspect the mount points:
351
352           # mount --rbind / /home/cecilia/
353           # mount | awk '{print $1, $2, $3}'
354           /dev/sda1 on /
355           /dev/sdb6 on /mntX
356           /dev/sdb7 on /mntY
357           /dev/sda1 on /home/cecilia
358           /dev/sdb6 on /home/cecilia/mntX
359           /dev/sdb7 on /home/cecilia/mntY
360
361       When we repeat this operation for the second user, we start to see  the
362       explosion problem:
363
364           # mount --rbind / /home/henry
365           # mount | awk '{print $1, $2, $3}'
366           /dev/sda1 on /
367           /dev/sdb6 on /mntX
368           /dev/sdb7 on /mntY
369           /dev/sda1 on /home/cecilia
370           /dev/sdb6 on /home/cecilia/mntX
371           /dev/sdb7 on /home/cecilia/mntY
372           /dev/sda1 on /home/henry
373           /dev/sdb6 on /home/henry/mntX
374           /dev/sdb7 on /home/henry/mntY
375           /dev/sda1 on /home/henry/home/cecilia
376           /dev/sdb6 on /home/henry/home/cecilia/mntX
377           /dev/sdb7 on /home/henry/home/cecilia/mntY
378
379       Under  /home/henry,  we  have  not only recursively added the /mntX and
380       /mntY mounts, but also the recursive mounts of those directories  under
381       /home/cecilia  that  were created in the previous step.  Upon repeating
382       the step for a third user, it becomes obvious  that  the  explosion  is
383       exponential in nature:
384
385           # mount --rbind / /home/otto
386           # mount | awk '{print $1, $2, $3}'
387           /dev/sda1 on /
388           /dev/sdb6 on /mntX
389           /dev/sdb7 on /mntY
390           /dev/sda1 on /home/cecilia
391           /dev/sdb6 on /home/cecilia/mntX
392           /dev/sdb7 on /home/cecilia/mntY
393           /dev/sda1 on /home/henry
394           /dev/sdb6 on /home/henry/mntX
395           /dev/sdb7 on /home/henry/mntY
396           /dev/sda1 on /home/henry/home/cecilia
397           /dev/sdb6 on /home/henry/home/cecilia/mntX
398           /dev/sdb7 on /home/henry/home/cecilia/mntY
399           /dev/sda1 on /home/otto
400           /dev/sdb6 on /home/otto/mntX
401           /dev/sdb7 on /home/otto/mntY
402           /dev/sda1 on /home/otto/home/cecilia
403           /dev/sdb6 on /home/otto/home/cecilia/mntX
404           /dev/sdb7 on /home/otto/home/cecilia/mntY
405           /dev/sda1 on /home/otto/home/henry
406           /dev/sdb6 on /home/otto/home/henry/mntX
407           /dev/sdb7 on /home/otto/home/henry/mntY
408           /dev/sda1 on /home/otto/home/henry/home/cecilia
409           /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
410           /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
411
412       The  mount  explosion  problem  in the above scenario can be avoided by
413       making each of the new mounts unbindable.  The effect of doing this  is
414       that  recursive  mounts  of  the  root directory will not replicate the
415       unbindable mounts.  We make such a mount for the first user:
416
417           # mount --rbind --make-unbindable / /home/cecilia
418
419       Before going further, we show that unbindable mounts are indeed unbind‐
420       able:
421
422           # mkdir /mntZ
423           # mount --bind /home/cecilia /mntZ
424           mount: wrong fs type, bad option, bad superblock on /home/cecilia,
425                  missing codepage or helper program, or other error
426
427                  In some cases useful info is found in syslog - try
428                  dmesg | tail or so.
429
430       Now we create unbindable recursive bind mounts for the other two users:
431
432           # mount --rbind --make-unbindable / /home/henry
433           # mount --rbind --make-unbindable / /home/otto
434
435       Upon  examining  the  list  of  mount  points, we see there has been no
436       explosion of mount points,  because  the  unbindable  mounts  were  not
437       replicated under each user's directory:
438
439           # mount | awk '{print $1, $2, $3}'
440           /dev/sda1 on /
441           /dev/sdb6 on /mntX
442           /dev/sdb7 on /mntY
443           /dev/sda1 on /home/cecilia
444           /dev/sdb6 on /home/cecilia/mntX
445           /dev/sdb7 on /home/cecilia/mntY
446           /dev/sda1 on /home/henry
447           /dev/sdb6 on /home/henry/mntX
448           /dev/sdb7 on /home/henry/mntY
449           /dev/sda1 on /home/otto
450           /dev/sdb6 on /home/otto/mntX
451           /dev/sdb7 on /home/otto/mntY
452
453   Propagation type transitions
454       The  following  table  shows the effect that applying a new propagation
455       type (i.e., mount --make-xxxx) has on the existing propagation type  of
456       a  mount point.  The rows correspond to existing propagation types, and
457       the columns are the new propagation settings.  For  reasons  of  space,
458       "private" is abbreviated as "priv" and "unbindable" as "unbind".
459
460                     make-shared   make-slave      make-priv  make-unbind
461       shared        shared        slave/priv [1]  priv       unbind
462
463       slave         slave+shared  slave [2]       priv       unbind
464       slave+shared  slave+shared  slave           priv       unbind
465       private       shared        priv [2]        priv       unbind
466       unbindable    shared        unbind [2]      priv       unbind
467
468       Note the following details to the table:
469
470       [1] If  a shared mount is the only mount in its peer group, making it a
471           slave automatically makes it private.
472
473       [2] Slaving a nonshared mount has no effect on the mount.
474
475   Bind (MS_BIND) semantics
476       Suppose that the following command is performed:
477
478           mount --bind A/a B/b
479
480       Here, A is the source mount point, B is the destination mount point,  a
481       is a subdirectory path under the mount point A, and b is a subdirectory
482       path under the mount point B.  The propagation type  of  the  resulting
483       mount,  B/b, depends on the propagation types of the mount points A and
484       B, and is summarized in the following table.
485
486                                    source(A)
487                            shared  private    slave         unbind
488       ───────────────────────────────────────────────────────────────
489       dest(B)  shared    | shared  shared     slave+shared  invalid
490                nonshared | shared  private    slave         invalid
491
492       Note that a recursive bind of a subtree follows the same  semantics  as
493       for  a bind operation on each mount in the subtree.  (Unbindable mounts
494       are automatically pruned at the target mount point.)
495
496       For further details, see Documentation/filesystems/sharedsubtree.txt in
497       the kernel source tree.
498
499   Move (MS_MOVE) semantics
500       Suppose that the following command is performed:
501
502           mount --move A B/b
503
504       Here,  A  is  the source mount point, B is the destination mount point,
505       and b is a subdirectory path under the mount point B.  The  propagation
506       type  of  the resulting mount, B/b, depends on the propagation types of
507       the mount points A and B, and is summarized in the following table.
508
509                                    source(A)
510                            shared  private    slave         unbind
511       ──────────────────────────────────────────────────────────────────
512       dest(B)  shared    | shared  shared     slave+shared  invalid
513                nonshared | shared  private    slave         unbindable
514
515       Note: moving a mount that resides under a shared mount is invalid.
516
517       For further details, see Documentation/filesystems/sharedsubtree.txt in
518       the kernel source tree.
519
520   Mount semantics
521       Suppose that we use the following command to create a mount point:
522
523           mount device B/b
524
525       Here,  B  is  the destination mount point, and b is a subdirectory path
526       under the mount point B.  The propagation type of the resulting  mount,
527       B/b,  follows the same rules as for a bind mount, where the propagation
528       type of the source mount is considered always to be private.
529
530   Unmount semantics
531       Suppose that we use the following command to tear down a mount point:
532
533           unmount A
534
535       Here, A is a mount point on B/b, where B is the parent mount and b is a
536       subdirectory  path  under  the mount point B.  If B is shared, then all
537       most-recently-mounted mounts at b on mounts  that  receive  propagation
538       from mount B and do not have submounts under them are unmounted.
539
540   The /proc/[pid]/mountinfo propagate_from tag
541       The  propagate_from:X  tag  is  shown  in  the  optional  fields  of  a
542       /proc/[pid]/mountinfo record in cases  where  a  process  can't  see  a
543       slave's  immediate  master  (i.e.,  the  pathname  of the master is not
544       reachable from the filesystem root directory) and so  cannot  determine
545       the chain of propagation between the mounts it can see.
546
547       In the following example, we first create a two-link master-slave chain
548       between  the  mounts  /mnt,  /tmp/etc,  and  /mnt/tmp/etc.   Then   the
549       chroot(1)  command is used to make the /tmp/etc mount point unreachable
550       from the root directory, creating  a  situation  where  the  master  of
551       /mnt/tmp/etc  is  not  reachable  from  the (new) root directory of the
552       process.
553
554       First, we bind mount the root directory onto /mnt and then  bind  mount
555       /proc  at  /mnt/proc  so  that  after  the  later chroot(1) the proc(5)
556       filesystem remains visible at the correct  location  in  the  chroot-ed
557       environment.
558
559           # mkdir -p /mnt/proc
560           # mount --bind / /mnt
561           # mount --bind /proc /mnt/proc
562
563       Next,  we  ensure  that  the /mnt mount is a shared mount in a new peer
564       group (with no peers):
565
566           # mount --make-private /mnt  # Isolate from any previous peer group
567           # mount --make-shared /mnt
568           # cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
569           239 61 8:2 / /mnt ... shared:102
570           248 239 0:4 / /mnt/proc ... shared:5
571
572       Next, we bind mount /mnt/etc onto /tmp/etc:
573
574           # mkdir -p /tmp/etc
575           # mount --bind /mnt/etc /tmp/etc
576           # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
577           239 61 8:2 / /mnt ... shared:102
578           248 239 0:4 / /mnt/proc ... shared:5
579           267 40 8:2 /etc /tmp/etc ... shared:102
580
581       Initially, these two mount points are in the same peer  group,  but  we
582       then  make  the  /tmp/etc  a  slave of /mnt/etc, and then make /tmp/etc
583       shared as well, so that it can propagate events to the  next  slave  in
584       the chain:
585
586           # mount --make-slave /tmp/etc
587           # mount --make-shared /tmp/etc
588           # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
589           239 61 8:2 / /mnt ... shared:102
590           248 239 0:4 / /mnt/proc ... shared:5
591           267 40 8:2 /etc /tmp/etc ... shared:105 master:102
592
593       Then  we  bind  mount /tmp/etc onto /mnt/tmp/etc.  Again, the two mount
594       points are  initially  in  the  same  peer  group,  but  we  then  make
595       /mnt/tmp/etc a slave of /tmp/etc:
596
597           # mkdir -p /mnt/tmp/etc
598           # mount --bind /tmp/etc /mnt/tmp/etc
599           # mount --make-slave /mnt/tmp/etc
600           # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
601           239 61 8:2 / /mnt ... shared:102
602           248 239 0:4 / /mnt/proc ... shared:5
603           267 40 8:2 /etc /tmp/etc ... shared:105 master:102
604           273 239 8:2 /etc /mnt/tmp/etc ... master:105
605
606       From  the  above, we see that /mnt is the master of the slave /tmp/etc,
607       which in turn is the master of the slave /mnt/tmp/etc.
608
609       We then chroot(1) to the /mnt directory, which renders the  mount  with
610       ID 267 unreachable from the (new) root directory:
611
612           # chroot /mnt
613
614       When  we  examine the state of the mounts inside the chroot-ed environ‐
615       ment, we see the following:
616
617           # cat /proc/self/mountinfo | sed 's/ - .*//'
618           239 61 8:2 / / ... shared:102
619           248 239 0:4 / /proc ... shared:5
620           273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
621
622       Above, we see that the mount with ID 273 is a slave whose master is the
623       peer group 105.  The mount point for that master is unreachable, and so
624       a propagate_from tag is displayed, indicating that the closest dominant
625       peer  group  (i.e.,  the nearest reachable mount in the slave chain) is
626       the peer group with the ID 102 (corresponding to the /mnt  mount  point
627       before the chroot(1) was performed.
628

VERSIONS

630       Mount namespaces first appeared in Linux 2.4.19.
631

CONFORMING TO

633       Namespaces are a Linux-specific feature.
634

NOTES

636       The propagation type assigned to a new mount point depends on the prop‐
637       agation type of the parent directory.  If the mount point has a  parent
638       (i.e.,  it  is  a non-root mount point) and the propagation type of the
639       parent is MS_SHARED, then the propagation type of the new mount is also
640       MS_SHARED.  Otherwise, the propagation type of the new mount is MS_PRI‐
641       VATE.  But see also NOTES.
642
643       Notwithstanding the fact that the  default  propagation  type  for  new
644       mount  points  is in many cases MS_PRIVATE, MS_SHARED is typically more
645       useful.  For this reason, systemd(1) automatically remounts  all  mount
646       points  as  MS_SHARED on system startup.  Thus, on most modern systems,
647       the default propagation type is in practice MS_SHARED.
648
649       Since, when one uses unshare(1) to create a mount namespace,  the  goal
650       is  commonly  to  provide full isolation of the mount points in the new
651       namespace, unshare(1) (since util-linux version 2.27) in turn  reverses
652       the step performed by systemd(1), by making all mount points private in
653       the new namespace.  That is, unshare(1) performs the equivalent of  the
654       following in the new mount namespace:
655
656           mount --make-rprivate /
657
658       To  prevent  this,  one  can  use the --propagation unchanged option to
659       unshare(1).
660
661       For a discussion of propagation types when moving mounts (MS_MOVE)  and
662       creating  bind  mounts (MS_BIND), see Documentation/filesystems/shared‐
663       subtree.txt.
664

SEE ALSO

666       unshare(1),  clone(2),  mount(2),  setns(2),   umount(2),   unshare(2),
667       proc(5), namespaces(7), user_namespaces(7)
668
669       Documentation/filesystems/sharedsubtree.txt in the kernel source tree.
670

COLOPHON

672       This  page  is  part of release 4.16 of the Linux man-pages project.  A
673       description of the project, information about reporting bugs,  and  the
674       latest     version     of     this    page,    can    be    found    at
675       https://www.kernel.org/doc/man-pages/.
676
677
678
679Linux                             2018-04-30               MOUNT_NAMESPACES(7)
Impressum