Course contentsShow
← Linux
Lesson 1499 of 1,81913. Containerization Primitives and NamespacesFree lesson

Shared subtree concepts

Configure bidirectional mount propagation to allow host and container to sync shared storage.

In this lesson, you will learn how to configure bidirectional mount propagation to allow the host and container to stay perfectly synchronized regarding their filesystem mounts.

The Problem: Isolation vs. Synchronization

By default, Linux mount namespaces are isolated. When you create a new mount namespace for a container, mounting a filesystem on the host does not automatically appear inside the container. While this is great for security, it creates a hurdle when you need a "shared" mount point—like a global configuration directory or a high-performance shared buffer—where additions or unmounts on one side must be reflected on the other.

Shared Subtree Concepts

To solve this, Linux uses mount propagation. A mount point can be marked with a propagation type that dictates how mount events flow between peers:

  1. shared: Changes propagate in both directions. If you mount a drive on the host, it appears in the container; if you unmount it inside the container, it disappears on the host.
  2. slave: Changes flow in one direction (from a master to a slave).
  3. private: The default; no propagation occurs.

Configuring Bidirectional Sync

To achieve bidirectional sync, you must mark the mount point as shared in both the host and the container namespaces. On the host, you can set the root or a specific directory to be shared using the mount command:

# Mark /mnt/data as a shared mount point
mount --make-shared /mnt/data

Once a mount is shared, it becomes part of a "peer group." Any new mount created under that path will automatically propagate to all other members of that group. When you spawn your container, you ensure the mount namespace respects this by passing the appropriate propagation flag (often handled by the container runtime via mount --bind and mount --make-shared).

This allows the container and host to treat a specific storage volume as a unified synchronization zone. Even if a process inside the container mounts a sub-partition or a secondary disk within that shared directory, the host will immediately see the new mount point, ensuring that both environments maintain a consistent view of the filesystem hierarchy.

Key Takeaway: By marking a mount point as shared, you create a peer group where all mount and unmount operations propagate bidirectionally, allowing the host and container to maintain synchronized access to shared storage paths.