systemd mount unit 失败显示 dependency failed 但手动 mount 成功的分析

根本原因是systemd启动时依赖关系、时机或路径状态判断与手动执行不同：父目录未就绪、挂载点目录缺失/权限不足/SElinux限制、设备路径不稳定、fstab冲突均会导致Dependency failed。

这种情况很常见：systemd mount unit 启动失败，日志显示 Dependency failed（比如 Dependency failed for /mnt/data），但执行 sudo mount /mnt/data 却能立刻成功。根本原因通常不是挂载本身出错，而是 systemd 在启动时对依赖关系、时机或路径状态的判断与手动执行时不同。

依赖目标未就绪（最常见）

systemd mount unit 默认隐式依赖 local-fs.target 和对应挂载点所在的父目录（如 /mnt）。如果父目录（如 /mnt）本身由另一个 mount unit 管理，而该 unit 尚未启动或失败，当前 unit 就会报 Dependency failed，哪怕设备可访问、fstab 配置正确。

• 检查挂载点父目录是否为独立 mount：运行 findmnt /mnt，看 /mnt 是否已挂载（尤其在使用 LVM、btrfs subvolume 或网络存储时）
• 确认依赖链完整：用 systemctl list-dependencies --reverse mnt-data.mount 查看谁依赖它，再用 systemctl list-dependencies mnt-data.mount 查看它依赖谁
• 若依赖的父目录 mount unit 名为 mnt.mount，需确保其 WantedBy=local-fs.target 且状态为 active (mounted)

挂载点目录不存在或权限/SELinux 限制

systemd 在启动 mount unit 前会检查挂载点目录是否存在且可访问。若目录不存在、属主错误、或 SELinux 上下文不匹配（尤其在 enforcing 模式下），unit 会因前置检查失败而报依赖错误（实际是 PathExists= 或 DirectoryMode= 验证失败）。

• 运行 ls -ld /mnt/data，确认目录存在、权限合理（至少 drwxr-xr-x）、属主为 root
• 若启用 SELinux，检查上下文：ls -Z /mnt；应为 system_u:object_r:mnt_t:s0 类似；否则用 sudo restorecon -Rv /mnt 修复
• 可在 unit 文件中显式要求创建目录：X-Systemd-Mount-TimeoutSec=30 + DirectoryMode=0755 + RuntimeDirectory=/mnt/data（慎用，仅限临时目录）

设备路径不稳定或未被 udev 完全识别

mount unit 中若使用 What=/dev/sdb1 这类传统设备名，在内核设备探测顺序变化或 udev 规则延迟时，unit 启动时该路径可能尚未出现在 /dev/ 下，导致 device not found → 被解释为依赖失败。

• 改用稳定的设备标识：优先使用 What=/dev/disk/by-uuid/xxxx 或 What=/dev/disk/by-label/DATA
• 添加设备等待机制：在 unit 文件中加入 BindsTo=dev-disk-byx2duuid-xxxx.device 和 After=dev-disk-byx2duuid-xxxx.device
• 验证设备是否就绪：systemctl list-units --type=device | grep sdb1，观察对应 .device unit 状态是否为 active

fstab 冲突或自动挂载干扰

如果同一挂载点同时存在于 /etc/fstab 和 systemd mount unit 中，systemd 可能因重复定义或解析顺序问题跳过 unit，或 fstab 条目触发了更早的挂载尝试并失败，间接影响后续 unit 的依赖状态。

• 运行 systemctl cat mnt-data.mount，确认没有 NoAuto 或 noauto 以外的冲突配置
• 检查 /etc/fstab 是否含相同挂载点条目；如有，注释掉 fstab 行，完全交由 systemd 管理
• 禁用 fstab 自动挂载：执行 sudo systemctl disable proc-sys-fs-binfmt_misc.automount（仅示例），或统一用 systemd-fstab-generator 管理逻辑

排查时先看完整日志：journalctl -u mnt-data.mount -n 50 -b，重点关注 “Failed to mount” 前一行的提示（如 “Dependency failed on…”、“Unit … not found”、“Path /mnt/data does not exist”）。手动 mount 成功说明后端存储和权限没问题，问题一定出在 systemd 的启动时序、依赖声明或路径预检环节。