Comment résoudre l’erreur Docker “OCI runtime create failed” [Guide mis à jour 2026]

Vous recevez le message “Error response from daemon: OCI runtime create failed” lorsque vous essayez de démarrer un conteneur Docker ? Cet article fournit un guide complet et à jour pour 2026 sur les causes et les solutions spécifiques de cette erreur. Que vous soyez débutant ou utilisateur avancé, ce guide étape par étape vous aidera à résoudre le problème.

Qu’est-ce que cette erreur ? Symptômes que vous rencontrerez
Causes de cette erreur
Solution 1 : Interpréter les messages d’erreur et corriger les problèmes d’exécutables (Recommandé)
Solution 2 : Corriger les permissions et les politiques de sécurité
Solution 3 : Mettre à jour Docker/runc et corriger la configuration cgroup (Avancé)
Comment prévenir cette erreur
Résumé
Références

Qu’est-ce que cette erreur ? Symptômes que vous rencontrerez

L’erreur “OCI runtime create failed” indique que le runtime de conteneurs de bas niveau de Docker, runc, n’a pas pu démarrer le processus du conteneur. OCI (Open Container Initiative) est un organisme industriel qui définit les standards des conteneurs, et Docker utilise un runtime conforme à OCI pour gérer les conteneurs.

Lorsque cette erreur se produit, votre terminal affichera des messages tels que :

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.

Ou :

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

Lorsque cette erreur se produit, votre conteneur ne démarrera pas du tout. La commande docker run renvoie une erreur immédiatement, rendant impossible l’accès à toute application à l’intérieur du conteneur. Cette erreur peut survenir non seulement dans les environnements de développement, mais aussi dans les pipelines CI/CD de production (CircleCI, GitHub Actions, etc.) et les clusters Kubernetes, bloquant complètement les déploiements.

Ce qui rend cette erreur particulièrement frustrante, c’est que le message d’erreur est long et complexe, rendant difficile l’identification de la cause racine au premier coup d’œil. Cependant, l’indice clé est caché dans la partie après “caused:” du message d’erreur. Cet article explique comment lire ces indices et fournit des solutions pour chaque modèle.

Causes de cette erreur

L’erreur “OCI runtime create failed” a cinq causes principales. Comprendre chaque modèle vous aidera à identifier rapidement le problème à partir du message d’erreur.

Cause 1 : Fichier exécutable introuvable (executable file not found in $PATH)

C’est l’une des causes les plus courantes. Elle survient lorsque l’exécutable spécifié dans ENTRYPOINT ou CMD du Dockerfile n’existe pas dans le $PATH de l’image du conteneur. Les cas spécifiques incluent :

Fautes de frappe dans le nom de la commande (par exemple, écrire pytohn au lieu de python)
L’image de base n’inclut pas la commande requise (par exemple, bash n’est pas inclus dans les images alpine)
Oubli de copier les binaires dans l’image finale lors de builds multi-étapes
Configuration incorrecte de WORKDIR empêchant la résolution des chemins de scripts

Cause 2 : Problèmes de permissions (permission denied)

Survient lorsque le processus de démarrage du conteneur n’a pas les permissions d’accès nécessaires aux fichiers ou répertoires. Les cas courants incluent :

Le script d’entrypoint n’a pas les permissions d’exécution (chmod +x)
SELinux ou AppArmor sur la machine hôte bloque l’accès aux fichiers du conteneur
Étiquetage inadéquat des volumes montés par bind
Propriété de fichiers corrompue sous /var/lib/docker

Cause 3 : Versions obsolètes de Docker ou runc

Les anciennes versions de Docker Engine, containerd ou runc peuvent causer des problèmes de compatibilité avec les fonctionnalités récentes du noyau. En particulier, les versions de Docker inférieures à 25 ont été signalées comme problématiques sur les distributions Linux récentes. La compatibilité peut également être rompue après des mises à jour du système d’exploitation hôte (par exemple, Proxmox VE 8.1 à 8.2).

Cause 4 : Problèmes de compatibilité avec cgroup v2

Les distributions Linux récentes (Ubuntu 22.04+, Fedora 31+, etc.) ont cgroup v2 activé par défaut. Les anciennes versions de Docker ou runc qui ne supportent pas cgroup v2 produiront des erreurs comme :

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 nécessite un noyau 4.15 ou supérieur (5.2+ recommandé).

Cause 5 : Épuisement de l’espace disque et conflits de ressources

Lorsque les images et conteneurs Docker épuisent l’espace disque disponible, cette erreur apparaît avec le message no space left on device. Les conflits avec des ports ou répertoires déjà utilisés peuvent également causer cette erreur.

