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 の comment に追加すると、この問題の顕現の原因はstaleループバックマウント。私はすでにfuser -vm <mountpoint>/lsof +D <mountpoint>、mountおよびcat /proc/mountsの出力を確認し、古いnfs-kernel-serverが実行されているかどうかを確認し、割り当てをオフにし、試行しました（しかし失敗しました）umount -f <mountpoint>と、残りのすべてがlosetupの出力を最終的に確認し、構成されているがマウントされていない古い2つのループバックを見つける前に、924日間の稼働時間を放棄することを辞任しました。
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>）を再マウントした後、残りのすべてのプロセスを強制終了しても安全です（r）。
fuser -vmMk <mountpoint>
マウントポイント
犯人はカーネルそのものかもしれません。 umountを実行しようとしているファイルシステムにマウントされている別のファイルシステムは、問題を引き起こします。確認する：
mount | grep <mountpoint>/
ループバックマウントの場合は、次の出力も確認してください。
losetup -la
匿名のiノード（Linux）
匿名のiノード は次の方法で作成できます。
- 一時ファイル（
openwithO_TMPFILE） - inotify ウォッチ
- [eventfd]
- [イベントポール]
- [timerfd]
これらは最もわかりにくいタイプのポケモンであり、lsofのTYPE列にはa_inodeとして表示されます（ lsof manページ ）。
これらはlsof +f -- /dev/<device>には表示されないため、以下を行う必要があります。
lsof | grep a_inode
匿名のiノードを保持しているプロセスの強制終了については、 現在のinotify監視（パス名、PID） の一覧を参照してください。
フューザーがマウントオープンを保持しているPIDについてレポートするには、-mを使用する必要があります
fuser -m /path
ルートファイルシステムが通常読み取り専用である独自のシステムがあります。時々、ファイルをコピーする必要があるとき、それは読み書き可能で再マウントされます：
mount -oremount,rw /
そして再びマウントし直しました：
mount -oremount,ro /
ただし、今回はmountがmount: / is busyエラーを出し続けました。これは、何らかのコマンドによってreplacedされたファイルへのオープン記述子を保持しているプロセスによって引き起こされました。これは、ファイルシステムが読み書き可能であるときに実行されました。 lsof -- /の出力の重要な行はたまたまです（名前は変更されています）：
replicate 1719 admin DEL REG 8,5 204394 /opt/gns/lib/replicate/modules/md_es.so
出力のDELに注意してください。削除されたファイルを保持しているプロセスを再起動するだけで問題は解決しました。
lsofとfuserからも何も得られませんでした。
すべての可能なディレクトリの名前を.oldに変更し、変更を加えるたびにシステムを再起動した後、原因となっている特定のディレクトリ（postfixに関連する）を1つ見つけました。
SDCARDベースのルートファイルシステム（Sheevaプラグ）でのディスク書き込みを最小限に抑えるために、私はかつて/var/spool/postfixから/disk2/pers/mail/postfix/varspoolへのシンボリックリンクを作成したことがわかりました。
このシンボリックリンクでは、postfixサービスとdovecotサービスを停止した後でも（ps auxとnetstat -tuanpの両方に関連するものは何も表示されませんでした）unmount /disk2/persを実行できませんでした。
シンボリックリンクを削除し、postfixおよびdovecot構成ファイルを更新して、/disk2/pers/上の新しいディレクトリを直接指すようにすると、サービスとunmountを正常に停止できました。
次回は、次の出力を詳しく見ていきます。
ls -lR /var | grep ^l | grep disk2
上記のコマンドは、ディレクトリツリー（ここでは/varで始まる）内のすべてのシンボリックリンクを再帰的にリストし、特定のターゲットマウントポイント（ここではdisk2）を指す名前をフィルターで除外します。
私にはこの問題があり、知らないバックグラウンドでアクティブなスクリーンセッションがあったことがわかりました。他のアクティブなスクリーンセッションに接続しましたが、そのシェルは現在、マウントされたディレクトリに座っていませんでした。他のシェルセッションを終了すると、問題が解決しました。
私の決意を共有すると思いました。
マウントの下にいくつかのbindマウントとoverlayマウントがあり、ブロックされていました。アンマウントするマウントポイントのタブの完了を確認してください。特にオーバーレイマウントだったのではないかと思いますが、これもバインドでした。
これは回答というよりは回避策ですが、誰かの助けになるかもしれない場合に備えて投稿します。
私の場合、/ varパーティションを大きくしたいのでLVMを変更しようとしていたため、アンマウントする必要がありました。私はこの投稿でコメントと回答をすべて試しました（みんなに感謝し、特に@ ole-tangeがそれらを収集してくれた）、それでも「デバイスがビジーです」というエラーが発生しました。
私の場合、順序が適切である場合に備えて、ほとんどのプロセスを0ランレベルで指定された順序で強制終了しようとしましたが、それも役に立ちませんでした。したがって、私が行ったのは、1（シングルユーザーモード）と非常によく似ていますが、ネットワーク機能（sshネットワークとxinetを使用）を持つカスタムランレベル（chkconfigの出力を新しいchkconfig --levelコマンドに結合）を作成することでした。
Redhatを使用していたので、ランレベル4は「未使用/ユーザー定義」としてマークされているので、それを使用してinit 4私の場合、どの場合でもサーバーを再起動する必要があったため、これで問題ありませんでしたが、おそらくディスクを微調整する人の場合はそうでしょう。
今日の問題はオープンソケット（具体的には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