3

There is another question discussing about umounting rbind mounts, but the solution has unwanted effect. Consider the following directory layout:

.
├── A_dir
│   └── mount_b
├── B_dir
│   └── mount_c
└── C_dir

Now I bind C_dir to B_dir/mount_c and rbind B_dir to A_dir/mount_b:

[hidden]$ sudo mount --bind C_dir B_dir/mount_c
[hidden]$ sudo mount --rbind B_dir A_dir/mount_b
[hidden]$ mount | grep _dir | wc -l
3

Now umount A_dir/mount_b will fail, which is not surprising. According to the answers everywhere on the web, we need to umount A_dir/mount_b/mount_c first then umount A_dir/mount_b. However, umount A_dir/mount_b/mount_c will also unmount B_dir/mount_c, which is unwanted:

[hidden]$ sudo umount A_dir/mount_b/mount_c
[hidden]$ mount | grep _dir | wc -l
1

Now my question is, how do I unmount A_dir/mount_b but leaving B_dir unaffected, i.e. there is still a bind B_dir/mount_c to C_dir?

Thanks.

Community
  • 1
icando
  • 229
  • 2
  • 8
  • 2
    I've been noticing this for *non*-recursive bind mounts. /subscribe. http://unix.stackexchange.com/questions/269695/mounting-new-filesystem-affects-non-recursive-bind-mounts – sourcejedi Apr 15 '16 at 12:42

1 Answers1

2

Found it. https://unix.stackexchange.com/a/276700/29483

Try --make-rprivate:

mount --make-rprivate A_dir
umount -R A_dir

Note: systemd people, who set your described behaviour as the new default, recommend that you would not make the rbind mount private initially. It's ok to do just before unmount though.

It's because when you clone all the mounts, you might e.g. then need to eject a CD. If it was mounted at clone-time, enabling propagation means you only need to run umount on one location only (e.g. outside the rbind mount, just like normal), and then you'll be able to eject it.

Community
  • 1
sourcejedi
  • 1,050
  • 10
  • 19