\_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'的oneshotservice，设WantedBy=multi-user.target，再让 mount unitRequires=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 参数更治本。
