systemd mount 超时但手动成功解决方法

\_netdev 不足以防止挂载超时，因其仅延迟挂载至网络设备就绪，不检测远端存储服务可达性；需通过自定义健康检查 service 显式依赖远端可用性。

服务启动时 systemd 报 mount timeout，但手动执行 mount -a 立即成功，问题大概率出在依赖顺序和网络就绪判定上——_netdev 只影响挂载时机（延迟到网络设备存在），并不保证远端服务（如 NFS、CIFS）已可连通；而 Requires=network-online.target 在多数发行版中默认由 systemd-networkd-wait-online.service 或 NetworkManager-wait-online.service 实现，但它们只确认“网络配置完成”，不探测远端存储是否响应。

为什么 _netdev 不足以防止 timeout

_netdev 是 fstab 标志，被 systemd-fstab-generator 转为 Wants=network.target 和 After=network.target，仅确保网卡已注册、IP 已配好，不等待 NFS 服务器可达或 SMB 共享可枚举。若远端服务启动慢、防火墙未开、DNS 解析卡顿，mount.nfs 就会在默认 60 秒内超时。

• _netdev 不触发任何网络连通性检测，它只是个“延迟挂载”的开关
• 实际挂载命令仍由 systemd-mount 或 mount 执行，超时由底层工具（如 nfs-utils 的 timeo= 参数）控制
• 即使加了 Requires=network-online.target，若 network-online.target 过早进入 active 状态（例如 NetworkManager 认为 DHCP 完成就算 online），远端依然不可达

如何让 mount 真正等远端就绪

必须把“远端存储可用”显式建模为一个 systemd 依赖单元，不能只靠网络层信号。常见做法是加一层轻量健康检查。

• 写一个 ExecStart=/usr/bin/sh -c 'until ping -c1 -w3 server.example.com &>/dev/null || nc -z server.example.com 2049 &>/dev/null; do sleep 2; done' 的 oneshot service，设 WantedBy=multi-user.target，再让 mount unit Requires=storage-online.service 且 After=storage-online.service
• 对 NFS，直接在 fstab 中加 soft,timeo=600,retrans=3（避免单次请求卡死）；对 CIFS，用 sec=ntlmssp,iocharset=utf8,vers=3.0 并配 credentials=/etc/samba/creds 避免交互式认证阻塞
• 禁用 systemd-networkd-wait-online.service（若不用 systemd-networkd），改用更可靠的等待逻辑，否则它可能 5 秒就返回 success，完全没意义

fstab 条目与对应 .mount 单元的常见错配

systemd 会为每行 fstab 自动生成 xxx.mount 单元，但自动生成的依赖可能覆盖手动设置。比如你写了 Requires=network-online.target，但生成器又加了 Conflicts=umount.target 或错误的 Before=，导致实际启动顺序混乱。

• 运行 systemctl cat mnt-data.mount 查看真实 unit 内容，确认 Requires= 和 After= 是否符合预期
• 若需精确控制，建议禁用自动生成：systemctl mask proc-sys-fs-binfmt_misc.automount（非必需），改用手工写的 /etc/systemd/system/mnt-data.mount
• 手工 unit 中必须包含 [Mount] 段的 What=、Where=、Type=，且 Where= 必须与挂载点路径完全一致（含尾部斜杠与否），否则 unit 不生效

真正卡住的往往不是“有没有网”，而是“远端服务是不是已经监听并接受连接”。别迷信 network-online.target，它连本机防火墙放行都没管。加一层简单探测，比调 timeout 参数更治本。