Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange
2 Slightly more clarity again.
source | link

If you are on a systemd based distribution with a util-linux version less than 2.27, you will see this unintuitive behaviour. This is because CLONE_NEWNS propogates flags such as shared depending on a setting in the kernel. This setting is normally private, but systemd changes this to shared. As of util-linux 2.27, a patch was made that changes the default behaviour of the unshare command to use private as the default propagation behaviour as to be more intuitive.

Solution

If you are on a systemd system with <2.27 util-linux, you must remount the root filesystem after running the unshare command:

# unshare --mount -- /bin/bash
# mount --make-private -o remount /

If you are on a systemd system with >=2.27 util-linux, it should work as expected in the example you gave in your question, ifverbatim, without the need to remount. If not: pass --propagation private to the unshare command to force the propagation of the mount namespace to be private.

If you are on a systemd based distribution with a util-linux version less than 2.27, you will see this unintuitive behaviour. This is because CLONE_NEWNS propogates flags such as shared depending on a setting in the kernel. This setting is normally private, but systemd changes this to shared. As of util-linux 2.27, a patch was made that changes the default behaviour of the unshare command to use private as the default propagation behaviour as to be more intuitive.

Solution

If you are on a systemd system with <2.27 util-linux, you must remount the root filesystem after running the unshare command:

# unshare --mount -- /bin/bash
# mount --make-private -o remount /

If you are on a systemd system with >=2.27 util-linux, it should work as expected, if not: pass --propagation private to the unshare command to force the propagation of the mount namespace to be private.

If you are on a systemd based distribution with a util-linux version less than 2.27, you will see this unintuitive behaviour. This is because CLONE_NEWNS propogates flags such as shared depending on a setting in the kernel. This setting is normally private, but systemd changes this to shared. As of util-linux 2.27, a patch was made that changes the default behaviour of the unshare command to use private as the default propagation behaviour as to be more intuitive.

Solution

If you are on a systemd system with <2.27 util-linux, you must remount the root filesystem after running the unshare command:

# unshare --mount -- /bin/bash
# mount --make-private -o remount /

If you are on a systemd system with >=2.27 util-linux, it should work as expected in the example you gave in your question, verbatim, without the need to remount. If not: pass --propagation private to the unshare command to force the propagation of the mount namespace to be private.

1
source | link

If you are on a systemd based distribution with a util-linux version less than 2.27, you will see this unintuitive behaviour. This is because CLONE_NEWNS propogates flags such as shared depending on a setting in the kernel. This setting is normally private, but systemd changes this to shared. As of util-linux 2.27, a patch was made that changes the default behaviour of the unshare command to use private as the default propagation behaviour as to be more intuitive.

Solution

If you are on a systemd system with <2.27 util-linux, you must remount the root filesystem after running the unshare command:

# unshare --mount -- /bin/bash
# mount --make-private -o remount /

If you are on a systemd system with >=2.27 util-linux, it should work as expected, if not: pass --propagation private to the unshare command to force the propagation of the mount namespace to be private.