df -h 卡住根本原因是硬挂载（hard）的 nfs/cifs 网络存储失联，导致 statfs() 调用陷入不可中断睡眠（d 状态）；需用 cat /proc/mounts | grep -e "nfs|cifs" 确认 hard 挂载，strace 追踪定位卡点，timeout 包裹网络命令验证服务端，并以 umount -l 临时恢复。

Linux 系统中，df -h 卡住、ls 进不去目录、umount 也挂起，十有八九是某个网络存储挂载点（NFS 或 CIFS）失联了，而且是以 hard 模式挂载的。它不会报错，也不会超时退出，而是让进程陷入不可中断睡眠（D 状态），连 Ctrl+C 都杀不掉。

确认是否存在可疑的网络挂载点

先快速扫一眼系统里有没有 NFS 或 CIFS 类型的挂载：

• 运行 cat /proc/mounts | grep -E "nfs|cifs"
• 重点看输出里是否含 hard 字样，比如 hard,proto=tcp,timeo=600 —— 这就是高风险配置
• 如果看到 soft，一般不会卡死，只是应用层报错快些

定位具体是哪个挂载点拖住了命令

如果 /proc/mounts 能出来但不确定哪一个是“罪魁祸首”，可以用系统调用追踪来抓现场：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• 执行 strace -e trace=statfs df -h 2>&1 | grep -v "ENOENT"
• 命令会逐个调用 statfs() 获取每个挂载点的空间信息
• 输出一旦停在某一行路径（如 /mnt/nfs-backup）不再滚动，那个路径就是问题挂载点

检查服务端连通性与基础服务状态

别直接硬 ping 或 telnet，所有走网络的排查命令都得加 timeout，否则自己也会卡住：

• 链路层：运行 timeout 3 ping -c 1 192.168.1.100，看是否通
• NFS 端口：运行 timeout 3 nc -zv 192.168.1.100 2049（CIFS 则试 445）
• RPC 服务：运行 timeout 3 rpcinfo -p 192.168.1.100，返回 124 就说明 RPC 不响应

临时恢复与后续加固

找到问题挂载点后，先解卡，再防复发：

• 尝试懒卸载：umount -l /mnt/nfs-broken（-l 表示 lazy，绕过内核等待）
• 检查 /etc/fstab 中对应行，补上 nofail 和 soft（或至少 timeo=10）
• 若必须 hard 挂载，至少加上 intr（允许中断）和合理 retrans 值
• 日常运维中，避免裸用 showmount -e 或 df -h，可封装成带 timeout 的脚本