挂载为什么会有单元
systemd 把挂载也单元化：每个挂载点在 systemd 里对应一个 .mount 单元，通常由 fstab 通过 systemd-fstab-generator 自动生成，也可以手写。好处是挂载被纳入依赖编排：哪个服务必须在挂载完成后启动、网络盘在什么条件下挂载，都能用依赖关系和 .automount 单元控制。代价是 fstab 与 systemd 是两个视角，改动后需要重载让生成器重算。
基本信息
| 适用平台 | Linux（systemd 系统） |
|---|---|
| 单元名规则 | /data 对应 data.mount，/mnt/nfs 对应 mnt-nfs.mount（斜杠换成连字符） |
| 查看方式 | systemctl list-units --type=mount、systemctl status data.mount |
| 生成器 | systemd-fstab-generator（读 /etc/fstab 生成单元） |
| 按需挂载 | .automount 单元，访问时才触发挂载 |
| 改动流程 | 改 fstab 后 daemon-reload 或 mount -a |
典型使用场景
- 确认某个挂载点是否由 systemd 管理、当前是不是 failed
- 排查开机顺序问题：服务比挂载先启动，启动即报文件不存在
- 用 .automount 实现按需挂载，减少长期占用
- 网络盘挂载失败导致开机变慢，定位具体是哪个挂载点卡住
- 确认 fstab 改动是否真正生效并核对最终状态
查看与生效
查看与生效
systemctl list-units --type=mount --all # 全部挂载单元与状态
systemctl status data.mount --no-pager # 单个单元的详细状态与依赖
systemctl list-units --type=mount --state=failed # 只看失败的挂载单元
mount -a && systemctl daemon-reload # fstab 改动后的标准动作
findmnt /data # 用实际挂载情况与单元输出对照
systemctl show data.mount -p Where -p What # 看单元对应的挂载点与设备
journalctl -u data.mount --no-pager | tail # 挂载失败的原因通常在这里常用操作对照
| 操作 | 命令 | 说明 |
|---|---|---|
| 查看全部挂载单元 | list-units --type=mount --all | 包含当前未激活的单元 |
| 查看单个单元 | systemctl status 单元名 | 失败原因通常在状态输出里 |
| 只看失败项 | --state=failed | 排查开机慢或挂载异常的第一站 |
| 让 fstab 改动生效 | daemon-reload 或重启 | 生成器据此重算单元定义 |
| 核对实际挂载 | findmnt | 与单元状态交叉验证 |
| 查失败细节 | journalctl -u 单元名 | 网络未就绪、路径不存在等都会体现 |
单元名按挂载点转换：/data 是 data.mount，/mnt/nfs 是 mnt-nfs.mount，斜杠变成连字符。动手前先按这个规则换算名字，能省下不少试错。
手写 .mount 单元与 fstab 同时定义同一个挂载点会冲突：选一种维护方式。另外 fstab 改动后运行态旧单元不会自动消失，必要时 daemon-reload 后重启相关单元。