umount /path时，我得到：umount: /path: device is busy.
文件系统很大，因此
lsof +D /path不是一个现实的选择。lsof /path，lsof +f -- /path和fuser /path都一无所获。 fuser -v /path给出： USER PID ACCESS COMMAND
/path: root kernel mount /path
，这对于所有未使用的已挂载文件系统都是正常的。 br />
我如何找出内核为何认为此文件系统很忙？
#1 楼
看来造成我问题的原因是nfs-kernel-server正在导出目录。 nfs-kernel-server可能落后于正常打开的文件，因此在lsof和fuser中未列出。页面，其中包含到目前为止的所有解决方案示例：http：//oletange.blogspot.com/2012/04/umount-device-is-busy-why.html 评论
感谢您回答您自己的问题，而不是在实施解决方案时放弃它。您的回答帮助我整理了类似导出的NFS共享。
–杰夫·韦林（Jeff Welling）
2011-12-15 5:44
如果在文件系统上设置了回送设备，也会发生同样的问题-例如，如果/ dev / loop0由/ path中的文件支持。
–BCran
2012年2月22日13:25
我不得不先让sudo服务samba停止，您的回答真的帮了忙！
– Malat
2014年6月10日7:38
这篇文章提醒我，经过数小时的尝试后，我才开始运行nfs服务。在RHEL6 / CentOS6中，使用sudo服务nfs stop，您可能（也不需要）也执行sudo exportfs -u来取消导出。请记住，然后sudo exportfs -r和sudo service nfs开始重新导出并重新启动服务。
– code_dredd
16年3月3日，0：45
在我的情况下，没有必要停止nfs服务器，只需导出有问题的目录。
–法律29
16-11-27在13:34
#2 楼
在上面BruceCran的评论中，我刚才表现出这个问题的原因是过时的环回安装。我已经检查过fuser -vm <mountpoint> / lsof +D <mountpoint>，mount和cat /proc/mounts的输出，检查某些旧的nfs-kernel-server是否正在运行，关闭配额，尝试（但失败）了umount -f <mountpoint>，并且所有人都辞职了以放弃924天的正常运行时间在最终检查losetup的输出并找到两个陈旧的已配置但未安装的环回之前：parsley:/mnt# cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0
然后
parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy
parsley:/mnt# losetup -a
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#
Gentoo论坛上的帖子还列出了交换文件是潜在的罪魁祸首；尽管现在交换到文件可能很少见，但检查
cat /proc/swaps的输出也不会有什么坏处。我不确定配额是否可以防止出现不合时宜的情况-我当时正抓着稻草。评论
所有924天的正常运行时间意味着您需要更新内核补丁：-)
– w00t
2012年6月25日下午13:39
+1代表交换文件，它们确实阻止了卸载，并且如果您不直接检查它们，则几乎无法检测到它们。
–P.Péter
19-09-13在11:53
#3 楼
不必使用lsof来爬网文件系统，而只需使用打开文件的总列表并将其grep即可。我发现此回报必须更快，尽管准确性较差。它应该完成任务。lsof | grep '/path'
评论
lsof / path仅查看路径。
–奥雷·丹吉（Ole Tange）
2011年6月15日在11:58
我没有说lsof / path，我说了lsof | grep'/路径'。不同之处在于，不带参数的lsof使用某种缓存表显示所有打开的文件，而grep可以非常快速地搜索它。您使用lsof尝试的操作使它扫描了很长时间的文件系统。
–卡莱布
2011年6月15日在12:02
就像我说的那样：lsof / path仅查看路径。它不会查看每个文件。它通常比lsof快得多。 grep / path（在我不科学的测试中，它比YMMV快20倍），因为它不会查看所有打开的文件，而只会查看该路径的文件。
–奥雷·丹吉（Ole Tange）
2011年6月16日10:10
我不确定技术上的区别是什么，但是在调查过时的NFS挂载时，lsof / path没有产生任何结果，而lsof | grep / path向我展示了保存打开文件并阻止我卸载卷的过程。
– dpw
17年9月27日在16:34
#4 楼
对我而言，令人讨厌的进程是在chroot中运行的守护程序。因为它在chroot中，所以找不到lsof和fuser。 chroot）。评论
很好，在FreeBSD中，我做到了：sudo ls -l / proc / * / status | grep HOST，其中HOST是监狱的主机名
– JGurtz
13年7月24日在22:31
在我的系统（Mint Qiana）上，即使是chroot，lsof / mountpoint和fuser / mountpoint都可以找到一个进程。
–奥雷·丹吉（Ole Tange）
2014年12月21日在17:20
#5 楼
打开文件打开文件的过程是常见的罪魁祸首。显示它们：
lsof +f -- <mountpoint or device>
使用
/dev/<device>而不是/mountpoint有一个优点：安装点在umount -l之后会消失，或者可能被覆盖的安装件隐藏。 br /> fuser也可以使用，但我认为lsof具有更有用的输出。但是，fuser在消除导致戏剧性的过程方面很有用，这样您就可以继续生活。 仅杀死打开了可写文件的进程：
fuser -vmM <mountpoint>
重新安装只读（
<mountpoint>）后，它是安全的杀死所有剩余进程：fuser -vmMkiw <mountpoint>
挂接点
罪魁祸首可能是内核本身。您尝试
mount -o remount,ro <mountpoint>挂载在文件系统上的另一个文件系统会引起悲伤。检查以下对象：fuser -vmMk <mountpoint>
对于环回安装，还检查以下输出： Linux）
可以通过以下方式创建匿名索引节点：
open） [eventfd] [eventpoll]
[timerfd]
这些是最难以捉摸的神奇宝贝类型，在
O_TMPFILE的lsof列中显示为TYPE（ a_inode手册页）。它们不会出现在
lsof中，因此您需要：mount | grep <mountpoint>/
用于杀死匿名进程inode，请参阅：列出当前的inotify监视（路径名，PID）。
#6 楼
要使热熔器报告保持架打开的PID，必须使用-mfuser -m /path
评论
正确，但无关紧要：lsof / path提供的PID与Fusion -m / path相同。
–吉尔斯'所以-不再是邪恶的'
11年6月16日在7:55
fuser -M / path将检查/ path是否为安装点。
–user3804598
19年6月9日在13:22
#7 楼
我们有一个专有系统，其中根文件系统通常是只读的。有时，当必须复制文件时，将其以读写方式重新安装：mount -oremount,rw /
，然后重新安装回去： />
但这一次，
mount一直显示mount: / is busy错误。这是由一个将打开的描述符保存到文件的进程所引起的，该描述符已被某个命令替换，该命令在读写文件系统时执行。来自lsof -- /输出的重要行恰好是（名称已更改）：mount -oremount,ro /
注意输出中的
DEL。只需重新启动保留已删除文件的过程即可解决此问题。评论
因此，摘要是：打开已删除文件的进程。好的输入。
–奥雷·丹吉（Ole Tange）
16年5月2日在14:03
#8 楼
我遇到了这个问题，结果发现我不知道在后台有活动的屏幕会话。我连接到另一个活动屏幕会话，并且它的外壳当前甚至不在安装目录中。杀死其他Shell会话对我来说解决了这个问题。我以为我会分享我的解决方案。
#9 楼
lsof和fuser也都没有给我任何东西。 事实证明，我曾经做过一个从
/var/spool/postfix到/disk2/pers/mail/postfix/varspool的符号链接，以最大程度地减少基于SDCARD的根文件系统（Sheeva Plug）上的磁盘写入。有了这个符号链接，即使在停止
postfix和dovecot服务（ps aux和netstat -tuanp都没有显示任何相关信息）之后，我也无法unmount /disk2/pers。当我删除符号链接并更新时
postfix和dovecot配置文件直接指向/disk2/pers/上的新目录，我能够成功停止服务和unmount目录。 /> ls -lR /var | grep ^l | grep disk2
以上命令将递归列出所有符号链接到目录树（此处从
/var开始）中，并过滤出指向特定目标安装点（此处为disk2）的名称。评论
查找/ var -type l -lname'* disk2 *'-printf'％p->％l \ n'与ls管道相同
– go2null
昨天
#10 楼
今天的问题是插座打开了（特别是tmux）：mount /mnt/disk
export TMPDIR=/mnt/disk
tmux
<<detatch>>
umount /mnt/disk
umount: /mnt/disk: device is busy.
lsof | grep /mnt/disk
tmux 20885 root 6u unix 0xffff880022346300 0t0 3215201 /mnt/disk/tmux-0/default
#11 楼
我的挂载下有几个bind和overlay挂载阻止了我，请检查选项卡是否完成以获取要卸载的挂载点。我怀疑这尤其是覆盖安装，但也可能是绑定#12 楼
这不是解决方案，而是答案，但我将其发布，以防它对某人有所帮助。在我的情况下，我试图修改LVM，因为我想使/ var分区更大，所以我需要卸载它。我尝试了这篇文章中的所有评论并回答了（感谢所有人，尤其是@ ole-tange收集了他们），仍然出现“设备繁忙”错误。
我也尝试按照0运行级别中指定的顺序杀死大多数进程，以防万一该顺序与我的情况相关，但这也无济于事。因此，我要做的就是为我创建一个自定义运行级别（将chkconfig的输出组合到新的chkconfig --level命令中），它非常类似于1（单用户模式），但具有网络功能（使用ssh network和xinet）。
当我使用redhat时，运行级别4被标记为“未使用/用户定义”，因此我使用了该级别，然后运行
init 4 无论如何，我都需要重新启动服务器，但是可能任何人都要调整磁盘。
#13 楼
如@LawrenceC所建议，如果外壳程序的当前工作目录位于安装点路径上，则将出现“设备正忙”错误。比安装点解决错误。
评论
OP明确表示他当前的工作目录不在安装路径上。
–冈伯特
20年1月29日在21:26
@guntbert，因为注释是短暂的，问题或答案都没有提及当前工作目录是否在安装路径上的问题，因此我将其添加为显式答案。
–谐音
20 Jan 29 '21：39
@guntbert，您是对的，但是对于来自搜索引擎的人来说，这并不是不可能的问题（就像对我而言）。
– Newbyte
20年5月11日在19:38
评论
您外壳程序的当前目录位于安装点路径上吗？不，那么热熔器会这么说。
您实际上需要融合器-vm / path ...
对于umount，--force将更加努力地进行卸载，而-v或-vvv甚至将揭示更多mount的问题。因此，请尝试：umount -vvv --force / band mount