Debian/Ubuntu: как размонтировать busy mount — lsof, fuser, lazy umount и bind mount

Ошибка umount: target is busy или umount: device or resource busy в Debian и Ubuntu кажется простой только до первого реального инцидента. На тестовой машине всё часто упирается в открытый файл. На сервере картина шире: shell стоит внутри каталога, сервис держит рабочую директорию, внутри сидит вложенный mount, каталог используется через bind mount, а lsof не показывает ничего очевидного.

Хорошая новость в том, что причина почти всегда находится, если идти по понятному чек-листу, а не начинать с umount -l или перезагрузки. Ниже разберём безопасный порядок действий: как проверить точку монтирования, чем отличаются lsof и fuser, когда помогает lazy umount и почему про bind-монтирования забывают чаще всего.

Материал рассчитан на обычные серверные сценарии: отдельный диск или раздел, временный mount, сетевой том, chroot, контейнеры, каталоги приложений, бэкапы и миграции. Все команды подойдут для Debian и Ubuntu.

Главное правило простое: сначала выясняем, кто использует файловую систему, и только потом выбираем способ размонтирования. Это почти всегда быстрее и безопаснее, чем силовые методы.

Что именно означает busy при umount

Когда umount отказывается работать, ядро видит активное использование точки монтирования или самой файловой системы. И это не обязательно открытый файл. Busy может означать сразу несколько разных ситуаций.

• Процесс держит открытые файлы или дескрипторы внутри mount point.
• Чей-то текущий рабочий каталог находится внутри этого пути.
• Процесс использует каталог как root через chroot или namespace.
• Внутри есть вложенные точки монтирования.
• Тот же каталог подключён повторно через bind mount.
• Файловую систему удерживает сервис, automount, контейнерный runtime или ядро.

Поэтому сообщение target is busy не отвечает на вопрос, кто именно мешает. Оно лишь говорит, что обычное размонтирование сейчас небезопасно.

Сначала проверьте, что размонтируете именно ту точку

Первая и очень частая ошибка — работать не с той точкой монтирования. Например, администратор видит каталог /mnt/data, но внутри есть дочерний mount, bind-монтирование или другой источник, который меняет картину.

findmnt
findmnt /mnt/data
mount | grep '/mnt/data'
cat /proc/self/mountinfo | grep '/mnt/data'

Обычно удобнее всего начинать с findmnt. Команда показывает дерево, источник, тип файловой системы и вложенные монтирования. Если внутри /mnt/data есть дочерние точки, сначала снимают их, а уже потом родительскую.

Отдельно обращайте внимание на повторяющиеся записи одного источника с разными целями. Это типичный признак bind mount или использования mount namespace контейнерами.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Частая причина: shell или утилита стоят внутри каталога

Самый банальный, но очень частый случай: текущая shell-сессия находится внутри каталога, который вы пытаетесь размонтировать. Иногда это ваша сессия, иногда чужая вкладка терминала, root-shell после sudo -i, tmux, screen или файловый менеджер.

pwd
cd /
umount /mnt/data

Полезно проверить и другие сессии на машине:

w
who
ps -ef | grep bash
ps -ef | grep sh

Если сервером пользуются несколько администраторов, busy легко создаёт чужой shell. Перед размонтированием боевого тома лучше синхронизироваться с командой, особенно если на пути висят резервные копии, деплой или ручная отладка.

Диагностика через lsof: кто держит файлы и каталоги

Когда нужен ответ на вопрос, какие процессы используют конкретный mount, обычно первым делом запускают lsof. Для разборов umount device or resource busy это одна из самых полезных утилит.

lsof +f -- /mnt/data
lsof /mnt/data
lsof | grep '/mnt/data'

На практике полезнее всего указывать конкретный путь. В выводе смотрите на имя процесса, PID, тип дескриптора, путь к файлу или каталогу, а также признаки текущего каталога процесса, корня процесса или mmap.

Если вы видите, что процесс держит лог, сокет, PID-файл или рабочий каталог внутри точки монтирования, виновник найден. Дальше уже решается по ситуации: остановить сервис, перевести задачу в другой каталог, дождаться окончания операции или завершить PID.

Но важно помнить нюанс: lsof не всегда мгновенно показывает всю картину, особенно на загруженных системах и при работе с контейнерами. Поэтому его стоит дополнять другими проверками.

Диагностика через fuser: кто использует файловую систему прямо сейчас

fuser нередко оказывается даже удобнее, чем lsof, если нужен список PID, которые держат именно mount point. Для сценария fuser umount это очень практичный инструмент.

fuser -vm /mnt/data
fuser -vmM /mnt/data

Здесь -m трактует путь как файловую систему, а не как обычный файл. Опция -M полезна как защита от ошибки: она требует, чтобы путь действительно был точкой монтирования.

