fuser 是处理目录占用的首选工具，因其能递归识别访问目录的所有进程并支持一键终止，而 ps 或 lsof 需手动过滤、拼接 pid 且易漏子进程或线程。
为什么 fuser 是处理目录占用的首选工具
当某个目录被进程占用（比如卸载 /mnt/data 报错 device is busy），ps 或 lsof 虽然也能查，但需要手动过滤路径、拼接 PID、再 kill -9，容易漏掉子进程或线程。fuser 专为这类场景设计：它能直接扫描文件系统层级，递归识别所有访问该目录（含子目录、打开的文件、挂载点）的进程，并支持一键终止。
fuser -v /path 查看谁在用这个目录
加 -v（verbose）是安全前提，必须先执行，否则可能误杀：
-
fuser -v /mnt/backup会列出所有访问该路径的 PID、用户、命令、访问类型（cwd表示当前工作目录，fd表示打开的文件描述符，root表示 chroot 目录） - 注意输出中带
*的行——那是内核线程或无法获取命令名的进程，通常可忽略；重点看普通用户进程 - 如果看到
bash进程的cwd是该目录，说明有人正 cd 在里面；python3的fd指向某日志文件，则说明程序正在写入
fuser -k -i /path 安全强制终止
确认无误后才执行终止。推荐始终加 -i（interactive）参数，避免批量误杀：
-
fuser -k -i /mnt/backup会逐个提示 “Kill process1234(user)? (y/N)”，按y确认，Enter跳过 - 不加
-i会直接发SIGKILL（等效kill -9），对正在写磁盘的进程可能导致数据损坏 - 若需静默强杀（如脚本中），改用
fuser -k -f /mnt/backup——-f强制以文件方式匹配，避免因挂载点重叠导致误判 -
fuser默认只杀直接访问者，不会自动处理子进程；若父进程被杀后子进程残留，需额外用pgrep -P $PID配合kill -9
常见陷阱和绕过方法
fuser 在某些场景下会“看不见”进程，不是 bug，而是机制限制：
- 容器内进程（如 Docker）默认隔离了命名空间，宿主机
fuser查不到；需进容器用nsenter或在容器内执行 - NFS 挂载点被远端服务器占用时，
fuser只显示本地客户端进程（如rpc.statd），实际需联系 NFS 服务端排查 - 如果
fuser -v输出为空但umount仍报 busy，大概率是内核级引用（如 bind mount、overlayfs 下层目录），此时fuser无效，得用findmnt -D /path或检查/proc/mounts - 某些守护进程（如
systemd-journald）会缓存日志路径，重启服务比杀进程更稳妥
真正麻烦的从来不是“怎么杀”，而是“杀完谁来收尾”——比如杀掉一个正在 rsync 的进程，临时文件没清理干净；杀掉数据库进程前没 flush log，下次启动可能 recovery 失败。所以 fuser -k 只是最后手段，优先考虑 systemctl stop、docker stop 或应用自身 graceful shutdown 流程。
