umount：设备正忙。为什么？

运行时，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

这对于所有未使用的已挂载文件系统都是正常的。

umount -l而umount -f不是我的情况不够好。

我如何弄清楚为什么内核认为这个文件系统很忙？

看来造成我问题的原因是nfs-kernel-server正在导出目录。将nfs-kernel-server可能进入正常打开的文件后面，因此没有上市lsof和fuser。

当我停止时，nfs-kernel-server我可以umount进入目录。

到目前为止，我已经在此处制作了所有解决方案示例的页面：http : //oletange.blogspot.com/2012/04/umount-device-is-busy-why.html

在上面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。我不确定配额是否可以防止出现不合时宜的情况-我当时正抓着稻草。

不必使用lsof来爬行文件系统，而只需使用打开文件的总列表并将其grep即可。我发现此回报必须更快，尽管准确性较差。它应该完成工作。

lsof | grep '/path'

对我而言，令人讨厌的进程是在chroot中运行的守护程序。因为它是在一个chroot，lsof而fuser不会发现它。

如果您怀疑您在chroot中还有其他东西要运行，sudo ls -l /proc/*/root | grep chroot将找到罪魁祸首（将“ chroot”替换为chroot的路径）。

打开文件

带有打开文件的进程是常见的罪魁祸首。显示它们：

lsof +f -- <mountpoint or device>

使用/dev/<device>而不是会有一个好处 /mountpoint：挂载点将在后面消失umount -l，或者可能被覆盖的挂载隐藏。

fuser也可以使用，但在我看来lsof有更有用的输出。但是fuser，在终止造成戏剧性事件的过程方面很有用，这样您就可以继续生活。

列出文件<mountpoint>（请参见上面的注意事项）：

fuser -vmM <mountpoint>

以交互方式仅杀死打开了可写入文件的进程：

fuser -vmMkiw <mountpoint>

重新挂载只读（mount -o remount,ro <mountpoint>）后，可以安全地杀死所有剩余进程：

fuser -vmMk <mountpoint>

挂载点

罪魁祸首可能是内核本身。您尝试安装在文件系统上的另一个文件系统umount会造成麻烦。检查：

mount | grep <mountpoint>/

对于环回安装，还请检查以下输出：

losetup -la

匿名索引节点（Linux）

可以通过以下方式创建匿名索引节点：

• 临时文件（open带有O_TMPFILE）
• 使手表变声
• [eventfd]
• [事件投票]
• [timerfd]

这些是最难以捉摸的神奇宝贝类型，在lsof的TYPE列中显示为a_inode（在lsof手册页中未记录 ）。

它们不会出现在中lsof +f -- /dev/<device>，因此您需要：

lsof | grep a_inode

有关杀死持有匿名inode的进程，请参阅：列出当前inotify监视（路径名，PID）。

要使热熔器报告保持安装打开的PID，必须使用-m

fuser -m /path

我们有一个专有系统，其中根文件系统通常是只读的。有时，当必须复制文件时，会以读写方式重新挂载它：

mount -oremount,rw /

然后重新装回：

mount -oremount,ro /

但是，这一次mount一直给出mount: / is busy错误。这是由一个将打开的描述符保存到文件的进程所引起的，该描述符已被某个命令替换，该命令在读写文件系统时执行。lsof -- /输出的重要行恰好是（名称已更改）：

replicate  1719 admin DEL REG 8,5  204394 /opt/gns/lib/replicate/modules/md_es.so

注意DEL输出中的。只需重新启动保留已删除文件的过程即可解决此问题。

lsof并fuser没有给我任何要么。

在将所有可能的目录重命名为.old并在每次进行更改后每次重新引导系统的过程之后，我发现一个特定的目录（与postfix有关）负责。

原来，我曾经做过一个从/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）的名称。

我遇到了这个问题，结果发现我不知道在后台有活动的屏幕会话。我连接到另一个活动屏幕会话，并且它的外壳当前甚至不在安装目录中。杀死其他shell会话对我来说解决了这个问题。

只是以为我会分享我的决心。

今天的问题是一个开放的套接字（特别是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

我有一对夫妇的bind和overlay坐骑在我安装的是被阻止我，请查看选项卡完成您要卸载挂载点。我怀疑这特别是覆盖安装，但也可能是绑定

这不是解决方案，而是答案，但我将其发布，以防可能对某人有所帮助。

在我的情况下，我试图修改LVM，因为我想使/ var分区更大，所以我需要将其挂载。我尝试了这篇文章中的所有评论并回答了（感谢所有人，尤其是@ ole-tange收集了他们），仍然出现“设备繁忙”错误。

我也尝试按照0运行级别中指定的顺序杀死大多数进程，以防万一该顺序与我的情况相关，但这也无济于事。因此，我要做的就是为我创建一个自定义运行级别（将chkconfig的输出组合到新的chkconfig --level命令中），该级别非常类似于1（单用户模式），但是具有网络功能（使用ssh network和xinet）。

当我使用redhat时，运行级别4被标记为“未使用/用户定义的”，因此我使用了该级别，然后运行 init 4 。调整磁盘的人。