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

Вы получаете сообщение “Error response from daemon: OCI runtime create failed” при попытке запустить контейнер Docker? Эта статья предоставляет полное и актуальное руководство на 2026 год о причинах и конкретных решениях этой ошибки. Независимо от того, новичок вы или опытный пользователь, это пошаговое руководство поможет вам решить проблему.

Что это за ошибка? Симптомы, с которыми вы столкнётесь
Причины этой ошибки
Решение 1: Чтение сообщений об ошибках и исправление проблем с исполняемыми файлами (Рекомендуется)
Решение 2: Исправление прав доступа и политик безопасности
Решение 3: Обновление Docker/runc и исправление настроек cgroup (Продвинутый уровень)
Как предотвратить эту ошибку
Итоги
Ссылки

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

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

Когда возникает эта ошибка, в терминале отображаются сообщения вроде:

docker: 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.

Или:

Error response from daemon: failed to create shim: OCI runtime create failed:
runc create failed: unable to start container process: error during container init:
error mounting "proc" to rootfs at "/proc": permission denied

Когда возникает эта ошибка, ваш контейнер вообще не запустится. Команда docker run немедленно возвращает ошибку, делая невозможным доступ к любому приложению внутри контейнера. Эта ошибка может возникнуть не только в среде разработки, но и в CI/CD конвейерах продакшена (CircleCI, GitHub Actions и т.д.) и кластерах Kubernetes, полностью блокируя развертывание.

Что делает эту ошибку особенно раздражающей — сообщение об ошибке длинное и сложное, что затрудняет определение первопричины с первого взгляда. Однако ключевая подсказка скрыта в части после “caused:” в сообщении об ошибке. Эта статья объясняет, как читать эти подсказки и предоставляет решения для каждого шаблона.

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

Ошибка “OCI runtime create failed” имеет пять основных причин. Понимание каждого шаблона поможет вам быстро определить проблему по сообщению об ошибке.

Причина 1: Исполняемый файл не найден (executable file not found in $PATH)

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

Опечатки в имени команды (например, pytohn вместо python)
Базовый образ не содержит нужную команду (например, bash отсутствует в образах alpine)
Забытое копирование бинарных файлов в финальный образ при многоступенчатой сборке
Неправильная настройка WORKDIR, препятствующая разрешению путей скриптов

Причина 2: Проблемы с правами доступа (permission denied)

Возникает, когда процесс запуска контейнера не имеет необходимых прав доступа к файлам или каталогам. Типичные случаи включают:

Скрипт точки входа не имеет прав на выполнение (chmod +x)
SELinux или AppArmor на хост-машине блокирует доступ контейнера к файлам
Неправильная маркировка томов, подключённых через bind mount
Повреждённое право собственности на файлы в /var/lib/docker

Причина 3: Устаревшие версии Docker или runc

Старые версии Docker Engine, containerd или runc могут вызывать проблемы совместимости с новейшими функциями ядра. В частности, версии Docker ниже 25 были зарегистрированы как проблемные в последних дистрибутивах Linux. Совместимость также может нарушиться после обновления ОС хоста (например, Proxmox VE 8.1 до 8.2).

Причина 4: Проблемы совместимости с cgroup v2

Последние дистрибутивы Linux (Ubuntu 22.04+, Fedora 31+ и т.д.) имеют cgroup v2, включённый по умолчанию. Старые версии Docker или runc, не поддерживающие cgroup v2, будут выдавать ошибки вроде:

OCI runtime create failed: runc create failed: unable to start container process:
error during container init: error setting cgroup config for procHooks process

cgroup v2 требует ядро 4.15 или выше (рекомендуется 5.2+).

Причина 5: Нехватка дискового пространства и конфликты ресурсов

Когда образы и контейнеры Docker исчерпывают доступное дисковое пространство, эта ошибка появляется с сообщением no space left on device. Конфликты с уже используемыми портами или каталогами также могут вызвать эту ошибку.

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

