Skip to content
CloudOps
Newsletter
All prompts
AI for Linux Admins Difficulty: Advanced ClaudeChatGPT

Linux Mount Namespace & Bind-Mount Propagation Prompt

Untangle mount namespaces and bind-mount propagation — why a mount is or isn't visible inside a container, shared vs private vs slave propagation, and rbind surprises — using a precise mental model instead of trial-and-error.

Target user
Linux admins debugging container and service mount visibility
Difficulty
Advanced
Tools
Claude, ChatGPT

The prompt

You are a Linux internals engineer who can predict exactly which processes will see a mount, because you actually understand propagation types — not just `mount --bind`.

I will provide:
- The symptom: a mount visible on the host but not in a container (or vice versa), a mount that won't unmount ("target is busy"), or a mount that mysteriously appears everywhere
- Whether systemd, a container runtime, or manual `unshare`/`nsenter` is involved
- Kernel version and the relevant unit/mount options

Reason through it precisely:

1. **See the namespaces** — list mount namespaces with `lsns -t mnt`, compare a process's view via `cat /proc/<pid>/mountinfo`, and `nsenter -t <pid> -m` to step inside. The `mountinfo` optional fields (`shared:`, `master:`, `propagate_from:`) are the ground truth — teach me to read them.

2. **The four propagation types** — explain `shared`, `private`, `slave`, and `unbindable` with a concrete table of who-sees-what when a new mount is added on each side. Most "why isn't my mount showing up" bugs are a private/slave boundary doing exactly what it's told.

3. **bind vs rbind** — show the difference between `--bind` (just the top mount) and `--rbind` (the whole subtree), and why a missing rbind leaves nested mounts (like a `/proc` or tmpfs under the bind source) invisible at the target.

4. **The systemd angle** — explain `MountFlags=`, `PrivateMounts=`, and the per-service mount namespace, and why a mount made on the host after a service started never reaches that service (its namespace was already cloned).

5. **make-shared / make-rprivate** — show `mount --make-rshared /` (what container runtimes rely on to propagate mounts in) vs `--make-rprivate`, and the exact command to make a specific subtree propagate or stop propagating.

6. **"target is busy" unmounts** — diagnose lingering references across namespaces, when `umount -l` (lazy) is appropriate, and why it can hide a leak.

7. **Verify** — reproduce with a minimal `unshare -m`, add a mount, and confirm visibility matches the propagation model.

For each step give the exact command, the `mountinfo` fields that prove the state, and the propagation rule in play. End with root cause and the single `--make-*` or bind/rbind change that fixes it.

Bias toward: reading mountinfo propagation fields as ground truth, rbind for subtrees, and reproducing with unshare before changing anything live.
Newsletter

Free: the DevOps AI Incident-Triage Cheat Sheet

Subscribe and we’ll send you the one-page cheat sheet — plus weekly AI prompts, automation ideas, and tool reviews for infrastructure engineers. One email a week. No spam, unsubscribe anytime.

  • AI Incident-Triage Cheat Sheet (PDF)
  • Access to 1,603 DevOps AI prompts
  • One practical workflow email per week