30

I'm trying to detect what filesystems a kernel can support. Ideally in a little list of their names but I'll take anything you've got.

Note that I don't mean the current filesystems in use, just ones that the current kernel could, theoretically support directly (obviously, fuse could support infinite numbers more).

1
  • The list of supported filesystems for a given running kernel can be seen with cat /proc/filesystems as pointed out in the kernel documentation. There may be modules, available on your hard drive, which support other additional filesystems, but that are not loaded into your running kernel. Those can be found in /lib/modules/$(uname -r)/kernel/fs.
    – Totor
    Nov 13, 2021 at 23:25

4 Answers 4

16

Can I list the filesystems a running kernel can support?

Well, answer /proc/filesystems is bluntly wrong — it reflects only those FSes that already were brought in use, but there are way more of them usually that kernel can support:

ls /lib/modules/$(uname -r)/kernel/fs

Another source is /proc/config.gz which might be absent in your distro (and I always wonder «why?!» in case), but a snapshot of config used to build the kernel typically can be found in the boot directory along with kernel and initrd images.

11
  • 2
    Ubuntu's kernel config is included, just in a different place: /boot/config-$(uname -r)
    – Oli
    Nov 3, 2013 at 16:21
  • 3
    /proc/filesystems is not wrong, it is just incomplete.
    – scai
    Nov 3, 2013 at 21:15
  • 6
    @poige By that logic your answer is terribly incomplete and wrong as well. /lib/modules/$(uname -r)/kernel/fs will only help with filesystems that have been enabled as modules, not ones that are built into the kernel. Additionally a module name might not match the filesystem name it provides, and a single module can provide multiple filesystems.
    – phemmer
    Nov 4, 2013 at 1:42
  • 4
    This answer is misleading, if a module isn't loaded, the kernel simply cannot load that filesystem type until it is. To state that the kernel can load it is not correct -- you don't know if it can until you successfully load the module. There's not even a guarantee that you can load that module.
    – Chris Down
    Nov 4, 2013 at 7:35
  • 3
    @poige actually I'm not overlooking /proc/config.gz at all. 1) it's not guaranteed to exist, 2) A module name might not match the filesystem name it provides, and a single module can provide multiple filesystems.
    – phemmer
    Nov 4, 2013 at 12:00
11

/proc/filesystems lists all of the filesystem types supported by the running kernel, along with filesystem attributes, nodev to indicate that this filesystem is not backed by a block device, for example.

man 5 filesystems gives some more in-depth information.

4
  • 1
    What does the nodev mean in the output when you cat /proc/filesystems?
    – slm
    Nov 3, 2013 at 14:22
  • 1
    On my Arch linux laptop, cat /proc/filesystems lists a bunch of "nodev", obviously special-purpose filesystems, plus ext2, ext3, ext4. When I look in /lib/modules/3.11.6-1-ARCH/kernel/fs, I see a number of others, like "fats", "btrfs", "reiserfs" which are also regular on-disk filesystems, but don't appear in the /proc/filesystem list. What's up with that?
    – user732
    Nov 3, 2013 at 14:49
  • 1
    nodev indicates that the filesystem in question is not a physical filesystem that needs a block device to live on, but rather a virtual filesystem that is backed by something other than a block device. Nov 3, 2013 at 14:49
  • 7
    @BruceEdiger: /proc/filesystems only shows the filesystems that the kernel has loaded -- until you insert those modules into the kernel (which usually happens automatically when you need them), the kernel cannot support those filesystems. Nov 3, 2013 at 14:51
2

I believe this will give you what you want:

(cat /proc/filesystems | awk '{print $NF}' | sed '/^$/d'; ls -1 /lib/modules/$(uname -r)/kernel/fs) | sort -u

Explanation

