https://nalar.dev/tags/mount-namespaces/ Recent content in Mount Namespaces on Nalar Hugo en-us Fri, 18 Sep 2026 00:00:00 +0000 https://nalar.dev/idmapped-mounts-remap-file-ownership-without-rewriting-inodes/ Fri, 18 Sep 2026 00:00:00 +0000 https://nalar.dev/idmapped-mounts-remap-file-ownership-without-rewriting-inodes/ <h1 id="idmapped-mounts-remap-file-ownership-without-rewriting-inodes">Idmapped Mounts Remap File Ownership Without Rewriting Inodes</h1> <p>A container needs read-write access to a directory whose files carry host ownership values that do not line up with the container&rsquo;s user namespace. Recursively changing ownership can make the directory usable, but it also mutates persistent inode metadata and can disrupt every other view of the same filesystem. Linux idmapped mounts provide a narrower mechanism: one mount can apply a different identity mapping while the stored ownership remains intact.</p> https://nalar.dev/mount-propagation-defines-the-filesystem-boundary-between-linux-mount-namespaces/ Fri, 18 Sep 2026 00:00:00 +0000 https://nalar.dev/mount-propagation-defines-the-filesystem-boundary-between-linux-mount-namespaces/ <p>A process can enter a new Linux mount namespace and still observe a later mount created elsewhere. The namespace boundary is intact: the process has its own mount table. The new mount appears because some mounts in the two namespaces remain connected by propagation relationships.</p> <p>This distinction matters in container runtimes, service sandboxes, build systems, and privileged helpers. Creating a mount namespace separates the namespace&rsquo;s view of the mount table, but it does not by itself make every future mount event local. Shared-subtree state determines whether mount and unmount events cross that boundary.</p>