Debian/Ubuntu: failed to create shim task и OCI runtime create failed в Docker — как найти причину и быстро исправить

Ошибки вида failed to create shim task, OCI runtime create failed и общий container start error в Docker на Debian и Ubuntu пугают не столько формулировкой, сколько своей расплывчатостью. Сообщение выглядит как низкоуровневая поломка рантайма, а реальная причина может быть вполне приземлённой: отсутствует файл, не примонтирован сокет, сломан профиль AppArmor, не совпадает конфигурация cgroups v2, повреждён runc, контейнер стартует с неподходящим seccomp-профилем или в образе указан несуществующий бинарник.

Проблема в том, что Docker здесь лишь верхний слой. Цепочка запуска обычно выглядит так: клиент обращается к демону Docker, демон передаёт задачу в containerd, тот поднимает shim-процесс, а дальше runc создаёт контейнер через механизмы ядра Linux. Поэтому одинаковая верхнеуровневая ошибка может означать сбой на разных уровнях стека.

Ниже разберём практичный сценарий диагностики: с чего начинать, какие логи и команды действительно помогают, как отличить no such file or directory от проблем с AppArmor или seccomp, что проверять в Debian 11/12 и Ubuntu 22.04/24.04, и в каких случаях виноваты cgroups v2 или несовместимые версии компонентов.

Почти никогда не стоит начинать с бездумного apt reinstall docker. Такой шаг редко помогает понять причину и часто лишь маскирует её, особенно если ошибка связана с образом, volume, пользовательским профилем безопасности или конкретной командой запуска.

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

Как проявляется ошибка и что она обычно означает

Типовые сообщения могут выглядеть по-разному, но читать их нужно одинаково:

Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/app/start.sh": stat /app/start.sh: no such file or directory: unknown

Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: unable to apply cgroup configuration: unknown

Error response from daemon: failed to create shim task: OCI runtime create failed: unable to start container process: error during container init: error mounting "/host/path" to rootfs at "/container/path": no such file or directory: unknown

Главный принцип простой: первые куски строки часто шаблонные и малоинформативны, а реальная зацепка обычно находится ближе к концу. Именно там появляются слова exec, stat, mount, permission denied, apparmor, seccomp, cgroup.

Если видите длинную цепочку из Docker, containerd, shim и runc, не цепляйтесь за самую «страшную» часть текста. Ищите последнюю конкретную причину в конце сообщения — чаще всего она и есть корень проблемы.

Быстрый алгоритм диагностики

Прежде чем что-либо менять, соберите минимум фактов о хосте и контейнере. Это сразу показывает, проблема системная или привязана к одному образу.

1. Проверяем статус Docker и containerd

systemctl status docker --no-pager -l
systemctl status containerd --no-pager -l
journalctl -u docker -n 100 --no-pager
journalctl -u containerd -n 100 --no-pager

Если containerd не запущен, уходит в restart loop или падает при старте, копаться в самом контейнере рано. Сначала нужно вернуть в порядок рантайм.

2. Смотрим полную ошибку запуска

docker ps -a
docker logs CONTAINER_NAME
docker inspect CONTAINER_NAME

docker logs помогает не всегда: процесс может не успеть стартовать вообще. Тогда больше пользы дают docker inspect, системный журнал и точный ответ демона на запуск.

3. Проверяем версии компонентов

docker version
docker info
containerd --version
runc --version
uname -r

Если проблема появилась после обновления системы, первым делом сопоставьте версии ядра, containerd и runc. Такие несовместимости редки, но именно они нередко и вылезают как OCI runtime create failed.

4. Пробуем запустить заведомо простой контейнер

docker run --rm hello-world
docker run --rm alpine:latest uname -a
docker run --rm busybox:latest sh -c 'echo ok'

Если не стартует вообще ничего, проблема системная: Docker, containerd, runc, cgroups, AppArmor, seccomp, storage driver или ядро. Если ломается только один контейнер, то причина почти наверняка в образе, команде запуска, volume, bind mount или параметрах безопасности.

Самая частая причина: no such file or directory

Фраза no such file or directory в сообщении Docker часто читается как «нет файла внутри контейнера». Иногда это так, но на практике за ней скрывается несколько разных сценариев.

Не существует entrypoint или command

Классический случай: в Dockerfile указан ENTRYPOINT или CMD на файл, которого нет в финальном слое образа. Особенно часто это всплывает после правок multi-stage сборки, когда путь изменили, а команду запуска забыли обновить.

