Comment Résoudre l’Erreur Docker “OCI runtime create failed” [Guide Actualisé 2026]

Avez-vous déjà rencontré l’erreur “Error response from daemon: OCI runtime create failed” en essayant de démarrer un conteneur Docker ? Cette erreur indique que le runtime de bas niveau de Docker (runc) n’a pas réussi à démarrer le conteneur. Dans cet article, nous expliquerons en détail les causes et les solutions spécifiques pour cette erreur basées sur les informations les plus récentes de 2026.

Qu’est-ce que cette erreur ? Symptômes que vous pouvez rencontrer
Causes de cette erreur
Solution 1 : Vérifier les exécutables et les chemins (Recommandé)
Solution 2 : Traiter les problèmes SELinux/AppArmor
Solution 3 : Mise à jour de Docker/runc et modifications de configuration (Avancé)
Comment prévenir cette erreur
Résumé
Références

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

L’erreur “OCI runtime create failed” se produit lorsque Docker tente de créer et de démarrer un conteneur en utilisant un runtime conforme à OCI (Open Container Initiative). OCI est une organisation qui définit les standards de l’industrie pour les formats de conteneurs et les runtimes, et Docker utilise runc, qui est conforme à ces standards, pour gérer les conteneurs.

Lorsque cette erreur se produit, vous pouvez rencontrer les symptômes suivants :

Les conteneurs ne démarrent pas avec la commande docker run
Les services ne démarrent pas avec docker-compose up
Les journaux du conteneur affichent le message “OCI runtime create failed”
Des messages d’erreur comme “runc create failed: unable to start container process” apparaissent

Le format du message d’erreur ressemble généralement à ceci :

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

Cette erreur peut se produire dans n’importe quel environnement Docker, y compris les environnements de développement, les pipelines CI/CD et les environnements de production, impactant significativement le développement et le déploiement d’applications basées sur des conteneurs.

Causes de cette erreur

Il existe plusieurs causes potentielles pour l’erreur OCI runtime create failed. L’indice clé est contenu dans la partie après “caused:” dans le message d’erreur, il est donc important de vérifier d’abord le message d’erreur complet.

Cause 1 : Exécutable non trouvé

L’une des causes les plus courantes est que l’exécutable ou la commande spécifié n’existe pas dans le conteneur. Cette erreur se produit lorsque la commande spécifiée dans ENTRYPOINT ou CMD du Dockerfile n’existe pas dans l’image du conteneur.

Par exemple, si vous essayez d’exécuter la commande python sur une image de base qui n’a pas Python installé, vous verrez l’erreur suivante :

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

Cela se produit fréquemment lors de l’utilisation d’images légères comme Alpine Linux.

Cause 2 : Contrôle d’accès SELinux/AppArmor

Cette erreur peut également se produire lorsque des modules de sécurité comme SELinux (Security-Enhanced Linux) ou AppArmor bloquent les processus du conteneur ou les opérations de montage. C’est particulièrement problématique dans les situations suivantes :

Lors du montage de répertoires hôtes en tant que volumes
Lors de l’accès à des fichiers de périphériques spécifiques
Lors de l’exécution de conteneurs nécessitant des opérations privilégiées

Dans les environnements avec SELinux activé, vous pouvez voir des messages d’erreur comme :

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

Cause 3 : Problèmes de script d’entrée

Des erreurs peuvent également se produire lorsqu’il y a des problèmes avec des fichiers de script comme entrypoint.sh spécifiés dans le Dockerfile. Les causes principales incluent :

Fichier non copié dans l’image
Chemin de fichier incorrect
Permission d’exécution non accordée
Fins de ligne (CRLF) des scripts créés sous Windows non reconnues sous Linux

Cause 4 : Problèmes de version Docker ou runc

Cette erreur peut se produire lorsque les versions de Docker ou runc sont incompatibles avec le noyau du système d’exploitation hôte. Des problèmes ont été particulièrement signalés après des mises à niveau dans Proxmox VE et d’autres environnements de virtualisation. De nombreux cas sont résolus en passant à Docker 25 ou supérieur.

Cause 5 : Problèmes de configuration cgroup

Des erreurs se produisent également lorsque la configuration cgroup (Control Groups) du conteneur est incompatible avec le système hôte. Ce problème est fréquemment signalé, surtout pendant la période de transition de cgroupsv1 à cgroupsv2.

Solution 1 : Vérifier les exécutables et les chemins (Recommandé)

La solution la plus efficace à essayer en premier est de vérifier les exécutables et les chemins à l’intérieur du conteneur.

Étape 1 : Vérifier le contenu de l’image

Tout d’abord, vérifiez que les commandes nécessaires existent dans l’image problématique :

# Vérifier le système de fichiers dans l'image
docker run --rm --entrypoint ls myapp:latest /usr/bin/

# Vérifier si une commande spécifique existe
docker run --rm --entrypoint which myapp:latest python

Étape 2 : Modifier le Dockerfile

Si l’exécutable n’existe pas, modifiez le Dockerfile pour installer les packages nécessaires :

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

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

Étape 3 : Vérifier ENTRYPOINT et CMD

Vérifiez que ENTRYPOINT et CMD sont correctement configurés dans le Dockerfile :