Solution 1 : Interpréter les messages d’erreur et corriger les problèmes d’exécutables (Recommandé)

L’approche la plus importante et efficace est d’interpréter correctement le message d’erreur. Pour cette erreur, la raison spécifique de l’échec est indiquée après caused:.

Étape 1 : Analyser le message d’erreur

D’abord, examinez attentivement le message d’erreur. Voici la structure typique :

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

Dans ce cas, après caused:, il est indiqué exec: "python": executable file not found in $PATH. Cela signifie que la commande “python” n’a pas été trouvée dans le PATH du conteneur.

Étape 2 : Vérifier et corriger le Dockerfile

Si l’erreur est liée aux fichiers exécutables, vérifiez votre Dockerfile :

# Mauvais exemple : l'image alpine n'inclut pas python
FROM alpine:latest
CMD ["python", "app.py"]

# Bon exemple : utiliser l'image officielle Python
FROM python:3.12-slim
COPY app.py /app/
WORKDIR /app
CMD ["python", "app.py"]

Pour les erreurs de bash introuvable (courantes avec les images basées sur Alpine Linux) :

# Mauvais exemple
RUN /bin/bash -c "echo hello"

# Bon exemple : Alpine inclut ash par défaut
RUN /bin/sh -c "echo hello"

# Ou installer bash
RUN apk add --no-cache bash

Étape 3 : Vérifier les fichiers à l’intérieur du conteneur

Vous pouvez lancer l’image de manière interactive pour vérifier l’existence des fichiers :

# Entrer dans le conteneur avec un shell spécifié
docker run --rm -it --entrypoint /bin/sh myimage:latest

# Vérifier les commandes dans PATH
which python
echo $PATH
ls -la /app/

Notes importantes

Si vous utilisez des builds multi-étapes, vérifiez que tous les binaires nécessaires sont copiés dans l’étape finale
Si ENTRYPOINT et CMD sont tous deux configurés, vérifiez comment ils se combinent (forme exec vs forme shell)
Vérifiez que les instructions COPY copient correctement les fichiers et que .dockerignore ne les exclut pas

Solution 2 : Corriger les permissions et les politiques de sécurité

Si le message d’erreur contient “permission denied”, le problème est lié aux permissions ou aux politiques de sécurité.

Accorder les permissions d’exécution au script d’entrypoint

# Accorder les permissions d'exécution localement
chmod +x entrypoint.sh

# Accorder les permissions dans le Dockerfile
COPY entrypoint.sh /app/
RUN chmod +x /app/entrypoint.sh
ENTRYPOINT ["/app/entrypoint.sh"]

Gestion des environnements SELinux

Dans les environnements avec SELinux activé (RHEL, CentOS, Fedora, etc.), les politiques peuvent bloquer l’accès du conteneur aux fichiers de l’hôte.

# Vérifier le statut de SELinux
sestatus

# Vérifier les journaux de refus SELinux
sudo ausearch -m avc -ts recent

# Méthode 1 : Ajouter le suffixe :z ou :Z au montage de volumes (recommandé)
docker run -v /host/data:/container/data:z myapp:latest

# Méthode 2 : Désactiver les étiquettes SELinux pour le débogage (non recommandé en production)
docker run --security-opt label=disable myapp:latest

Le suffixe :z rend le volume partageable entre plusieurs conteneurs, tandis que :Z l’étiquette exclusivement pour ce conteneur. Utilisez toujours :z ou :Z en production et évitez label=disable.

Gestion des environnements AppArmor

Des problèmes similaires peuvent survenir avec AppArmor sur Ubuntu et d’autres systèmes. Notamment, depuis le correctif de sécurité containerd.io 1.7.28-2 en novembre 2025, les erreurs liées à AppArmor ont augmenté lors de l’exécution de Docker à l’intérieur de conteneurs LXC imbriqués.

# Désactiver le profil AppArmor pour le débogage (non recommandé en production)
docker run --security-opt apparmor=unconfined myapp:latest

# Vérifier le statut d'AppArmor
sudo aa-status

Corriger la propriété des fichiers

# Vérifier la propriété de /var/lib/docker
ls -la /var/lib/docker/

# Redémarrer le daemon Docker si nécessaire
sudo systemctl restart docker

Solution 3 : Mettre à jour Docker/runc et corriger la configuration cgroup (Avancé)

Les problèmes de compatibilité de version et de configuration du noyau nécessitent des corrections plus approfondies.

Mettre à jour Docker Engine

La mise à jour vers Docker 25 ou supérieur résout de nombreux problèmes de compatibilité.

