Inspect Mounted Filesystem State Through /proc/fs

Every filesystem that wants to publish its own status drops a branch under /proc/fs/, which is why the layout differs on every machine. This guide shows a safe way to browse those branches, work out which mounted filesystem a directory actually belongs to, and stop mistaking a diagnostic file for a configuration interface. It uses the installed proc_fs(5) entry from Linux man-pages 6.7 on a Linux 6.8 host.

Allow about ten minutes. You need a shell and read access to /proc, which is normally available to an ordinary user. The guide only reads directory entries and status files: it does not mount, unmount, remount or reconfigure anything, so no elevated privileges should be needed.

1. Confirm that procfs is mounted

/proc/fs/ is a directory inside procfs. Start by checking the filesystem that actually supplies the path:

$ findmnt -T /proc/fs -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET SOURCE FSTYPE OPTIONS
/proc  proc   proc   rw,relatime

Exact options can differ. What matters is that the target is /proc and the filesystem type is proc. If findmnt is not installed, the kernel's mount table gives you a read-only fallback:

$ grep ' /proc ' /proc/mounts
proc /proc proc rw,relatime,hidepid=2 0 0

Your line may show different options or a different mount source. Do not copy the example into /etc/fstab: it is illustrative output, not a recommended mount configuration.

2. List the filesystem-specific branches

The manpage describes /proc/fs/ as holding subdirectories with information about certain mounted filesystems. It does not promise every filesystem will appear, or that any particular kernel exposes the same names. List what this machine actually provides:

$ find /proc/fs -mindepth 1 -maxdepth 1 -type d -printf '%f\n' | sort
ext4
jbd2
nfsd

That output is entirely host-specific. A short result is not automatically a fault, and an empty directory is valid evidence that no filesystem-specific branches happen to be exposed there right now. A directory name is an implementation detail, not proof that every mount of that filesystem has a matching entry.

3. Inspect one branch without changing state

Walk one level deeper and show regular files alongside the directories:

$ find /proc/fs -maxdepth 3 -type f -printf '%p\n' | sort
/proc/fs/ext4/DEVICE_ID/options
/proc/fs/jbd2/DEVICE_ID/info

Replace DEVICE_ID with the names your own command actually printed. On this host, for example, the entries include /proc/fs/ext4/md1/options and /proc/fs/jbd2/md1-8/info. Do not assume those exact names carry over to another kernel, or that a device name doubles as a mount-point name.

Read a known file only once you have checked that it exists:

$ status_file=/proc/fs/ext4/DEVICE_ID/options
$ if test -r "$status_file"; then
>     sed -n '1,30p' "$status_file"
> else
>     printf 'not readable or not present: %s\n' "$status_file" >&2
> fi
rw
bsddf
... host-specific lines ...

These files are text representations supplied by the kernel or a filesystem driver, and their names, fields and values are not defined by the short proc_fs(5) entry itself. Treat the contents as diagnostics unless the filesystem's own documentation explicitly says a file is writable and explains what writing to it does.

4. Relate an entry to a mounted filesystem

Use the mount table to see the actual mounted devices and filesystem types:

$ findmnt -t ext4,jbd2,nfs,nfs4 -o TARGET,SOURCE,FSTYPE
TARGET SOURCE FSTYPE
/srv   /dev/DEVICE ext4
/var   /dev/DEVICE ext4

Rows and filesystem types will differ on your machine. The point is correlation: findmnt reports mounts, while /proc/fs/ exposes branches and files chosen by each filesystem implementation. There is no general rule for turning a branch name straight into a mount point. Compare device identifiers, then verify the path with findmnt -T /path/to/mount if you need to pin down one particular mount.

For example, this asks which filesystem backs a path without editing anything:

$ findmnt -T /var -o TARGET,SOURCE,FSTYPE,OPTIONS
TARGET SOURCE     FSTYPE OPTIONS
/      /dev/ROOT  ext4   rw,relatime

If the path sits inside a bind mount, overlay, container, or namespace, the answer may not look anything like the host's ordinary device layout. Run the check in the same namespace and account whose behaviour you are actually investigating.

5. Check permissions before reaching for sudo

Most inspection is unprivileged. Check the directory and file permissions directly:

$ stat -c '%A %U:%G %n' /proc/fs /proc/fs/ext4/DEVICE_ID/options
dr-xr-xr-x root root /proc/fs
-r--r--r-- root root /proc/fs/ext4/DEVICE_ID/options

These are example shapes, not fixed output. A permission error can be entirely deliberate, especially when procfs is mounted with privacy-related options or a file is restricted by the filesystem implementation itself. sudo cat may make a readable diagnostic visible, but it does not create a missing branch and does not make an unsupported write safe.

6. Diagnose an empty or changing result

Repeat the listing when another service is busy mounting, unmounting or reconfiguring filesystems:

$ find /proc/fs -maxdepth 3 -printf '%y %p\n' | sort
d /proc/fs
d /proc/fs/ext4
f /proc/fs/ext4/DEVICE_ID/options

Procfs is a live view. Entries can appear or vanish as modules and filesystems load, mounts change, or a process exits, so a failed read can simply mean the file disappeared between discovery and access. Re-run the discovery command and quote paths in scripts.

If /proc/fs itself is absent, check the mount shown by findmnt -T /proc and whether procfs is mounted in the namespace where the command actually runs. In a container, the visible procfs may be intentionally restricted. Do not try to fix that by remounting procfs from a running service without first establishing who owns the container and host mount.