cat /proc/filesystems 是最权威来源，显示内核编译支持或可动态加载的所有文件系统类型，含伪文件系统（带 nodev 前缀）和真实块设备型（如 ext4、xfs），后者可用 awk '$1 != "nodev" {print $2}' /proc/filesystems 过滤。
cat /proc/filesystems 显示内核编译支持的所有类型
这是最权威的来源，反映内核原生支持或可动态加载的全部文件系统，不管模块是否已加载、设备是否存在。
直接运行 cat /proc/filesystems，输出每行第二列就是文件系统名，比如 ext4、xfs、vfat。带 nodev 前缀的是伪文件系统（如 proc、sysfs），不依赖块设备；没这个前缀的才是你插硬盘能用的真实类型。
想只看真实块设备型文件系统，用这句过滤：
awk '$1 != "nodev" {print $2}' /proc/filesystems
注意：某些发行版（如 Alpine）会把部分文件系统编译为模块而非内置，它仍会出现在这里，但需 modprobe 才能挂载。
ls /lib/modules/$(uname -r)/kernel/fs/ 查模块实际存在性
这个目录列出当前内核版本下所有可加载的文件系统模块文件，比 /proc/filesystems 更贴近“物理存在”——如果某类型没对应 .ko 文件，说明内核根本没提供该驱动。
执行：ls /lib/modules/$(uname -r)/kernel/fs/
常见陷阱：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 路径拼错：必须是
$(uname -r)，不是硬写版本号； - 权限不足：普通用户可能看不到部分子目录，加
sudo不解决——这不是权限问题，而是模块目录本身对非 root 可读； - 输出为空或极简：说明内核配置极度精简（如某些容器镜像或嵌入式系统），
ext4都可能被编译进内核而非模块，此时它不会出现在该目录，但仍在/proc/filesystems里。
lsmod | grep xxx 判断当前是否已启用
内核支持 ≠ 当前可用。模块没加载，mount -t ntfs 就会报 unknown filesystem type 'ntfs'。
查已加载的文件系统模块：
lsmod | grep -E '^(ext|ntfs|xfs|btrfs|f2fs|vfat)'
重点看 Used by 列：
- 值为
0：模块已加载但没被使用； - 非
0：正被某个挂载点占用； - 完全没出现：模块未加载，可尝试
sudo modprobe ntfs3（注意不是ntfs，新版推荐用ntfs3）； - 若
modprobe失败，先用modinfo ntfs3确认模块是否存在、内核是否支持该参数。
file -s /dev/sdX1 不能查“支持”，但能验证识别能力
这个命令不回答“系统支持什么”，只告诉你：对这个具体设备，内核能不能解析出它的格式。但它是最接地气的反向验证——如果连 file -s 都输出 data 或报错，大概率是驱动缺失或格式太新（比如旧内核无法识别带 casefold 特性的 ext4）。
操作前确认：
- 设备未被挂载或占用（否则可能报
cannot open）； - 有 root 权限（
sudo file -s /dev/sdb1）； - 别信
fdisk -l的 type 字段——它只读分区表 ID（如0x83），不校验实际格式，误报率高。
输出含 ext4 filesystem data 或 ISO 9660 才算识别成功。
真正麻烦的地方不在命令本身，而在判断层级：/proc/filesystems 告诉你“理论上能”，/lib/modules/ 告诉你“物理上有”，lsmod 告诉你“此刻开着没”，file -s 告诉你“这个盘它认得”。四个结果不一致是常态，得按需交叉验证。