docker image inspect IMAGE_NAME
docker run --rm --entrypoint /bin/sh IMAGE_NAME -c 'ls -la /app'

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

docker create --name tmpcheck IMAGE_NAME
docker export tmpcheck | tar -tf - | head
docker rm tmpcheck

Файл есть, но неверный shebang

Скрипт может физически существовать, но всё равно давать no such file or directory. Типичная причина — строка вроде #!/bin/bash в образе, где есть только /bin/sh, либо файл сохранён с Windows-окончаниями строк.

Это особенно коварно: start.sh лежит на месте, имеет +x, но ядро не может найти интерпретатор из shebang. В ответ Docker сообщает ошибку так, будто отсутствует сам файл.

docker run --rm --entrypoint /bin/sh IMAGE_NAME -c 'ls -l /app/start.sh; head -n 1 /app/start.sh; od -An -t x1 -N 32 /app/start.sh'

Если в дампе видны 0d 0a, это CRLF. Файл нужно сохранить в Unix-формате и пересобрать образ.

Нет исходного пути в bind mount

Ещё один частый сценарий — Docker пытается примонтировать путь с хоста, которого не существует. Например, в Compose-файле или команде запуска указан каталог, который есть на одном сервере, но отсутствует на другом.

docker inspect CONTAINER_NAME | grep -A 20 'Mounts'
ls -la /host/path

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

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

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

Подробнее

Когда виноват runc или containerd

Если простые контейнеры тоже не стартуют, а журналы показывают сбои ещё до запуска процесса внутри контейнера, фокус смещается на сам рантайм.

Проверяем бинарники и пакеты

which docker
which containerd
which runc
dpkg -l | grep -E 'docker|containerd|runc'

В Debian и Ubuntu периодически встречаются системы, где после ручной установки пакетов из разных источников оказываются несовместимые версии Docker Engine, containerd и runc. Внешне это легко выглядит как failed to create shim task.

Отдельно проверьте, нет ли старых бинарников в нестандартных путях. Иногда древний runc остаётся в /usr/local/sbin и подхватывается раньше пакетной версии.

Смотрим события containerd

journalctl -u containerd -b --no-pager | tail -n 200

Если в логах всплывают ошибки про shim, runtime v2, невозможность создать task или применить spec, искать нужно уже на стороне containerd и runc. Полезно также сравнить проблемный хост с заведомо рабочим сервером по выводу docker info.

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

Проблемы с cgroups v2 в Debian и Ubuntu

Современные Debian и Ubuntu всё чаще работают с unified hierarchy, то есть с cgroups v2. В штатной конфигурации Docker с этим справляется нормально, но проблемы начинаются, когда старые настройки, нестандартный systemd-конфиг или унаследованные параметры запуска не соответствуют новой модели.

Как понять, что у вас cgroups v2

stat -fc %T /sys/fs/cgroup
docker info | grep -i cgroup
mount | grep cgroup

Если видите cgroup2fs и в docker info фигурирует драйвер systemd, это типичная современная схема. Но если Docker настроен на один драйвер, а система реально живёт по другому сценарию, ошибки применения лимитов CPU, памяти или pids могут возникать ещё до старта процесса.

Что проверить

• Совпадает ли драйвер cgroup у Docker с ожиданиями systemd.

• Не пришли ли в проект устаревшие параметры из старого Compose-файла или CI-шаблона.

• Не используются ли лимиты, которые текущее ядро или runtime не может корректно применить.

docker info

Если ошибка возникает только у контейнеров с лимитами, временно уберите cpus, mem_limit, pids_limit и проверьте, стартует ли контейнер без них. Это быстро сужает область поиска.

AppArmor: контейнер не стартует из-за профиля безопасности

На Ubuntu AppArmor включён по умолчанию и нередко участвует в проблемах запуска контейнеров. На Debian это тоже возможно, особенно если система настраивалась вручную. Иногда ошибка прямо указывает на AppArmor, а иногда Docker показывает общий OCI runtime create failed, а детали видны только в ядре или журнале.

aa-status
journalctl -k -n 100 --no-pager | grep -i apparmor
dmesg | grep -i apparmor

Если профиль повреждён, не загружается или конфликтует с текущим рантаймом, контейнер может не пройти инициализацию. Частый симптом — отказ при монтировании, доступе к специальным файловым системам или запуске конкретного бинарника.