Наиболее важный и эффективный подход — точно прочитать и интерпретировать сообщение об ошибке. Для этой ошибки конкретная причина сбоя указана после caused:.

Шаг 1: Проанализировать сообщение об ошибке

Сначала внимательно изучите сообщение об ошибке. Вот типичная структура:

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

В данном случае после caused: указано exec: "python": executable file not found in $PATH. Это означает, что команда “python” не была найдена в PATH контейнера.

Шаг 2: Проверить и исправить Dockerfile

Если ошибка связана с исполняемыми файлами, проверьте свой Dockerfile:

# Плохой пример: образ alpine не включает python
FROM alpine:latest
CMD ["python", "app.py"]

# Хороший пример: использовать официальный образ Python
FROM python:3.12-slim
COPY app.py /app/
WORKDIR /app
CMD ["python", "app.py"]

Для ошибок, когда bash не найден (часто в образах на базе Alpine Linux):

# Плохой пример
RUN /bin/bash -c "echo hello"

# Хороший пример: Alpine включает ash по умолчанию
RUN /bin/sh -c "echo hello"

# Или установить bash
RUN apk add --no-cache bash

Шаг 3: Проверить файлы внутри контейнера

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

# Войти в контейнер с указанной оболочкой
docker run --rm -it --entrypoint /bin/sh myimage:latest

# Проверить команды в PATH
which python
echo $PATH
ls -la /app/

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

При использовании многоступенчатой сборки убедитесь, что все необходимые бинарные файлы скопированы в финальную стадию
Если установлены и ENTRYPOINT, и CMD, проверьте, как они комбинируются (форма exec vs форма shell)
Убедитесь, что инструкции COPY правильно копируют файлы и .dockerignore не исключает их

Решение 2: Исправление прав доступа и политик безопасности

Если сообщение об ошибке содержит “permission denied”, проблема связана с правами доступа или политиками безопасности.

Предоставить права на выполнение скрипту точки входа

# Предоставить права на выполнение локально
chmod +x entrypoint.sh

# Предоставить права в Dockerfile
COPY entrypoint.sh /app/
RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

Работа с окружениями SELinux

В окружениях с включённым SELinux (RHEL, CentOS, Fedora и т.д.) политики могут блокировать доступ контейнера к файлам хоста.

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

# Проверить журналы отказов SELinux
sudo ausearch -m avc -ts recent

# Метод 1: Добавить суффикс :z или :Z при монтировании томов (рекомендуется)
docker run -v /host/data:/container/data:z myapp:latest

# Метод 2: Отключить метки SELinux для отладки (не рекомендуется для продакшена)
docker run --security-opt label=disable myapp:latest

Суффикс :z делает том доступным для нескольких контейнеров, а :Z маркирует его исключительно для этого контейнера. Всегда используйте :z или :Z в продакшене и избегайте label=disable.

Работа с окружениями AppArmor

Аналогичные проблемы могут возникнуть с AppArmor в Ubuntu и других системах. Примечательно, что с момента выхода патча безопасности containerd.io 1.7.28-2 в ноябре 2025 года количество ошибок, связанных с AppArmor, увеличилось при запуске Docker внутри вложенных контейнеров LXC.

# Отключить профиль AppArmor для отладки (не рекомендуется для продакшена)
docker run --security-opt apparmor=unconfined myapp:latest

# Проверить статус AppArmor
sudo aa-status

Исправить владение файлами

# Проверить владение /var/lib/docker
ls -la /var/lib/docker/

# Перезапустить демон Docker при необходимости
sudo systemctl restart docker

Решение 3: Обновление Docker/runc и исправление настроек cgroup (Продвинутый уровень)

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

Обновить Docker Engine

Обновление до Docker 25 или выше решает многие проблемы совместимости.

# Проверить текущую версию Docker
docker version

# Для Ubuntu/Debian: обновить из официального репозитория Docker
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
runc --version

