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 的脚本