Также проверьте, не запускается ли контейнер с кастомным профилем, который больше не существует на хосте:

docker inspect CONTAINER_NAME | grep -i apparmor -A 5

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

Seccomp и несовместимые системные вызовы

Seccomp — ещё один источник ошибок, которые снаружи выглядят как сбой OCI runtime. Особенно это заметно после обновления ядра, Docker, смены базового образа или запуска нестандартных приложений, которым нужны специфические системные вызовы.

docker info | grep -i seccomp
journalctl -k -n 100 --no-pager | grep -i seccomp

Если у контейнера подключён кастомный seccomp-профиль, проверьте его актуальность. Старый профиль может запрещать вызовы, которые теперь нужны приложению или самому рантайму на этапе инициализации.

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

Права, UID/GID и файловая система хоста

Иногда источник проблемы не в Docker как таковом, а в том, что процесс рантайма не может получить доступ к каталогу, сокету или файлу на хосте. Это может выглядеть как permission denied, но нередко проявляется и более косвенно — через ошибки создания task.

Обычно стоит проверить несколько вещей:

• права на bind mount-каталоги;

• наличие execute-бита на директориях в цепочке пути;

• доступность сокетов, конфигов и секретов;

• не размещён ли Docker data root на проблемной файловой системе.

namei -om /host/path/to/file
ls -la /host/path/to
findmnt
df -h
df -i

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

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Когда проблема в образе, а не в хосте

Очень полезно быстро отделить проблему сервера от проблемы конкретного образа. Если hello-world и alpine стартуют, а ваш контейнер нет, причина почти наверняка в одном из следующих мест:

• неверный ENTRYPOINT или CMD;

• сломанный shebang;

• скрипт без chmod +x;

• отсутствующий файл после multi-stage сборки;

• невалидные bind mounts;

• несовместимый пользователь USER и права на рабочий каталог;

• ожидание бинарника, которого нет в базовом образе.

В такой ситуации полезно временно переопределить entrypoint и посмотреть файловую систему вручную:

docker run --rm -it --entrypoint /bin/sh IMAGE_NAME

Если /bin/sh отсутствует, это уже важный диагностический сигнал: образ минималистичный, и обычные приёмы отладки придётся заменить проверкой через docker export, debug-образ или пересборку Dockerfile.

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

Когда сервис не поднимается после деплоя или перезагрузки сервера, лучше действовать по короткому runbook, а не метаться между логами и переустановкой пакетов.

1. Сохраните точный текст ошибки запуска.

2. Проверьте, стартуют ли простые контейнеры.

3. Сравните поведение проблемного контейнера без лимитов, кастомных профилей и bind mounts.

4. Изучите journalctl для Docker, containerd и ядра.

5. Проверьте версии docker, containerd, runc и ядра.

6. Проверьте пути, права, shebang и наличие файлов в образе.

7. Отдельно проверьте AppArmor, seccomp и конфигурацию cgroups v2.

Такой порядок почти всегда быстрее, чем хаотичные эксперименты.

Что особенно часто ломается после обновлений Debian/Ubuntu

На практике всплеск ошибок failed to create shim task чаще всего случается после одного из таких событий:

• обновили ядро и не перезагрузили хост, получив смешанное состояние;

• обновили Docker, но оставили старый runc или containerd;

• поменяли базовый образ приложения, и в нём исчез /bin/bash;

• перенесли Compose-проект на новый сервер, где нет старых путей и директорий;

• изменили политики AppArmor или seccomp;

• перешли на cgroups v2, но не пересмотрели старые лимиты и параметры запуска.

Если у вас несколько окружений, полезно сравнивать не только Compose-файлы, но и вывод docker info на рабочем и проблемном узле. Разница в драйвере cgroup, storage driver, security options или версии runtime часто объясняет всё быстрее любых догадок.

Итог

Ошибка failed to create shim task в Debian или Ubuntu — это не диагноз, а лишь верхний симптом. То же самое относится к OCI runtime create failed. В большинстве случаев реальная причина лежит в одной из понятных областей: отсутствующий файл, неверный ENTRYPOINT, сломанный shebang, ошибки bind mount, проблемы runc или containerd, конфликты с cgroups v2, AppArmor или seccomp.

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

И главный практический вывод здесь простой: последняя строка ошибки обычно важнее первых трёх.