Home / Alt manpages / proc_mounts(5)

  • proc_mounts(5)
  • File format
  • linux

Read a Process Mount Namespace from /proc/mounts

You will finish with a safe way to inspect the filesystems visible to a process, compare that view with another process, and recognise when a mount listing belongs to a different mount namespace. The examples use the Linux man-pages 6.7 documentation, installed here as package version 6.7-2.

Allow about ten minutes. You need a shell and access to procfs. These checks are read-only and normally need no elevated privileges. You do not need to mount or unmount anything, so this guide does not change system state.

1. Confirm the procfs files you are reading

The canonical per-process file is /proc/pid/mounts. Replace pid with a numeric process ID. The special path /proc/self/mounts means the mount namespace of the process doing the read. On modern Linux, /proc/mounts is a link to that same per-process view.

Check the relationship rather than relying on memory:

$ readlink /proc/mounts
self/mounts
$ readlink /proc/self/mounts || true
$ test -r /proc/self/mounts && echo readable
readable

/proc/self/mounts is a procfs file, not normally a symbolic link, so the second readlink can print nothing. The useful checkpoint is the final line and a successful exit status from test.

2. Read the current process's mount list

Print a short sample first. Every line describes one mounted filesystem, but device names, paths and options are host-specific:

$ sed -n '1,8p' /proc/self/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
udev /dev devtmpfs rw,nosuid,relatime,size=...,mode=755 0 0
...

Do not treat the sample values as defaults. The first field identifies the source, the second is the mount point, the third is the filesystem type, and the fourth contains comma-separated mount options. The final two fields use the fstab convention for dump and filesystem-check metadata. The exact values depend on the kernel, filesystem and how the host was started.

For a compact, script-friendly view of the records, use findmnt as a separate inspection tool:

$ findmnt --kernel --output SOURCE,TARGET,FSTYPE,OPTIONS --first-only /proc
SOURCE TARGET FSTYPE OPTIONS
proc   /proc  proc   rw,relatime

Column spacing and options vary. The command asks util-linux to locate the kernel mount record for /proc; it does not alter the mount. When a script needs the raw procfs format, read the file directly instead of treating findmnt's display as an API.

3. Compare your view with another process

A path under /proc is resolved for the process ID in the path. Choose a long-lived, readable process, then compare its list with your own:

$ pid=1
$ test -r "/proc/$pid/mounts" && echo "mount list readable for PID $pid"
mount list readable for PID 1
$ wc -l /proc/self/mounts "/proc/$pid/mounts"
      28 /proc/self/mounts
      28 /proc/1/mounts
      56 total
$ diff -u /proc/self/mounts "/proc/$pid/mounts"

Zero output from diff means the two files were identical at the time they were read. Different output is not automatically an error: the processes may be in different mount namespaces, or a mount may have changed between the two reads. A process can also disappear while you are inspecting it, producing a normal read error.

Do not use a process ID copied from an old incident report. PIDs are reused. Check the process identity before drawing a conclusion:

$ ps -p "$pid" -o pid=,comm=,args=
      1 /sbin/init /sbin/init

The output is host-specific. If it names an unexpected process, stop and choose the intended PID again.

4. Read a record without losing the namespace context

When a service reports a path as missing, inspect the service's mount view, not just your interactive shell's view. A simple record count and mount-point search can establish what that process can see:

$ service_pid=12345
$ test -r "/proc/$service_pid/mounts" || { echo "cannot read mount list"; exit 1; }
$ awk '$2 == "/data" { print }' "/proc/$service_pid/mounts"
/dev/mapper/example /data ext4 rw,relatime 0 0

Replace 12345 and /data with values from your system. No output means that exact mount-point field was not present when the file was read. It does not prove the path is unusable: a bind mount, an over-mounted directory, permissions, or a later mount event can change the result. Follow up with the service's own logs and process identity.

The fields follow fstab-style escaping. A space in a source or mount point is represented as an escape such as \040, rather than as a literal field separator. Avoid a naive parser that assumes every whitespace-separated token is a complete path. For robust software, use a mount-table parser appropriate to your language or the system's getmntent(3) interface.

5. Watch for mount changes when writing a monitor

The manpage documents a special polling behaviour. After a process opens its mount file for reading, a mount or unmount in that process's namespace causes poll(2) and epoll_wait(2) to report a priority event, POLLPRI. This is a notification that the file changed, not a parsed event containing the new mount.

For a monitor, reopen or reread the file after the notification and compare the new records with the previous snapshot. Treat the contents as a point-in-time view: mounts can change again before your reader processes the notification. The behaviour described here is for Linux 2.6.15 and later. The older pre-2.6.30 indication used different readiness flags, so code supporting old kernels must account for that historical difference.

Do not test this by mounting arbitrary filesystems on a production host. That requires elevated privileges and can affect services, isolation and data access. A disposable namespace or test machine is the right place for an integration test; ordinary inspection does not require sudo.

6. Avoid the common traps

  • Confusing /proc/mounts with every mount on the host: it shows the namespace of the process reading it. Compare the target process's file when namespace isolation matters.
  • Assuming the listing is stable: mounts and unmounts can happen while you read. Take a fresh snapshot when a decision depends on it.
  • Parsing paths by splitting on spaces: fstab-style escaping means a visible path may contain encoded whitespace. Preserve and decode fields deliberately.
  • Using a stale PID: verify /proc/pid/comm or ps before interpreting the listing.
  • Treating a mount listing as an access check: visibility does not prove that the process can open, modify or execute anything at the mount point.

Done means

  • You can read the current process's mounts through /proc/self/mounts.
  • You know that /proc/mounts resolves to the reader's own mount view.
  • You can inspect /proc/pid/mounts after checking which process owns the PID.
  • You can explain different listings without assuming corruption or a host-wide view.
  • Your scripts account for fstab-style escaping and reread the file after a polling notification.
  • You have made no mount, unmount, service or persistent configuration change.