Debian/Ubuntu: как исправить Device is busy у Docker network, volume и namespace

Ошибка device is busy в Docker на Debian и Ubuntu выглядит просто, но почти всегда означает не «поломку Docker», а то, что какой-то ресурс ещё используется. Это может быть контейнер, точка монтирования, сетевой namespace, интерфейс veth или даже обычный процесс на хосте, который держит каталог тома открытым.

На практике администратор чаще всего видит одну из таких ситуаций: не удаляется сеть через docker network rm, не удаляется том через docker volume rm, не исчезает namespace после падения контейнера, либо Docker считает ресурс занятым, хотя контейнер уже остановлен.

Главное правило здесь простое: не начинайте с ручной чистки /var/lib/docker. Пока не найдено, кто удерживает ресурс, грубое удаление файлов и служебных объектов только повышает шанс сломать метаданные и получить проблему уже на уровне всего хоста.

Ниже разберём практичный порядок действий: сначала диагностика на уровне Docker, затем проверка mount и namespace в Linux, потом только очистка зависших объектов. Такой подход подходит и для одиночного сервера, и для узла с CI, сборками или тестовыми контейнерами.

Что означает Device is busy в Docker

Сообщение device is busy приходит от ядра Linux и означает, что объект ещё используется. В контейнерной среде под «объектом» обычно понимается не диск и не устройство в прямом смысле, а один из служебных ресурсов:

• точка монтирования тома или bind mount;
• сетевой namespace;
• виртуальный интерфейс veth;
• каталог тома в /var/lib/docker/volumes;
• процесс внутри mount namespace контейнера;
• процесс на хосте с открытым файловым дескриптором;
• зависший хвост после аварийного завершения dockerd или containerd.

Поэтому сама ошибка почти ничего не говорит о корне проблемы. Она лишь показывает, что зависимость ещё не освобождена.

Безопасная логика всегда одна: сначала найти, кто держит ресурс, потом освободить зависимость, и только после этого удалять сеть, том или namespace.

Быстрая первичная диагностика

Первый шаг — собрать общую картину. Нужно увидеть состояние контейнеров, логов Docker и понять, есть ли очевидный живой объект, который всё ещё привязан к проблемному ресурсу.

docker ps -a
systemctl status docker --no-pager
journalctl -u docker -n 100 --no-pager

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

docker network ls
docker network inspect NETWORK_NAME

Если не удаляется том, полезно начать с проверки его использования контейнерами:

docker volume ls
docker volume inspect VOLUME_NAME
docker ps -a --filter volume=VOLUME_NAME

Если ошибка касается namespace, пригодятся системные команды:

ip netns list
ls -la /run/docker/netns
lsns -t net,mnt,pid

Уже на этом этапе часто видно, что контейнер остановлен только формально, а дочерний процесс или старый endpoint всё ещё живут. Если вы часто запускаете тестовые контейнеры, runner'ы и временные стенды, держать их на отдельном VDS обычно удобнее: диагностика и перезапуск Docker меньше мешают рабочим сервисам.

Когда не удаляется сеть: docker network rm device is busy

Самая частая причина ошибки docker network rm device is busy — к сети всё ещё подключён контейнер, в том числе остановленный, либо Docker не очистил endpoint после аварийного завершения.

Проверьте секцию Containers в инспекте сети:

docker network inspect NETWORK_NAME

Если контейнеры там есть, сначала корректно отсоедините или удалите их:

docker stop CONTAINER_ID
docker rm CONTAINER_ID
docker network disconnect -f NETWORK_NAME CONTAINER_ID

Если контейнер из списка уже исчез, но сеть всё равно считается занятой, возможен рассинхрон метаданных. В таком случае имеет смысл повторно проверить состояние после перезапуска демона:

systemctl restart docker
docker network inspect NETWORK_NAME

Если проблема осталась, переходите на уровень ядра и смотрите интерфейсы и namespace:

ip link show
ip netns list
lsns -t net

Иногда сеть не удаляется потому, что кто-то вошёл в namespace через nsenter, отладочный скрипт или внешний агент. Тогда Docker не сможет корректно убрать сетевой объект, пока не исчезнет удерживающий процесс.