Если нужно быстро понять, мешает ли конкретный процесс, удобно сразу проверить его отдельно:

ps -fp 1234
readlink -f /proc/1234/cwd
readlink -f /proc/1234/root
ls -l /proc/1234/fd

Такой подход особенно полезен, когда сервис породил несколько дочерних процессов и нужно понять, кто именно всё ещё висит в каталоге.

Как безопасно освободить mount: сначала останавливайте сервисы

Когда виновник найден, следующий шаг — освободить точку монтирования с минимальным риском. В продакшне почти всегда лучше корректно остановить службу, чем сразу переходить к принудительному завершению процессов.

Если путь использует веб-сервер, воркер очередей, агент резервного копирования, контейнерный runtime или собственный сервис приложения, начинайте с штатной остановки:

systemctl stop nginx
systemctl stop php8.2-fpm
systemctl stop docker
systemctl stop myapp.service

После этого повторите проверку:

lsof +f -- /mnt/data
fuser -vmM /mnt/data

Если процессы не исчезли, значит, могли остаться дочерние PID, namespace, зависшие операции ввода-вывода или другой скрытый держатель. Тогда уже стоит разбирать конкретные процессы точечно.

Если речь идёт о базе данных, очередях, почтовом хранилище или активной записи на диск, не превращайте размонтирование в аварийную остановку. Сначала завершите приложение штатно и убедитесь, что данные успели сброситься на диск.

Когда использовать kill, а когда лучше не спешить

Если процесс не критичен и вы понимаете последствия, можно завершить его вручную. Начинать стоит с мягкого сигнала:

kill 1234
kill -TERM 1234

И только если процесс не реагирует, переходить к жёсткому варианту:

kill -KILL 1234

Но тут есть две важные оговорки. Во-первых, принудительное завершение не гарантирует мгновенное освобождение mount, если процесс завис в состоянии D на I/O. Во-вторых, приложение можно оставить в неконсистентном состоянии. Поэтому kill -KILL — это уже крайний шаг, а не стандартный рецепт.

Bind mount: самый частый «невидимый» виновник

Отдельно стоит запомнить тему bind mount. Именно bind-монтирования регулярно ломают логику диагностики. У вас может быть каталог /srv/data, который дополнительно примонтирован в /var/www/data через --bind. Внешне это выглядит как обычный каталог, но для ядра это отдельное монтирование.

findmnt -R /srv/data
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS

Если видно, что каталог смонтирован ещё и в другое место, сначала снимайте bind-mount, а уже затем исходную точку, если это требуется по задаче.

umount /var/www/data
umount /srv/data

Ключевой момент: bind mount может ссылаться на каталог снаружи, а не только находиться внутри него. Поэтому простой просмотр содержимого каталога проблему не покажет — нужна именно проверка таблицы монтирований.

Кстати, если вы одновременно поддерживаете DNS-инфраструктуру и привязываете сервисы к разным зонам доступа, может пригодиться материал про split-horizon и views в BIND: логика разделения контекстов там другая, но сама идея «одно и то же выглядит по-разному в разных окружениях» очень знакома и при работе с namespace.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Вложенные монтирования и порядок размонтирования

Если у вас дерево mount points, размонтирование должно идти снизу вверх. Иначе родительская точка всегда будет занята дочерними. Это типично для chroot-окружений, rescue-сценариев, контейнеров и ручного обслуживания системных разделов.

findmnt -R /mnt/chroot

Если внутри видны /mnt/chroot/proc, /mnt/chroot/sys, /mnt/chroot/dev, сначала снимаются они, и только потом сам корень chroot:

umount /mnt/chroot/proc
umount /mnt/chroot/sys
umount /mnt/chroot/dev
umount /mnt/chroot

Для больших деревьев может помочь рекурсивное размонтирование:

umount -R /mnt/chroot

Но на рабочих серверах я советую сначала посмотреть дерево через findmnt -R, а уже потом применять рекурсию. Так меньше шанс снять что-то лишнее.

Lazy umount: что делает umount -l на самом деле

umount -l не «отрывает файловую систему силой». Он лениво отсоединяет точку монтирования от текущего namespace: путь пропадает из дерева монтирований, но реальные ресурсы освобождаются позже, когда на них перестанут ссылаться процессы.

umount -l /mnt/data

Это уместно в нескольких сценариях:

• подвисший сетевой mount мешает дальнейшей работе;
• нужно быстро убрать временное окружение из namespace;
• идёт очистка при shutdown или cleanup, где важнее отвязать путь, чем немедленно закрыть все обращения.

Но lazy umount — не универсальная таблетка. Если процессы продолжают писать в файловую систему, они ещё какое-то время будут работать со старым mount, а диагностика станет менее прозрачной. Для локальных томов с важными данными лучше сначала освободить точку обычным способом.

