Как исправить ошибку Docker “OCI runtime create failed” [Актуальное руководство 2026]

Вы когда-нибудь сталкивались с ошибкой “Error response from daemon: OCI runtime create failed” при попытке запустить контейнер Docker? Эта ошибка указывает на то, что низкоуровневая среда выполнения контейнеров Docker (runc) не смогла запустить контейнер. В этой статье мы подробно объясним причины и конкретные решения этой ошибки на основе самой актуальной информации 2026 года.

Что это за ошибка? Симптомы, которые вы можете наблюдать
Причины этой ошибки
Решение 1: Проверка исполняемых файлов и путей (Рекомендуется)
Решение 2: Устранение проблем SELinux/AppArmor
Решение 3: Обновление Docker/runc и изменения конфигурации (Для продвинутых пользователей)
Как предотвратить эту ошибку
Заключение
Ссылки

Что это за ошибка? Симптомы, которые вы можете наблюдать

Ошибка “OCI runtime create failed” возникает, когда Docker пытается создать и запустить контейнер, используя среду выполнения, совместимую с OCI (Open Container Initiative). OCI — это организация, определяющая отраслевые стандарты для форматов контейнеров и сред выполнения, а Docker использует runc, соответствующий этим стандартам, для управления контейнерами.

При возникновении этой ошибки вы можете наблюдать следующие симптомы:

Контейнеры не запускаются с помощью команды docker run
Службы не запускаются с помощью docker-compose up
В журналах контейнера отображается сообщение “OCI runtime create failed”
Появляются сообщения об ошибках типа “runc create failed: unable to start container process”

Формат сообщения об ошибке обычно выглядит так:

Error response from daemon: OCI runtime create failed: container_linux.go:380: starting container process caused: exec: "python": executable file not found in $PATH: unknown

Эта ошибка может возникнуть в любой среде Docker, включая среды разработки, конвейеры CI/CD и производственные среды, что существенно влияет на разработку и развёртывание приложений на основе контейнеров.

Причины этой ошибки

Существует несколько потенциальных причин ошибки OCI runtime create failed. Ключевая подсказка содержится в части после “caused:” в сообщении об ошибке, поэтому важно сначала проверить полное сообщение об ошибке.

Причина 1: Исполняемый файл не найден

Одна из самых распространённых причин — указанный исполняемый файл или команда не существует внутри контейнера. Эта ошибка возникает, когда команда, указанная в ENTRYPOINT или CMD Dockerfile, не существует в образе контейнера.

Например, если вы попытаетесь выполнить команду python на базовом образе, в котором не установлен Python, вы увидите следующую ошибку:

exec: "python": executable file not found in $PATH

Это часто происходит при использовании лёгких образов, таких как Alpine Linux.

Причина 2: Контроль доступа SELinux/AppArmor

Эта ошибка также может возникнуть, когда модули безопасности, такие как SELinux (Security-Enhanced Linux) или AppArmor, блокируют процессы контейнера или операции монтирования. Это особенно проблематично в следующих ситуациях:

При монтировании каталогов хоста как томов
При доступе к определённым файлам устройств
При запуске контейнеров, требующих привилегированных операций

В средах с включённым SELinux вы можете видеть сообщения об ошибках типа:

write /proc/self/attr/keycreate: permission denied

Причина 3: Проблемы со скриптом точки входа

Ошибки также могут возникать при проблемах с файлами скриптов, такими как entrypoint.sh, указанными в Dockerfile. Основные причины включают:

Файл не скопирован в образ
Неправильный путь к файлу
Не предоставлено разрешение на выполнение
Окончания строк (CRLF) из скриптов, созданных в Windows, не распознаются в Linux

Причина 4: Проблемы с версиями Docker или runc

Эта ошибка может возникнуть, когда версии Docker или runc несовместимы с ядром хостовой ОС. Проблемы особенно часто возникают после обновлений в Proxmox VE и других средах виртуализации. Многие случаи решаются обновлением до Docker 25 или выше.

Причина 5: Проблемы с конфигурацией cgroup

Ошибки также возникают, когда конфигурация cgroup (Control Groups) контейнера несовместима с хостовой системой. Эта проблема часто возникает, особенно в период перехода с cgroupsv1 на cgroupsv2.

Решение 1: Проверка исполняемых файлов и путей (Рекомендуется)

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

Шаг 1: Проверка содержимого образа

Сначала убедитесь, что необходимые команды существуют в проблемном образе:

# Проверка файловой системы в образе
docker run --rm --entrypoint ls myapp:latest /usr/bin/

# Проверка существования конкретной команды
docker run --rm --entrypoint which myapp:latest python

Шаг 2: Модификация Dockerfile

Если исполняемый файл не существует, измените Dockerfile для установки необходимых пакетов:

# Для Alpine Linux
FROM alpine:latest
RUN apk add --no-cache python3 py3-pip

# Для Debian/Ubuntu
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y python3 python3-pip

Шаг 3: Проверка ENTRYPOINT и CMD

