Read a Process Mount Namespace with /proc/pid/mounts

By the end, you will be able to list the filesystems visible to a particular Linux process, compare that view with your own, and detect when its mount list changes. The examples only read procfs. Allow about 10 minutes, plus time to investigate any namespace differences you find.

Before you start

You need a Linux shell with procfs mounted at /proc. The behaviour described here comes from the installed proc_pid_mounts(5) page in Linux man-pages 6.7, dated 2023-08-15. You do not need elevated privileges to inspect your own mount namespace. Access to another process can be restricted by procfs permissions, so do not assume that root access is appropriate or necessary.

A mount namespace is the process-specific view of mounted filesystems. Containers commonly have a different view from the host. The file is a snapshot-like text interface: each record describes one mount, and the format is the same format documented for fstab(5).

Checkpoint: inspect your own view

1. Print the first few records from your shell's mount namespace.

sed -n '1,5p' /proc/self/mounts

Typical output has six whitespace-separated fields. The first is the filesystem source, the second is its mount point, and the third is the filesystem type. The fourth contains mount options. The final two fields are the dump and filesystem check values used by the fstab(5) format.

sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
tmpfs /run tmpfs rw,nosuid,nodev,noexec,relatime,size=3264464k,mode=755 0 0

Your sources, options and mount points will differ. Do not copy the sample lines as configuration. They are only an illustration of the record shape.

Checkpoint: use a numeric process ID

Replace PID with the process you want to examine. For a process you own, this is an ordinary read operation:

PID=12345
sed -n '1,20p' "/proc/$PID/mounts"

Use a real process ID from ps, a service manager, or the program that launched the process. A process can exit between choosing its ID and opening the file. If that happens, the path disappears or the read fails; check the process again rather than treating an empty result as a mount namespace with no filesystems.

For a quick self-contained check, the shell's process ID is available from $$:

printf 'PID: %s
' "$$"
sed -n '1,3p' "/proc/$$/mounts"

Do not confuse the three similar paths

/proc/pid/mounts reports the mount namespace of the process represented by pid. /proc/self/mounts reports the namespace of the process doing the read. The special self component is resolved by procfs for each reader, so it is useful in scripts that should follow the script's current namespace.

/proc/mounts is retained for compatibility. On current Linux it is a link to /proc/self/mounts, so it shows the reader's namespace, not a universal list of every mount visible across the machine. Verify the relationship on this system:

readlink /proc/mounts
cmp -s /proc/mounts /proc/self/mounts
printf 'same contents: exit status %s
' "$?"

The readlink command may print nothing on a procfs implementation that does not expose the link target in the usual way. The comparison is the useful check: a zero status means the two reads matched at that moment. They can change between separate reads if a mount operation happens concurrently.

Compare a process with your shell

To investigate a container or service, save neither file permanently nor modify the process. Compare the mount lists directly:

PID=12345
diff -u /proc/self/mounts "/proc/$PID/mounts"

No output means the two reads matched. Lines beginning with - are mounts visible to your shell but absent from the target process's view. Lines beginning with + are present in the target view but absent from yours. A non-zero status from diff is expected when the lists differ, not proof that the command failed.

Mount points containing spaces, tabs, backslashes or special characters are escaped in the procfs text representation. Treat this as a machine-readable representation of the fstab(5) format, not as a list that can always be split safely with a simple shell loop. If you need structured mount information, use a parser that understands the format and its escaping rules.

Watch for mount and unmount changes

The manpage documents a useful event interface. Open /proc/pid/mounts for reading, then poll the file descriptor. A mount or unmount in that process's namespace produces a priority event, POLLPRI, for poll(2) and epoll_wait(2). The event tells you that the mount list changed; reread the file to obtain the current records.

This is not a shell tail -f stream. The file does not append one line per event. A watcher must open the target path, wait for the exceptional condition, then perform a fresh read and handle the process disappearing. Code using select(2) should watch for its exceptional condition too. Very old kernels used different readiness indications, but Linux 2.6.30 and later use the priority-event behaviour described above.

Common traps and safe boundaries

• Reading the wrong namespace: /proc/mounts follows the reader. Use the target PID path when the process matters.
• Assuming host visibility: a process can legitimately omit mounts that are visible to your shell, especially across a container boundary.
• Using a stale PID: PIDs can be reused. Confirm the process identity immediately before reading if the result affects an operational decision.
• Expecting a stable file: mounts can change while you read. For a consistent operational decision, reread after an event and handle changes in your code.
• Trying to configure through this file: /proc/pid/mounts is an observation interface. The examples here do not mount, unmount or alter anything, and no elevated command is required.

If a read fails, first check that /proc is mounted and that the PID still exists. Then check the permissions on the proc entry. Do not work around an access failure by changing procfs permissions or moving mounts unless that change is part of a separately reviewed system administration task.

Done means

• You can read /proc/self/mounts and recognise its six-field record format.
• You can read /proc/PID/mounts for a confirmed process ID.
• You know that /proc/mounts follows the reader's namespace.
• You can compare namespace views with diff and interpret its exit status.
• You know that mount changes are reported as POLLPRI events and require a fresh read.