该错误是系统资源冲突所致，需用lsof查占用进程并kill，nfs相关问题应改用本地tmpdir，docker场景需检查挂载与容器残留。
![如何修复python中由于文件占用导致的oserror: [errno 16] device or resource busy？](https://img.php.cn/upload/article/000/969/633/178545624927219.png?x-oss-process=image/resize,p_40)
这个错误不是代码写错了，而是系统层面的资源冲突——目标设备或文件正被别的进程锁着，Python 拿不到控制权。直接杀进程或换路径通常比修代码更有效。
查哪个进程占着 /dev/ttyUSB0 或其他设备文件
串口、USB 设备、NFS 挂载点出错时，lsof 是第一反应工具：
- 运行
lsof /dev/ttyUSB0（替换成你实际报错的设备路径），看输出里有没有python、minicom、screen、cutecom这类进程 - 如果没权限，加
sudo：sudo lsof /dev/ttyUSB0 - 找不到具体路径？用
lsof | grep -i "tty\|usb\|nfs"全局筛一遍 - 看到 PID 后，用
kill -9 PID强制结束；若担心误杀，先试kill PID
PyTorch DataLoader 在 NFS 上报 .nfs* 错误
这不是 Python 代码问题，是 Linux + NFS 的经典配合 bug：当多进程尝试删除临时文件时，NFS 服务端会把“正在被读的文件”悄悄重命名为 .nfsxxxx 并拒绝 unlink —— 于是 shutil.rmtree 就卡在 OSError: [Errno 16]。
- 根本解法是避开 NFS 的
/tmp：创建本地临时目录，比如mkdir -m 1777 /var/tmp/myproj - 运行前设置环境变量：
TMPDIR=/var/tmp/myproj python train.py - 或者在代码开头加：
import os; os.environ["TMPDIR"] = "/var/tmp/myproj"（必须在torch.multiprocessing初始化前） - 别用
os.tmpfile()或默认tempfile.mkdtemp()，它们都依赖系统TMPDIR
检查是否因 Docker 挂载导致设备忙
如果你在容器里操作宿主机设备（如 /dev/video0、/dev/ttyACM0），或挂载了 NFS 卷，Device or resource busy 很可能来自挂载残留：
- 查挂载点：
mount | grep -E "(nfs|/dev)" - 确认是否重复挂载同一路径，或挂载后未正常
umount - Docker 场景下，运行
docker ps看是否有旧容器还在用该设备，docker stop && docker rm清掉 - 极端情况：
sudo umount -l /path/to/nfs/mount（-l表示 lazy unmount，强制断开）
真正麻烦的从来不是报错本身，而是那个没显式退出、却一直 hold 着文件句柄的后台进程——它可能藏在 tmux 会话里，可能由 systemd 用户服务启动，也可能只是某个忘记关的 Jupyter kernel。查 lsof 前，先 ps aux | grep -i "python\|serial\|nfs" 快扫一眼，往往比等 lsof 跑完更快。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