Отдельно помните о последствиях: после lazy umount путь может исчезнуть, но устройство ещё останется занятым на уровне ядра. Это неприятно, если вы собираетесь сразу отключать loop-устройство, удалять LVM-том, отсоединять диск или менять конфигурацию RAID.

Почему umount -f не является волшебной кнопкой

Иногда в таких случаях вспоминают про umount -f. На Linux этот режим в основном полезен для некоторых сетевых файловых систем. Для обычных локальных ext4 или xfs это не кнопка «снять несмотря ни на что».

Если у вас локальный диск и ошибка busy, почти всегда правильнее искать процесс, bind mount, дочернюю точку монтирования или проблемы с I/O, а не надеяться на force-режим.

Что делать, если lsof и fuser ничего не показывают

Такие случаи тоже бывают. Если lsof и fuser не дали результата, проверьте более редкие, но вполне реальные источники busy.

Проверьте mount namespaces и контейнеры

Контейнерный runtime или systemd может держать mount в отдельном namespace. На хосте это не всегда видно с первого взгляда.

systemctl list-units --type=service --state=running
ps -ef | grep -E 'docker|containerd|podman|runc'

Если каталог связан с контейнерами, сначала корректно остановите контейнеры или сам runtime.

Проверьте systemd mount и automount units

Иногда точка монтирования управляется через .mount или .automount unit. Тогда обычный umount может фактически спорить с менеджером сервисов.

systemctl status mnt-data.mount
systemctl status mnt-data.automount

Если mount описан в systemd, возможно, сначала нужно остановить соответствующий unit.

Проверьте swap-файлы, loop-устройства и удалённые файлы

Если внутри точки монтирования лежит активный swap-файл или loop-образ, обычная проверка каталога не всегда быстро приводит к ответу.

swapon --show
losetup -a
lsof | grep deleted

Удалённый, но всё ещё открытый большой файл тоже может продолжать удерживать файловую систему и место на диске.

Смотрите сообщения ядра

dmesg | tail -n 50
journalctl -k -n 50

Если процесс завис на I/O, сетевой том недоступен, а диск отвечает ошибками, это часто видно именно в сообщениях ядра.

Практический порядок действий для продакшна

Когда нужно снять mount без суеты и лишнего риска, удобно идти по короткому сценарию:

1. Проверить дерево монтирований через findmnt.
2. Убедиться, что вы и коллеги не находитесь внутри каталога.
3. Проверить пользователей точки через lsof и fuser.
4. Корректно остановить сервисы, связанные с этим путём.
5. Проверить bind mount и дочерние точки монтирования.
6. Повторить обычный umount.
7. Использовать umount -l только если вы понимаете последствия и это действительно лучший вариант.

Такой порядок почти всегда эффективнее, чем сразу убивать процессы или перезагружать сервер. Если вы держите приложения на VDS, имеет смысл оформить этот чек-лист как внутренний runbook — экономит время во время ночных работ и аварийных переключений.

Готовый runbook: набор команд под рукой

Ниже компактная шпаргалка для случаев, когда umount отвечает busy:

findmnt /mnt/data
findmnt -R /mnt/data
cat /proc/self/mountinfo | grep '/mnt/data'
pwd
cd /
lsof +f -- /mnt/data
fuser -vmM /mnt/data
systemctl stop myapp.service
ps -fp 1234
readlink -f /proc/1234/cwd
readlink -f /proc/1234/root
umount /mnt/data
umount -R /mnt/data
umount -l /mnt/data

Подставьте свою точку монтирования и не пропускайте промежуточные проверки. Именно они обычно экономят больше всего времени.

Типичные ошибки администраторов

• Размонтировать не ту точку, когда реальный mount расположен глубже или выше по дереву.
• Игнорировать bind mount.
• Сразу использовать kill -9 без остановки сервиса.
• Применять lazy umount как универсальный фикс.
• Не замечать, что shell, tmux или файловый менеджер стоят внутри каталога.
• Забывать про контейнеры, chroot и systemd mount units.

Если держать эти пункты в голове, большинство инцидентов с busy mount решаются за несколько минут.

Итог

Ошибка umount device or resource busy в Debian и Ubuntu почти никогда не бывает случайной. За ней стоит конкретная причина: процесс, рабочий каталог, дочерний mount, bind mount, контейнерный namespace или проблемный ввод-вывод.

Лучший путь — начать с findmnt, затем пройтись по lsof и fuser, корректно освободить путь и только потом размонтировать. lazy umount полезен, но не заменяет диагностику. А про bind-монтирования стоит вспоминать сразу, особенно в ситуации «вроде никто ничего не держит, но umount всё равно отвечает busy».

Если превратить этот порядок в привычный runbook, неприятные случаи с размонтированием перестают быть лотереей и становятся обычной рутинной задачей администратора.