Based on my best understanding:

  • cat /proc/filesystems | awk '{print $NF}' | sed '/^$/d' gives you all the filesystems that are natively supported by the kernel (like sysfs) along with those that have their kernel modules currently loaded
  • ls -1 /lib/modules/$(uname -r)/kernel/fs gives you the list of available filesystem modules available for your kernel
  • sort -u sorts the combined results of the first two commands with duplicates removed (only show unique results -u)

I am still learning linux, this works on Arch linux but I believe for at least ubuntu you may need to change the path /lib/modules/$(uname -r)/kernel/fs to a different directory appropriate for your distribution.

1

tl;dr

cat /proc/filesystems will show you which filesystems your running kernel can support right now.

ls /lib/modules/$(uname -r)/kernel/fs will provide clues as to which additional filesystems it could support, if you loaded the appropriate module.

Explanation

The question has already been answered, but all of the other answers are in some way incomplete, misleading, untrue, or at least not true any more.

From man 8 mount (emphasis mine):

-t, --types fstype

The argument following the -t is used to indicate the filesystem type. The filesystem types which are currently supported depend on the running kernel. See /proc/filesystems and /lib/modules/$(uname -r)/kernel/fs for a complete list of the filesystems. The most common are ext2, ext3, ext4, xfs, btrfs, vfat, sysfs, proc, nfs and cifs.

I therefore can't fault anyone suggesting these approaches. However, as others have pointed out, the /lib/modules/$(uname -r)/kernel/fs directory contains filesystem-related kernel modules, which is not the same thing as currently supported filesystems:

  • If the module is not loaded, the filesystem will not be supported currently.
  • If support is built-in to the kernel, the filesystem will be supported but won't show up in the list of modules.
  • Module names are not guaranteed to map 1:1 to the filesystems they support.

The list can therefore contain additions, deletions and/or substitutions. It's not very reliable. It's possible to have a so-called "monolithic kernel" which has everything built-in already - in that (admittedly unusual) case the module list will be completely empty but the kernel will still support an arbitrary number of things - including, of course, various filesystems.

On the other hand, this is the contents of my /proc/filesystems file:

nodev   sysfs
nodev   tmpfs
nodev   bdev
nodev   proc
nodev   cgroup
nodev   cgroup2
nodev   cpuset
nodev   devtmpfs
nodev   binfmt_misc
nodev   configfs
nodev   debugfs
nodev   tracefs
nodev   securityfs
nodev   sockfs
nodev   bpf
nodev   pipefs
nodev   ramfs
nodev   hugetlbfs
nodev   rpc_pipefs
nodev   devpts
        ext3
        ext4
        ext2
        cramfs
        squashfs
        vfat
        msdos
        exfat
        iso9660
nodev   nfs
nodev   nfs4
nodev   nfsd
nodev   cifs
nodev   smb3
        ntfs3
nodev   autofs
        fuseblk
nodev   fuse
nodev   fusectl
        udf
        f2fs
nodev   efivarfs
nodev   mqueue
nodev   resctrl
        btrfs
nodev   pstore

There are filesystems in that list that my system has never even seen, let alone has currently mounted.

So on my system at least, that's the answer. I can't speak to why the currently accepted answer leads with the opposite conclusion; perhaps this is a new development...

3
  • I don't know why your system shows filesystems in /proc/filesystem that the system has never seen, but… I just tried it, not "btrfs" in /proc/filesystems, after "modprobe btrfs" it's in there. I suspect that, for some reason, your kernel has all those filesystems built in and not as loadable modules. Dec 7, 2021 at 14:43
  • 1
    My kernel probably does have all those filesystems builtin, as I configure it myself (due to being a masochist) and it's mostly monolithic. I've amended my tl;dr to clarify the role of loadable modules. Other than cluttering up my nice short lsmod output, that is ;)
    – tlloyd87
    Dec 8, 2021 at 20:28
  • Hehe… I very recently built my own kernel (package, for Devuan). First time in years… all due to the new NTFS3 fs driver, which isn't (or at least wasn't at the time) activated in the Debian/Devuan kernel package. Dec 26, 2021 at 18:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .