Home / server / Questions / 868682
Accepted
Tom Hale
Asked: 2017-08-15 23:47:44 +0800 CST

Implications of `mount --make-private /`

  • 772

Currently, / has shared mount propagation:

# findmnt -o TARGET,PROPAGATION /
TARGET PROPAGATION
/      shared

I am considering changing it to private to enable mount --move to work on filesystems mounted under /mnt and /media.

(I want to use mount --move rather than the unsafe umount --lazy)

Without / being private, mount --move will complain with something like:

# mount --move /mnt/mountpoint /mnt/moved
mount: /mnt/moved: bad option; moving a mount residing under a shared mount is unsupported.

  1. Why is / shared by default?

  2. What are the implications of changing / to be private?

linux

1 Answers

  1. Best Answer

    The propagation flag is changed by systemd. From man 7 mount_namespaces:

    systemd(1) automatically remounts all mount points as MS_SHARED on system startup. Thus, on most modern systems, the default propagation type is in practice MS_SHARED.

    From https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L406

      /* Mark the root directory as shared in regards to mount propagation. The kernel defaults to "private", but we
     * think it makes more sense to have a default of "shared" so that nspawn and the container tools work out of
     * the box. If specific setups need other settings they can reset the propagation mode to private if
     * needed. Note that we set this only when we are invoked directly by the kernel. If we are invoked by a
     * container manager we assume the container manager knows what it is doing (for example, because it set up
     * some directories with different propagation modes). */
    if (detect_container() <= 0)
            if (mount(NULL, "/", NULL, MS_REC|MS_SHARED, NULL) < 0)

    The implications depend on your particular use cases. I think that most programs will continue to work. However, your change will be overwritten on reboot.

    You can read more in the comment from Lennart Poettering in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739593

    Here is a part of it:

    b) If you patch systemd to go back to MS_PRIVATE for the root dir, you disable propagation to containers, and nobody can opt-in to it anymore for their specific namespace.

    Advantage: you don't have to patch those few programs which currently assume the root dir is MS_PRIVATE and don't disassociate things.

    Disadvantage: the apps are still broken for those who switch to MS_SHARED for /. You hence only cover the usecases where people do not dissassocitate. You break the usecase where people want the propagation to tkae place.

    • 3