umount: устройство занято. Почему?

Вместо того, чтобы использовать lsof для проверки через файловую систему просто используйте общий список открытых файлов и grep это. Я нахожу, что это возвращается, должен быстрее, хотя это менее точно. Это должно сделать задание.

lsof | grep '/path'

Чтобы термофиксатор сообщил относительно PIDs о содержании монтирования, открытого, необходимо использовать-m

fuser -m /path

Для добавления к комментарию BruceCran выше причиной для моего проявления этой проблемы сейчас была устаревшая обратная петля, монтируются. Я уже проверил вывод fuser -vm <mountpoint>/lsof +D <mountpoint>, mount и cat /proc/mounts, проверил, работал ли некоторый старый сервер ядра nfs, выключил квоты, предпринятые (но перестал работать), a umount -f <mountpoint> и почти примирившийся я с отказом от времени работы 924 дней прежде наконец проверить вывод losetup и нахождение двух устаревших configured-but-not-mounted обратных петель:

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#

Хинду сообщение форума также перечисляет своп-файлы как потенциального преступника; хотя свопинг в файлы, вероятно, довольно редок в эти дни, не может повредить проверять вывод cat /proc/swaps. Я не уверен, могли ли квоты когда-либо предотвращать размонтирование — я хватался за соломинку.

У меня была эта проблема, и оказалось, что были активные экранные сессии в фоновом режиме, я не знал о. Я соединился с другой активной экранной сессией, и ее оболочка даже в настоящее время не находилась в смонтированном каталоге. Уничтожение тех других сессий оболочки устранило проблему для меня.

Просто мысль я совместно использовал бы свое разрешение.

Для меня незаконный процесс был демоном, работающим в chroot. Поскольку это было в chroot, lsof и fuser не нашел бы его.

Если Вы подозреваете, что имеете еще кое-что, работая в chroot, sudo ls -l /proc/*/root | grep chroot найдет преступника (замените "chroot" путем к chroot).

[12151]lsof[114758] и [114759]fuser[114760] мне тоже ничего не дали.[12152]После процесса переименования всех возможных каталогов в .old и перезагрузки системы каждый раз после внесения изменений я находил один конкретный каталог (относящийся к постфиксу), который был ответственным. [12153]Оказалось, что однажды я сделал сим-ссылку с [114761]/var/spool/postfix[114762] на [114763]/disk2/pers/mail/postfix/varspool[114764] для того, чтобы минимизировать записи на диск в корневой файловой системе на базе SDCARD (Sheeva Plug). С помощью этой симлинковой ссылки, даже после остановки сервисов [114765]postfix[114766] и [114767]dovecot[114768] (оба [114769]ps aux[114770], а также [114771]netstat -tuanp[114772] ничего не показали) я не смог [114773]размонтировать /disk2/pers[114774]. Когда я удалил симлинк и обновил постфикс [114775]postfix[114776] и конфигурационные файлы [114777]dovecot[114778] для указания непосредственно на новые dirs на [114779]/disk2/pers/[114780], я смог успешно остановить сервисы и [114781]размонтировать[114782] каталог. [12156]В следующий раз я подробнее рассмотрю вывод:[12157]Вышеприведенная команда рекурсивно перечислит все символические ссылки в дереве каталогов (здесь, начиная с [114783]/var[114784]) и отфильтрует имена, указывающие на конкретную целевую точку монтирования (здесь, на диске2).[114389].

Сегодня проблема была в открытом сокетах (в частности 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

У нас есть собственная система, в которой корневая файловая система обычно доступна только для чтения. Иногда, когда файлы необходимо скопировать, он повторно монтируется для чтения-записи:

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 в выводе. Простой перезапуск процесса, удерживающего удаленный файл, решил проблему.

У меня есть несколько ездовых животных bindи overlayпод моим ездовым животным, которые блокировали меня, проверьте завершение вкладки для точки крепления -, которую вы хотите размонтировать. Я подозреваю, что это было, в частности, накладное крепление, но могло быть и крепление

.

Открытые файлы

Обычно виновниками являются процессы с открытыми файлами. Отобразите их:

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

Анонимные иноды (Linux)

Анонимные иноды могут быть созданы с помощью:

• Временные файлы(openсO_TMPFILE)
• inotify часы
• [событиеfd]
• [опрос событий]
• [таймерфд]

Это самый неуловимый тип покемонов, и они появляются в lsofколонке TYPEкак a_inode(, которая не задокументирована на справочной страницеlsof).

Они не появятся в lsof +f -- /dev/<device>, поэтому вам нужно:

lsof | grep a_inode

Информацию об уничтожении процессов, содержащих анонимные индексные дескрипторы, см. в разделе:List current inotify watch (pathname, PID).

Как предложил @LawrenceC , если текущий рабочий каталог вашей оболочки находится на пути к точке монтирования, вы получите сообщение об ошибке «устройство занято».

ubuntu@myip:~/efs$ sudo umount ~/efs
umount.nfs4: /home/ubuntu/efs: device is busy

cdв место, отличное от точки подключения, чтобы устранить ошибку.

В моем случае я ранее сделал zpool importфайлового -пула на этом диске. Я не мог размонтировать диск, потому что он использовался, но lsofи fuserничего не показывали.

Решение состояло в том, чтобы выполнить sudo zpool export mypool, а затем размонтировать.