lsof不识别“独占模式”，挂载点无法被open()；真正阻塞umount的是进程的cwd、root或打开的挂载点内文件，应使用sudo lsof -xN +D /mnt/data递归扫描全路径树并结合fuser -v验证。
lsof 查看挂载点被哪些进程以独占模式打开？根本查不到——因为 lsof 本身不识别“独占模式”
Linux 内核没有“独占打开挂载点”这个概念。挂载点（如 /mnt/data）本身不是文件，不能被 open()；真正被打开的是挂载点下的文件或目录，或是挂载点作为工作目录（cwd）、根目录（root）、chroot 环境等被进程持有。所谓“独占占用导致无法卸载”，本质是：有进程的 cwd、root、或打开了该文件系统里的任意打开文件（含目录），且该文件系统正处于 busy 状态。
所以你真正要查的，不是“谁以独占模式打开挂载点”，而是：哪些进程正在使用该挂载点所在的文件系统，从而阻塞 umount。
用 lsof -xN +D 精确扫描挂载点路径（推荐）
lsof -xN 是关键：它强制 lsof 使用“名称缓存绕过”模式，避免因内核 dentry 缓存失效导致漏报已删除但仍被打开的文件；+D 则递归扫描整个挂载点路径树（注意不是 -d 或 -D）。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
-
lsof -xN +D /mnt/data—— 扫描所有在/mnt/data下打开的文件/目录（含子目录），包括当前工作目录、内存映射、执行文件等 - 加
-F p可只输出 PID，方便脚本处理：lsof -xN +D /mnt/data -F p | grep '^p' | sort -u - 若提示
ERROR: cannot read mount table，说明 lsof 没权限读/proc/mounts，改用sudo lsof -xN +D /mnt/data
为什么不用 lsof /mnt/data 或 lsof -g /mnt/data？
这些写法看似直观，但实际效果差：
-
lsof /mnt/data只匹配“打开路径恰好等于/mnt/data”的条目（比如某个进程open("/mnt/data", O_RDONLY)），但绝大多数占用来自子路径（/mnt/data/db/lock）或cwd，会完全漏掉 -
lsof -g /mnt/data中的-g是按进程组 ID 过滤，和路径无关，纯属误用 -
lsof -d cwd -D /mnt/data错误：-D 不是合法选项；且仅查 cwd 会漏掉 mmap、root、打开的普通文件等
配合 fuser 和 findmnt 快速定位 busy 原因
lsof 结果多时，建议先用更轻量的工具交叉验证：
-
fuser -v /mnt/data—— 直接列出所有访问该挂载点的进程及其访问类型（cwd,root,mem,txt等），输出紧凑，适合快速判断 -
findmnt -D /mnt/data—— 确认该路径是否仍是活跃挂载点，并显示其 source 和 FSTYPE，排除路径已失效或重复挂载干扰 - 如果
fuser有输出但lsof -xN +D没有，大概率是进程已僵死但内核未清理引用，此时需检查/proc/PID/fd/是否存在残留 fd 指向该文件系统
真正难搞的 case 往往不是进程明面打开文件，而是容器 runtime（如 containerd）或 systemd 服务通过 bind mount、mount namespace 隐式持有路径——这种时候 lsof -xN +D 仍有效，但得注意是否在正确命名空间里运行（比如进了容器再查，或用 nsenter 进目标 pid namespace）。