# Vérifier la version actuelle de Docker
docker version

# Pour Ubuntu/Debian : mettre à jour depuis le dépôt officiel Docker
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Pour CentOS/RHEL
sudo yum update docker-ce docker-ce-cli containerd.io

Mettre à jour runc séparément

Vous pouvez également mettre à jour runc indépendamment :

# Vérifier la version de runc
runc --version

# Installer la dernière version de runc depuis les releases GitHub
wget https://github.com/opencontainers/runc/releases/download/v1.2.5/runc.amd64
sudo install -m 755 runc.amd64 /usr/local/sbin/runc

Résoudre la compatibilité cgroup v2

Si vous rencontrez des erreurs liées à cgroup v2 :

# Vérifier la version actuelle de cgroup
stat -fc %T /sys/fs/cgroup/
# "cgroup2fs" signifie que v2 est activé

# Vérifier la version du noyau (5.2+ recommandé)
uname -r

Méthode A : Modifier la configuration du daemon Docker

# Éditer /etc/docker/daemon.json
sudo tee /etc/docker/daemon.json <<EOF
{
  "default-cgroupns-mode": "host",
  "exec-opts": ["native.cgroupdriver=systemd"]
}
EOF

# Redémarrer Docker
sudo systemctl daemon-reload
sudo systemctl restart docker

Méthode B : Revenir à cgroup v1 (non recommandé mais efficace en urgence)

Ajoutez ce qui suit aux paramètres de démarrage GRUB pour forcer cgroup v1 :

# Éditer /etc/default/grub
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=0"

# Mettre à jour GRUB et redémarrer
sudo update-grub
sudo reboot

Vérifier et libérer l’espace disque

# Vérifier l'espace disque utilisé par Docker
docker system df

# Supprimer toutes les images, conteneurs et volumes inutilisés
docker system prune -a --volumes

# Supprimer les images pendantes
docker image prune

Vérifier la configuration du service systemd

Dans certains environnements, la configuration du fichier d’unité systemd de Docker peut causer des problèmes :

# Vérifier le fichier d'unité du service Docker
sudo systemctl cat docker.service

# Si MountFlags=slave est configuré, le supprimer
sudo systemctl edit docker.service
# [Service]
# MountFlags=

# Appliquer les changements
sudo systemctl daemon-reload
sudo systemctl restart docker

Comment prévenir cette erreur

Suivez ces bonnes pratiques pour prévenir l’erreur “OCI runtime create failed”.

1. Suivre les bonnes pratiques Dockerfile

Utiliser des images officielles comme base
Dans les builds multi-étapes, vérifier que l’étape finale contient tous les fichiers nécessaires
Comprendre et utiliser correctement la différence entre ENTRYPOINT et CMD
Configurer correctement le fichier .dockerignore

2. Tester minutieusement en local

# Tester que l'image construite démarre correctement
docker build -t myapp:test .
docker run --rm myapp:test

3. Maintenir l’environnement Docker à jour

Mettez régulièrement à jour Docker Engine, containerd et runc. Appliquez rapidement les mises à jour mineures contenant des correctifs de sécurité.

4. Surveiller l’espace disque régulièrement

# Vérifier périodiquement l'utilisation du disque
docker system df
# Nettoyage régulier des ressources inutilisées
docker system prune -f --filter "until=168h"

5. Fixer les versions de Docker dans les pipelines CI/CD

Lors de l’utilisation de Docker en CI/CD, fixez la version de Docker pour prévenir les problèmes de compatibilité inattendus.

Résumé

L’erreur “OCI runtime create failed” de Docker peut sembler complexe, mais en lisant attentivement la partie après caused: dans le message d’erreur, identifier la cause racine est relativement simple.

Points clés :

Exécutable introuvable → Vérifiez ENTRYPOINT/CMD dans votre Dockerfile et spécifiez le bon chemin et la bonne commande
Erreurs de permissions → Vérifiez les permissions d’exécution du script et les paramètres SELinux/AppArmor
Problèmes de compatibilité de version → Mettez à jour Docker, runc et le noyau vers la dernière version
Problèmes liés à cgroup → Ajustez les paramètres cgroup dans daemon.json
Problèmes d’espace disque → Nettoyez les ressources inutiles avec docker system prune

Si les méthodes de cet article ne résolvent pas votre problème, essayez :

Publier une question sur Docker Community Forums (forums.docker.com)
Rechercher des issues sur le dépôt GitHub moby/moby
Poser une question sur Stack Overflow avec la sortie de docker info et docker version

Copier le message d’erreur complet et le rechercher est le premier pas le plus efficace vers la résolution.