Read /proc/filesystems and Check Mount Support Safely

You will finish with a quick way to inspect the filesystem types registered by the running Linux kernel, distinguish virtual filesystems from block-backed ones, and use the result when investigating a mount failure. The examples describe the local machine's behaviour without changing mounts or kernel settings.

Allow about ten minutes. You need a shell and a readable /proc mount. The reference installed here is Linux man-pages 6.7 from the manpages package version 6.7-2. The list is produced by the kernel, so your output will depend on the kernel configuration and modules loaded at the time you read it.

1. Read the kernel's list

Run this ordinary, read-only command as your normal user:

$ cat /proc/filesystems

Each line contains a filesystem type. Some lines begin with nodev, followed by the type name. On this host, the beginning of the list looks like this:

nodev	sysfs
nodev	tmpfs
nodev	bdev
nodev	proc
nodev	cgroup
nodev	cgroup2
	 ext4

The spacing is significant enough to preserve the two fields, but do not treat the exact order or membership as portable. It is a snapshot of filesystem types currently supported by this kernel: types compiled into it, plus types supplied by modules that are currently loaded.

Checkpoint: confirm that the file exists and has at least one non-empty line:

$ test -s /proc/filesystems && printf '%s\n' 'filesystem list is readable'
filesystem list is readable

2. Interpret the nodev marker

nodev does not mean that the filesystem cannot be mounted. It says that the filesystem does not require a block device as its backing source. That is normal for virtual filesystems such as proc, sysfs and tmpfs, and for some network or userspace filesystem arrangements.

A line without nodev identifies a filesystem type that can use a block device. For example, ext4, xfs or btrfs normally interpret a device or image as their source. This marker describes the filesystem type's mount model; it does not say whether the type is mounted now, whether a particular device contains a valid filesystem, or whether your account is allowed to mount it.

To separate the two groups without relying on visual alignment, use awk:

$ awk '($1 == "nodev") { print "no block device:", $2; next } { print "block-backed:", $1 }' /proc/filesystems

Expected output includes lines like these, although the complete list is host-specific:

no block device: proc
no block device: sysfs
block-backed: ext4
block-backed: squashfs

Do not use the presence of nodev as a security decision by itself. A virtual filesystem can still expose sensitive kernel or process information, and access is also controlled by mount options, permissions, namespaces and other kernel policy.

3. Check one type precisely

When diagnosing a script or configuration, check for an exact field rather than searching for an unanchored substring. This avoids treating a name such as fuseblk as a match for a different value:

$ filesystem_type='ext4'
$ awk -v wanted="$filesystem_type" '($1 == wanted) || ($1 == "nodev" && $2 == wanted) { found=1; print; exit } END { if (!found) exit 1 }' /proc/filesystems
	ext4

A printed line means the kernel has registered that type at the time of the check. A non-zero status means it is not in this list. It does not prove that a module package is absent: a filesystem module can exist on disk but not be loaded. It also does not prove that a mount will succeed, because the source, mountpoint, options, permissions and filesystem contents still matter.

For a readable status message in a shell script:

filesystem_type='ext4'
if awk -v wanted="$filesystem_type" '($1 == wanted) || ($1 == "nodev" && $2 == wanted) { found=1; exit } END { exit !found }' /proc/filesystems
then
    printf 'kernel knows filesystem type %s\n' "$filesystem_type"
else
    printf 'filesystem type %s is not registered\n' "$filesystem_type" >&2
    exit 1
fi

4. Relate the list to mount troubleshooting

The mount command may consult /proc/filesystems when no filesystem type was supplied and it could not determine the type another way. It tries the listed types except those marked nodev. This is a fallback, not a guarantee that guessing is safe or correct.

For a block device, first identify the device and its detected type with a read-only command:

$ lsblk -f /dev/DEVICE
$ blkid /dev/DEVICE

Replace /dev/DEVICE with a real device path. These commands only inspect metadata. If they report a type, prefer an explicit mount operation such as:

$ sudo mount -t ext4 /dev/DEVICE /mnt/TARGET

This is the first state-changing example: it needs elevated privileges on a normally configured system and attaches storage at the target directory. Check the device, filesystem type and mountpoint carefully before pressing Enter. Mounting the wrong device can expose, obscure or alter access to data at the target. Do not use a guessed device or a production mountpoint for a test.

If the command succeeds, verify the actual result rather than relying on the absence of an error:

$ findmnt --target /mnt/TARGET
TARGET      SOURCE      FSTYPE OPTIONS
/mnt/TARGET /dev/DEVICE ext4   rw,relatime

The source and options vary by host. To undo this particular test mount, leave the directory and unmount the exact target:

$ cd /
$ sudo umount /mnt/TARGET

Unmounting can disrupt processes that are using the mount. If it reports that the target is busy, inspect users with fuser -vm /mnt/TARGET or lsof +D /mnt/TARGET, stop only the processes you understand, and retry. Do not force an unmount as a first response.

5. Handle missing or surprising entries

An absent entry can have several explanations. The running kernel may not include support, the relevant module may not be loaded, or /proc may be unavailable or mounted in an unusual environment such as a container. Compare the command's result with the kernel and environment you are actually troubleshooting:

$ uname -r
$ findmnt --target /proc
$ test -r /proc/filesystems && sed -n '1,80p' /proc/filesystems

Do not edit /proc/filesystems. It is a kernel-provided interface, not a configuration file. There is no text-file change to undo. Loading a filesystem module, changing boot parameters or rebuilding a kernel are separate administrative actions with their own compatibility and security consequences; this guide does not prescribe them.

Also avoid treating the list as a list of currently mounted filesystems. Use findmnt for that question:

$ findmnt --types ext4,tmpfs,proc

That command filters mounts, whereas /proc/filesystems reports registered filesystem types. Keeping those questions separate prevents a common debugging trap: a type may be supported but unused, or mounted but not obvious from the support list because the list contains many more possibilities.