In this lesson, you will learn how to identify and prune persistent mount namespaces that prevent clean unmount operations and resource reclamation.
The Anatomy of an Orphaned Mount
When a process enters a new mount namespace (CLONE_NEWNS) and mounts a filesystem, the kernel maintains a reference count on that namespace. Even if the original process that created the namespace exits, the namespace can persist if other processes or "ghost" file descriptors remain attached to it. These "orphaned mounts" often manifest as device or resource busy errors when attempting to unmount a parent filesystem or delete a container runtime root.
Locating the Ghost
To debug these, we first look at /proc. Since we have already mastered Procfs and Sysfs Namespace Inspection (Lesson 11), we know that every namespace is represented by an inode. You can find active mount namespaces by scanning process entries, but orphaned namespaces are trickier because they aren't always tied to a running task.
A common culprit is a "stale" bind mount or a process that has kept a file descriptor open to a directory inside the namespace. You can use lsns to list all namespaces, but for deep debugging, examine the reference count:
# Identify processes keeping a namespace alive
lsns -t mnt
# Inspect who is holding an open file descriptor in that namespace
# Replace <PID> with the ID found in lsns
ls -l /proc/<PID>/fd/
Cleaning Up
If a namespace is held open by a zombie or a leaked mount point, you cannot force-unmount it from the parent namespace easily because the kernel protects the integrity of the mount tree. If you identify a process holding a mount, you must terminate the process or force it to close the descriptor.
If the namespace itself is truly orphaned (no processes attached, but kernel ref-count > 0), check for sub-mounts within that namespace. Often, a recursive mount or a FUSE mount that failed to exit cleanly keeps the kernel namespace structure alive. You can verify if a mount point is preventing the namespace from being garbage collected by checking cat /proc/self/mountinfo within the target namespace's context using nsenter.
Key Takeaway: Orphaned mount namespaces persist due to leaked file descriptors or sub-mounts, and must be reclaimed by identifying the holding process via lsns and cleaning up active mount points before the kernel can perform garbage collection.