Linux findmnt --verify 怎么检查挂载配置：fstab 语法、设备存在性与启动前验收

改完 /etc/fstab 后直接重启，是排查服务器起不来的高风险动作。更稳妥的做法是先用 findmnt --verify 让系统检查配置能否解析，再确认设备、挂载点和最终挂载状态；这三个结果不能混成一句“配置没问题”。

先分清 fstab 验收的三个层次

/etc/fstab 一行里同时包含设备、挂载点、文件系统类型、选项和转储顺序。排障时至少要分三步看：文件格式能否解析，来源设备是否可见，挂载动作是否真的成功。只看第一步，最容易把“写得像配置”误判成“重启后可用”。

用 findmnt --verify 检查 fstab 语法

操作时先不要触碰正在承载业务的挂载点，直接读取 fstab 文件做静态检查：

sudo findmnt --verify --verbose
echo $?

排查时重点看输出里的文件名、行号和错误对应对象。命令返回退出码为零，只能说明当前工具认可这些条目格式；如果碰到无法解析的字段、缺少挂载点路径或者不认识的挂载选项，先修正对应行内容，再继续做后面的设备合法性检查。

为什么要保留 --verbose

不带详细输出时，多个条目同时出错会让定位变得含糊。--verbose 能把检查对象和判断过程显示出来，适合把结果保存进变更记录。不要把终端里“没有报错”当作设备检查已经完成。

把设备路径和挂载点单独核对

语法校验通过后，再逐一核对 fstab 里填写的挂载来源是不是真的存在于当前机器上。传统设备名可能因为磁盘开机顺序变动发生偏移，填的UUID也需要确认仍然匹配对应的目标文件系统：

lsblk -f
findmnt --source /dev/disk/by-uuid/你的UUID
findmnt --target /srv/archive

这里的查询不会替你改配置。若 findmnt --source 没有返回目标，先查看 UUID、分区和文件系统类型；若目标目录不存在，则先确认目录创建策略，不要随手改成根目录。

在重启前做一次可回退的挂载测试

先把原有配置文件备份留存，再做不需要重启的挂载加载测试：

sudo cp -a /etc/fstab /etc/fstab.bak.$(date +%Y%m%d-%H%M%S)
sudo mount -a
findmnt --target /srv/archive
mountpoint /srv/archive

mount -a 会尝试挂载尚未挂载的条目。它返回成功后，还要用 findmnt --target 看实际来源和文件系统类型，避免挂载点虽然存在，却挂上了错误设备。

测试失败时怎么回退

测试过程中先记下报错的行和完整错误提示，再恢复之前的备份文件，或者只撤回刚改动的那一行内容。如果已经挂载了错误的来源路径，不要直接删除对应的文件夹，先卸载目标挂载点，再核对数据存储路径和业务进程是否还在占用这个路径。

nofail、网络盘与启动时机的边界

nofail 适合允许设备暂时缺席、但不希望它阻塞启动的场景。它不是路径纠错开关，也不代表应用可以在挂载完成前读取目录。网络文件系统还要考虑网络就绪、凭据来源和服务依赖，不能只靠一行 fstab 选项兜底。

常见问题：findmnt 验收时容易混淆什么

findmnt --verify 通过后可以直接重启吗？

不建议只凭这一项重启。还应确认来源设备可见，并用 mount -a 与 findmnt --target 做一次实际挂载测试。

为什么 fstab 有 UUID 但 findmnt 找不到？

可能是磁盘未连接、UUID 写错、分区尚未识别，或文件系统类型与实际不符。先用 lsblk -f 查看当前主机的真实值。

挂载点目录不存在会怎样？

这种情况下挂载动作通常会直接报错。你可以先确认对应文件夹是由系统镜像、部署脚本还是服务单元自动创建的，再在后续的变更记录里把文件夹的创建权限做固定。

结尾：把重启前检查变成固定清单

一条可用的 fstab 配置至少要经过“语法能解析、设备真实存在、挂载可成功”三道检查。把原文件备份、静态校验、来源核对、实际挂载和结果读取几个步骤都写进变更单，重启操作就从碰运气的猜测变成了可回滚的标准化验收动作。