Убедитесь, что ENTRYPOINT и CMD правильно настроены в Dockerfile:

# Правильный пример
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["python3", "app.py"]

# Рекомендуется использовать абсолютные пути
ENTRYPOINT ["/usr/local/bin/python3"]

Важные замечания

При использовании shell-скриптов всегда предоставляйте разрешения на выполнение: RUN chmod +x /app/entrypoint.sh
Для скриптов, созданных в Windows, преобразуйте окончания строк с помощью команды dos2unix или обработайте это в Dockerfile

Решение 2: Устранение проблем SELinux/AppArmor

Вот как устранить ошибки, вызванные SELinux или AppArmor.

Проверка статуса SELinux

# Проверка статуса SELinux
sestatus

# Проверка последних журналов отказов SELinux
ausearch -m avc -ts recent

Конфигурация меток для монтирования томов

При монтировании томов в среде SELinux установите соответствующие метки:

# Опция :z (для общих томов)
docker run -v /host/path:/container/path:z myapp:latest

# Опция :Z (для частных томов)
docker run -v /host/path:/container/path:Z myapp:latest

Настройка постоянных меток

Для часто используемых каталогов можно установить постоянные метки SELinux:

# Установка контекста SELinux для контейнеров
chcon -Rt svirt_sandbox_file_t /path/to/volume

Отключение меток SELinux для тестирования

Для целей отладки можно временно отключить метки SELinux:

docker run --security-opt label=disable myapp:latest

Важно: Постоянное отключение SELinux не рекомендуется в производственных средах. Настройте соответствующие политики после полного понимания рисков безопасности.

Решение 3: Обновление Docker/runc и изменения конфигурации (Для продвинутых пользователей)

Решения для проблем с версиями или когда требуется расширенная настройка.

Обновление Docker

Если вы используете старую версию Docker, обновите до последней версии:

# Для Ubuntu/Debian
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Для CentOS/RHEL
sudo yum update docker-ce docker-ce-cli containerd.io

Проверка и обновление версии runc

# Проверка версии runc
runc --version

# Обновление runc отдельно при необходимости
sudo apt-get install runc

Изменение конфигурации systemd

В некоторых средах может потребоваться изменить конфигурацию systemd для Docker:

# Редактирование файла службы Docker
sudo systemctl edit docker.service

# Добавление следующей конфигурации (решает проблемы с MountFlags)
[Service]
MountFlags=shared

# Применение изменений
sudo systemctl daemon-reload
sudo systemctl restart docker

Настройка драйвера cgroup

При проблемах совместимости драйвера cgroup измените конфигурацию демона Docker:

# Редактирование /etc/docker/daemon.json
sudo nano /etc/docker/daemon.json

Добавьте следующее содержимое:

{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

После настройки перезапустите Docker:

sudo systemctl restart docker

Как предотвратить эту ошибку

Вот лучшие практики для предотвращения ошибок OCI runtime create failed.

Лучшие практики Dockerfile

Используйте доверенные базовые образы: Используйте официальные или проверенные образы и убедитесь, что они содержат необходимые зависимости.
Используйте многоэтапные сборки: Избегайте включения ненужных инструментов или файлов в финальный образ.
Явно устанавливайте разрешения на выполнение: Всегда выполняйте chmod +x для файлов скриптов.
Используйте абсолютные пути: Используйте абсолютные пути вместо относительных в ENTRYPOINT и CMD.

Регулярное обслуживание

Поддерживайте Docker и runc в актуальном состоянии: Выполняйте регулярные обновления для получения патчей безопасности и улучшений совместимости.
Удаляйте неиспользуемые образы и контейнеры: Регулярно выполняйте docker system prune для освобождения дискового пространства.
Мониторьте журналы: Регулярно проверяйте системные журналы Docker с помощью journalctl -u docker.

Тестирование перед развёртыванием

Всегда проверяйте, что контейнеры корректно запускаются в локальных или staging-средах перед развёртыванием в production. Также эффективно включить тесты запуска контейнеров в ваш CI/CD-конвейер.

Заключение

Ошибка Docker “OCI runtime create failed” — это распространённая ошибка, указывающая на то, что среда выполнения контейнера не смогла запустить контейнер. Основные причины включают отсутствие исполняемых файлов, контроль доступа SELinux/AppArmor, ошибки конфигурации точки входа, проблемы с версиями Docker/runc и несогласованность конфигурации cgroup.

При устранении неполадок важно сначала проверить часть после “caused:” в сообщении об ошибке, чтобы определить конкретную причину. Во многих случаях проблему можно решить, изменив Dockerfile или добавив опции монтирования тома.

Если проблема сохраняется, попробуйте следующие шаги:

Проверьте более подробную информацию об ошибке с помощью docker logs или journalctl
Поищите похожие проблемы на официальных форумах Docker или Stack Overflow
Рассмотрите возможность обновления версии Docker
Проверьте совместимость между ядром хостовой ОС и Docker

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