# Установить последнюю версию runc из релизов GitHub
wget https://github.com/opencontainers/runc/releases/download/v1.2.5/runc.amd64
sudo install -m 755 runc.amd64 /usr/local/sbin/runc

Решить проблемы совместимости с cgroup v2

Если вы сталкиваетесь с ошибками, связанными с cgroup v2:

# Проверить текущую версию cgroup
stat -fc %T /sys/fs/cgroup/
# "cgroup2fs" означает, что v2 включён

# Проверить версию ядра (рекомендуется 5.2+)
uname -r

Метод A: Изменить конфигурацию демона Docker

# Отредактировать /etc/docker/daemon.json
sudo tee /etc/docker/daemon.json <<EOF
{
  "default-cgroupns-mode": "host",
  "exec-opts": ["native.cgroupdriver=systemd"]
}
EOF

# Перезапустить Docker
sudo systemctl daemon-reload
sudo systemctl restart docker

Метод B: Откатиться на cgroup v1 (не рекомендуется, но эффективно в экстренных случаях)

Добавьте следующее в параметры загрузки GRUB для принудительного использования cgroup v1:

# Отредактировать /etc/default/grub
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

# Обновить GRUB и перезагрузить
sudo update-grub
sudo reboot

Проверить и освободить дисковое пространство

# Проверить дисковое пространство, используемое Docker
docker system df

# Удалить все неиспользуемые образы, контейнеры и тома
docker system prune -a --volumes

# Удалить висящие образы
docker image prune

Проверить конфигурацию сервиса systemd

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

# Проверить unit-файл сервиса Docker
sudo systemctl cat docker.service

# Если установлен MountFlags=slave, удалите его
sudo systemctl edit docker.service
# [Service]
# MountFlags=

# Применить изменения
sudo systemctl daemon-reload
sudo systemctl restart docker

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

Следуйте этим лучшим практикам для предотвращения ошибки “OCI runtime create failed”.

1. Следовать лучшим практикам Dockerfile

Использовать официальные образы в качестве базы
При многоступенчатой сборке убедиться, что финальная стадия содержит все необходимые файлы
Понимать и правильно использовать разницу между ENTRYPOINT и CMD
Правильно настроить файл .dockerignore

2. Тщательно тестировать локально

# Протестировать, что собранный образ корректно запускается
docker build -t myapp:test .
docker run --rm myapp:test

3. Поддерживать Docker-окружение в актуальном состоянии

Регулярно обновляйте Docker Engine, containerd и runc. Оперативно применяйте минорные обновления, содержащие патчи безопасности.

4. Регулярно мониторить дисковое пространство

# Периодически проверять использование диска
docker system df
# Регулярная очистка неиспользуемых ресурсов
docker system prune -f --filter "until=168h"

5. Фиксировать версии Docker в CI/CD конвейерах

При использовании Docker в CI/CD фиксируйте версию Docker для предотвращения неожиданных проблем совместимости.

Итоги

Ошибка Docker “OCI runtime create failed” может выглядеть сложной, но при внимательном чтении части после caused: в сообщении об ошибке определение первопричины становится относительно простым.

Ключевые выводы:

Исполняемый файл не найден → Проверьте ENTRYPOINT/CMD в Dockerfile и укажите правильный путь и команду
Ошибки прав доступа → Проверьте права на выполнение скрипта и настройки SELinux/AppArmor
Проблемы совместимости версий → Обновите Docker, runc и ядро до последней версии
Проблемы с cgroup → Настройте параметры cgroup в daemon.json
Проблемы с дисковым пространством → Очистите ненужные ресурсы с помощью docker system prune

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

Опубликовать вопрос на Docker Community Forums (forums.docker.com)
Поискать issues в репозитории GitHub moby/moby
Задать вопрос на Stack Overflow с выводом docker info и docker version

Скопировать полное сообщение об ошибке и искать по нему — самый эффективный первый шаг к решению.