Read /proc/filesystems and Check Mount Support Safely

A mount that fails with an unhelpful error is the usual reason someone opens /proc/filesystems for the first time. It lists every filesystem type the running kernel currently supports, splits virtual filesystems from block-backed ones, and gives you a fast way to check support before you blame the mount command itself. Nothing here touches 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 live by the kernel, so your output depends on the kernel configuration and whatever modules happen to be loaded when you read it.

1. Read the kernel's list

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

$ cat /proc/filesystems

Each line holds one filesystem type. Some lines start with nodev, followed by the type name. On this host the start of the list looks like this:

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

The spacing matters enough to keep the two fields apart, but do not treat the exact order or membership as portable between machines. It is a snapshot of what this kernel currently supports: types compiled in, plus types supplied by whatever modules are loaded right now.

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

2. Interpret the nodev marker correctly

nodev does not mean a filesystem cannot be mounted. It means the filesystem does not need a block device as its backing source, which is normal for virtual filesystems such as proc, sysfs and tmpfs, and for some network or userspace filesystem setups.

A line without nodev identifies a type that can use a block device: ext4, xfs or btrfs normally treat a device or image as their source. This marker only describes the mount model. It says nothing about whether the type is mounted right now, whether a particular device holds a valid filesystem, or whether your account is even allowed to mount it.

To split the two groups without relying on lining columns up by eye, reach for awk:

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

Expect output shaped like this, though the full list is host-specific:

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

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

3. Check one type precisely

When you are diagnosing a script or a config file, match an exact field rather than grepping for an unanchored substring. That avoids treating something like fuseblk as a match for a different value entirely:

$ 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 that type registered right now. A non-zero exit status means it is not in the list, but that does not prove a module package is absent: a filesystem module can sit on disk without being loaded yet. It also does not prove a mount will succeed, since 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 can consult /proc/filesystems when no type was supplied and it could not work one out another way. It tries the listed types except those marked nodev, but that is a fallback, not a guarantee that guessing is safe or even 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. Both commands only inspect metadata. Once one reports a type, prefer an explicit mount operation such as:

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

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

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

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 the target as busy, look at who is using it with fuser -vm /mnt/TARGET or lsof +D /mnt/TARGET, stop only the processes you understand, and retry. Do not reach for a forced unmount as a first response.

5. Handle missing or surprising entries

An absent entry has a few possible explanations: the running kernel may not include support, the relevant module may not be loaded, or /proc may be unavailable or mounted inside 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, so 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, and this guide does not walk through any of them.

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

$ findmnt --types ext4,tmpfs,proc

That command filters mounts, whereas /proc/filesystems reports registered filesystem types. Keeping the two questions separate avoids a common debugging trap, where a type is supported but unused, or mounted without being obvious from the support list simply because that list contains far more possibilities than are in use.