Что делать с зависшим endpoint

Практический порядок такой:

1. убедиться, что связанных контейнеров больше нет в docker ps -a;
2. перепроверить содержимое сети через docker network inspect;
3. перезапустить docker, если похоже на рассинхрон;
4. проверить lsns и ip link на остаточные объекты;
5. только потом разбирать хвосты в служебных каталогах.

Если у вас параллельно есть вопросы по сетевому поведению контейнеров, полезно отдельно посмотреть разбор как Docker работает с iptables и nftables: часть проблем с bridge и интерфейсами становится понятнее после этого.

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

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

Подробнее

Когда не удаляется том: docker volume rm device is busy

С ошибкой docker volume rm device is busy почти всегда связан mount namespace или открытый путь в файловой системе. Даже если контейнер остановлен, том всё ещё может удерживаться другим контейнером, живым дочерним процессом или обычной shell-сессией на хосте.

Сначала проверяем использование тома через Docker:

docker ps -a --filter volume=VOLUME_NAME
docker volume inspect VOLUME_NAME

Затем получаем путь монтирования:

docker volume inspect VOLUME_NAME --format '{{ .Mountpoint }}'

После этого уже ищем реального держателя на уровне Linux:

lsof +D /var/lib/docker/volumes/VOLUME_NAME/_data
fuser -vm /var/lib/docker/volumes/VOLUME_NAME/_data
findmnt -R /var/lib/docker/volumes/VOLUME_NAME/_data

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

Если findmnt показывает остаточный mount, проверьте mount namespace:

lsns -t mnt

Затем найдите PID и посмотрите, к чему он относится:

readlink /proc/PID/ns/mnt
ls -la /proc/PID/fd
cat /proc/PID/cgroup

Безопасная очистка тома

Обычно работает такой порядок:

1. остановить и удалить контейнеры, связанные с томом;
2. выйти из каталога тома на хосте;
3. завершить внешние процессы, использующие путь;
4. проверить остаточные mount через findmnt;
5. если mount действительно лишний — размонтировать его;
6. повторить docker volume rm.

umount /var/lib/docker/volumes/VOLUME_NAME/_data
docker volume rm VOLUME_NAME

К umount -l лучше относиться как к аварийному инструменту. Он может убрать симптом, но не причину. Поэтому сначала ищите удерживающий PID, а уже потом решайте, нужен ли ленивый unmount.

Cannot remove network namespace и ip netns delete device busy

Сетевые namespace Docker не всегда ведут себя как namespace, созданные вручную через ip netns add. Docker использует свои служебные объекты, поэтому ошибка cannot remove network namespace часто означает, что namespace ещё связан с процессом, интерфейсом или внутренним объектом Docker.

Проверяем список namespace и общую картину по процессам:

ip netns list
lsns -t net -p 1
for p in /proc/[0-9]*; do readlink "$p/ns/net"; done | sort | uniq -c

Дальше нужно понять две вещи: есть ли ещё процесс внутри namespace и остались ли связанные интерфейсы. Иногда namespace держит не контейнер, а зависший containerd-shim, отладочная сессия или ручной запуск через nsenter.

ps -ef | grep -E 'dockerd|containerd|containerd-shim|runc' | grep -v grep

Если подозрительный netns-файл виден в /run/docker/netns, проверьте, не открыт ли он как дескриптор:

lsof /run/docker/netns
fuser -vm /run/docker/netns

Полезно также сверить интерфейсы:

ip link show type veth
bridge link
brctl show

На Debian и Ubuntu утилита brctl может отсутствовать, и это нормально. В большинстве случаев хватает bridge link и ip link.

Как удалять namespace аккуратно

Если namespace создавался вручную, порядок стандартный: убрать интерфейсы, убедиться в отсутствии процессов, затем удалять namespace. Если это Docker-namespace, безопаснее сначала очистить контейнерную сущность через Docker, а не удалять netns-файл напрямую.

1. найти контейнер, shim-процесс или внешнюю сессию, связанную с namespace;
2. остановить контейнер или завершить зависший процесс;
3. проверить исчезновение объекта через lsns;
4. при необходимости перезапустить Docker;
5. только в крайнем случае трогать служебный netns вручную.