# Exemple correct
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["python3", "app.py"]

# L'utilisation de chemins absolus est recommandée
ENTRYPOINT ["/usr/local/bin/python3"]

Notes importantes

Lors de l’utilisation de scripts shell, accordez toujours les permissions d’exécution : RUN chmod +x /app/entrypoint.sh
Pour les scripts créés sous Windows, convertissez les fins de ligne en utilisant la commande dos2unix ou gérez-le dans le Dockerfile

Solution 2 : Traiter les problèmes SELinux/AppArmor

Voici comment traiter les erreurs causées par SELinux ou AppArmor.

Vérifier l’état de SELinux

# Vérifier l'état de SELinux
sestatus

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

Configuration des labels pour les montages de volumes

Lors du montage de volumes dans des environnements SELinux, définissez les labels appropriés :

# Option :z (pour les volumes partagés)
docker run -v /host/path:/container/path:z myapp:latest

# Option :Z (pour les volumes privés)
docker run -v /host/path:/container/path:Z myapp:latest

Configuration de labels persistants

Pour les répertoires fréquemment utilisés, vous pouvez définir des labels SELinux persistants :

# Définir le contexte SELinux pour les conteneurs
chcon -Rt svirt_sandbox_file_t /path/to/volume

Désactiver les labels SELinux pour les tests

À des fins de dépannage, vous pouvez temporairement désactiver les labels SELinux :

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

Important : Désactiver définitivement SELinux n’est pas recommandé dans les environnements de production. Configurez des politiques appropriées après avoir pleinement compris les risques de sécurité.

Solution 3 : Mise à jour de Docker/runc et modifications de configuration (Avancé)

Solutions pour les problèmes de version ou lorsqu’une configuration avancée est nécessaire.

Mettre à jour Docker

Si vous utilisez une ancienne version de Docker, mettez à jour vers la dernière version :

# Pour Ubuntu/Debian
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

Vérifier et mettre à jour la version de runc

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

# Mettre à jour runc séparément si nécessaire
sudo apt-get install runc

Modifier la configuration systemd

Dans certains environnements, vous devrez peut-être modifier la configuration systemd de Docker :

# Éditer le fichier de service Docker
sudo systemctl edit docker.service

# Ajouter la configuration suivante (résout les problèmes de MountFlags)
[Service]
MountFlags=shared

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

Configurer le pilote cgroup

S’il y a des problèmes de compatibilité du pilote cgroup, modifiez la configuration du démon Docker :

# Éditer /etc/docker/daemon.json
sudo nano /etc/docker/daemon.json

Ajoutez le contenu suivant :

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

Après la configuration, redémarrez Docker :

sudo systemctl restart docker

Comment prévenir cette erreur

Voici les meilleures pratiques pour prévenir les erreurs OCI runtime create failed.

Meilleures pratiques Dockerfile

Utilisez des images de base fiables : Utilisez des images officielles ou vérifiées et assurez-vous qu’elles contiennent les dépendances nécessaires.
Utilisez des builds multi-étapes : Évitez d’inclure des outils ou fichiers inutiles dans l’image finale.
Définissez explicitement les permissions d’exécution : Exécutez toujours chmod +x sur les fichiers de script.
Utilisez des chemins absolus : Utilisez des chemins absolus plutôt que relatifs dans ENTRYPOINT et CMD.

Maintenance régulière

Maintenez Docker et runc à jour : Effectuez des mises à jour régulières pour les correctifs de sécurité et les améliorations de compatibilité.
Supprimez les images et conteneurs inutilisés : Exécutez régulièrement docker system prune pour libérer de l’espace disque.
Surveillez les journaux : Vérifiez régulièrement les journaux système Docker avec journalctl -u docker.

Tests pré-déploiement

Vérifiez toujours que les conteneurs démarrent correctement dans des environnements locaux ou de staging avant de déployer en production. Il est également efficace d’intégrer des tests de démarrage de conteneurs dans votre pipeline CI/CD.

Résumé

L’erreur Docker “OCI runtime create failed” est une erreur courante indiquant que le runtime du conteneur n’a pas pu démarrer le conteneur. Les causes principales incluent des exécutables manquants, le contrôle d’accès SELinux/AppArmor, des erreurs de configuration d’entrypoint, des problèmes de version Docker/runc et des incohérences de configuration cgroup.

Lors du dépannage, il est important de vérifier d’abord la partie après “caused:” dans le message d’erreur pour identifier la cause spécifique. Dans de nombreux cas, le problème peut être résolu en modifiant le Dockerfile ou en ajoutant des options de montage de volume.

Si le problème persiste, essayez les étapes suivantes :

Vérifiez des informations d’erreur plus détaillées avec docker logs ou journalctl
Recherchez des problèmes similaires sur les forums officiels Docker ou Stack Overflow
Envisagez de mettre à jour votre version de Docker
Vérifiez la compatibilité entre le noyau du système d’exploitation hôte et Docker

La technologie des conteneurs évolue quotidiennement, et de nombreux problèmes sont résolus dans les nouvelles versions. Maintenez un environnement de conteneurs stable grâce à des mises à jour régulières et une gestion appropriée de la configuration.