Inspect Mounted Filesystem State Through /proc/fs

You will finish with a safe way to inspect the filesystem-specific information exposed below /proc/fs/, identify which mounted filesystem a directory belongs to, and avoid treating a diagnostic file as a configuration interface. The examples use 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 within procfs. Start by checking the filesystem that supplies the path:

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

The exact options can differ. The useful checks are that the target is /proc and the filesystem type is proc. If findmnt is not installed, the kernel's mount table provides a read-only fallback:

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

Your line may include 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 containing subdirectories with information about certain mounted filesystems. It does not promise that every filesystem will appear, or that a particular kernel will expose 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 host-specific. A minimal result is not automatically a fault, and an empty directory is valid evidence that no filesystem-specific branches are exposed there at the time of the check. A directory name is an implementation detail, not proof that all mounts of that filesystem have a corresponding entry.

Checkpoint: record the names printed on your host before looking for a particular file. This prevents a common distraction, where a command copied from another machine is assumed to apply locally.

3. Inspect one branch without changing state

Walk one level deeper and show regular files as well as 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 printed by your own command. On this host, for example, the entries include /proc/fs/ext4/md1/options and /proc/fs/jbd2/md1-8/info. Do not assume that those names exist on another kernel, or that a device name is a mount-point name.

Read a known file only after checking 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. Their names, fields and values are not defined by the short proc_fs(5) entry. Treat their contents as diagnostics unless the filesystem's own documentation explicitly says that a file is writable and explains the supported operation.

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

The rows and filesystem types will differ. The point is correlation: findmnt reports mounts, while /proc/fs/ exposes branches and files selected by filesystem implementations. There is no general rule that lets you turn a branch name directly into a mount point. Compare device identifiers, then verify the path with findmnt -T /path/to/mount if you need to identify one particular mount.

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

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

If the path is inside a bind mount, overlay, container, or namespace, the answer may not resemble the host's ordinary device layout. Run the check in the same namespace and account whose behaviour you are 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 deliberate, especially when procfs is mounted with privacy-related options or when a file is restricted by the filesystem implementation. sudo cat may make a readable diagnostic visible, but it does not create a missing branch and does not make an unsupported write safe.

Do not redirect output back into a file below /proc/fs/ as a test. Shell redirection opens the destination before the command runs, and a writable procfs control file can change live kernel or filesystem behaviour immediately. If you are unsure whether an entry is an administrative control, stop and consult documentation for that filesystem and kernel.

6. Diagnose an empty or changing result

Repeat the listing when another service is 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 disappear as modules and filesystems are loaded, mounts change, or a process exits. A failed read can therefore mean that the file vanished 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 runs. In a container, the visible procfs may intentionally be restricted. Do not repair that by remounting procfs from a running service without first establishing the container and host ownership of the mount.