Mount namespace: где обычно скрыта реальная причина

Многие ошибки busy при удалении volume, container и даже network на самом деле упираются именно в mount namespace. Снаружи контейнер уже остановлен, но внутри его mount namespace продолжает жить дочерний процесс.

Для проверки пригодятся такие команды:

lsns -t mnt
ps -eo pid,ppid,cmd,mntns --sort=mntns

Если несколько процессов сидят в одном mount namespace, ищите тот, который пережил основной контейнерный PID. Часто это shell, worker, агент резервного копирования или зависший процесс с открытым файлом в volume.

Полезно смотреть cgroup конкретного PID:

cat /proc/PID/cgroup

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

kill TERM PID
sleep 2
kill -KILL PID

После этого повторно проверьте lsns, findmnt и только затем возвращайтесь к удалению тома или сети. Если интересна тема дополнительной изоляции контейнеров, можно почитать и про изоляцию контейнерных нагрузок через gVisor и Firecracker.

Короткий runbook: от ошибки к исправлению

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

1. определите, что именно не удаляется: сеть, том, контейнер или namespace;
2. проверьте Docker-уровень через docker ps -a, docker network inspect, docker volume inspect;
3. проверьте Linux-уровень через lsns, findmnt, lsof, fuser;
4. найдите удерживающий PID или интерфейс;
5. остановите контейнер либо завершите зависший процесс;
6. убедитесь, что mount или namespace исчез;
7. только после этого удаляйте ресурс;
8. если остался рассинхрон метаданных, перезапустите docker.

docker ps -a
lsns -t net,mnt
findmnt -R /var/lib/docker
lsof /run/docker/netns
systemctl restart docker

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

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

Подробнее

Когда помогает перезапуск Docker, а когда нет

Перезапуск dockerd действительно часто помогает при зависших endpoint и старых ссылках на namespace, но он не решает проблему, если живой процесс по-прежнему удерживает ресурс.

Перезапуск обычно уместен, когда:

• контейнеров, использующих ресурс, уже нет;
• ошибка похожа на рассинхрон метаданных;
• сбой появился после падения хоста или самого Docker;
• в логах видны ошибки cleanup.

Перезапуск мало поможет, если:

• файлы удерживает сторонний процесс;
• кто-то работает внутри каталога тома;
• жив containerd-shim или дочерний процесс контейнера;
• осталась реальная точка монтирования.

Именно поэтому сервисный рестарт — это не первый шаг, а один из шагов после диагностики.

Чего делать не стоит

Есть несколько популярных, но рискованных действий, которые часто делают ситуацию хуже:

• удаление каталогов из /var/lib/docker вручную без понимания зависимостей;
• массовый rm -rf по томам при работающем Docker;
• попытка сразу применять umount -l ко всем подозрительным путям;
• жёсткое завершение dockerd и containerd без проверки рабочих контейнеров;
• ручное удаление netns-файлов в /run/docker/netns без проверки процессов и интерфейсов.

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

Профилактика

Полностью исключить ошибки busy нельзя, но уменьшить их частоту вполне реально:

• не прерывайте деплой и cleanup посередине операции;
• используйте корректную обработку сигналов завершения в приложениях;
• не работайте без необходимости внутри каталогов volume на проде;
• проверяйте зависшие дочерние процессы после остановки контейнеров;
• регулярно смотрите логи Docker и общее состояние узла;
• не смешивайте ручное управление namespace с объектами, которыми управляет Docker.

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

Вывод

Ошибка device is busy в Docker на Debian и Ubuntu — это не одна поломка, а общий симптом: ресурс всё ещё удерживается. Для сети чаще виноваты endpoint, netns и veth, для томов — mount namespace, открытые файлы и остаточные mount, для namespace — живые процессы и неочищенные интерфейсы.

Самый надёжный путь — идти от процесса к ресурсу: сначала найти держателя, затем освободить mount или namespace, потом повторить удаление. Именно этот порядок позволяет решить проблему аккуратно и без лишнего риска для рабочего хоста.