Cette source contient plusieurs pannes survenues à peu d’intervalle ; elle ne doit donc pas être réécrite comme un simple « bug de Portainer ». Le disque système avait presque entièrement manqué d’espace libre, Docker et containerd ont été mis à niveau vers de nouvelles versions majeures via Debian, un ancien test de l’interface de ligne de commande Docker a été rejeté par le daemon Docker 29, Portainer a perdu son environnement Local, CasaOS continuait d’afficher « chargement des applications » et un problème de démarrage ultérieur a donné au tableau de bord une apparence presque identique à celle d’une nouvelle installation.
Aucune réponse de la source ne confirme une cause racine définitive. L’interprétation la plus prudente est celle d’un problème de récupération à plusieurs niveaux : préserver d’abord les données existantes, puis déterminer quel disque de démarrage et quel système de fichiers racine sont actifs, vérifier si la racine de données Docker existe toujours, si le daemon fonctionne correctement et si Portainer/CasaOS sont compatibles avec l’API Docker mise à niveau.
Le disque système était déjà soumis à une forte pression d’espace
L’utilisateur ne disposait que d’environ 1 Go d’espace libre sur un système de fichiers racine de 27 Go avant le nettoyage. Les principaux consommateurs comprenaient les données de superposition Docker, les métadonnées de Jellyfin, les journaux système et les paquets de développement.
Un espace libre insuffisant peut entraîner un comportement imprévisible des opérations sur les images et conteneurs Docker, des bases de données, des journaux et des services CasaOS. Libérer de l’espace était nécessaire, indépendamment du problème ultérieur lié à l’API Docker.
La mise à niveau de l’hôte a fait passer Docker de la version 28.x à la version 29.0.0
L’historique des paquets Debian indiquait la mise à niveau des éléments suivants :
-
docker-ce; -
docker-ce-cli; -
containerd.io; - les composants supplémentaires Docker sans privilèges.
Une mise à niveau majeure de Docker Engine peut révéler des problèmes de compatibilité dans les outils de gestion qui intègrent ou négocient d’anciennes versions de l’API.
La source a relevé une véritable incompatibilité de versions de l’API Docker
Un conteneur utilisant l’interface de ligne de commande Docker 24.0.5 a renvoyé :
client version 1.43 is too old.
Minimum supported API version is 1.44Ce message prouve directement qu’au moins un ancien client ne pouvait plus communiquer avec le daemon Docker mis à niveau. Il ne prouve pas à lui seul que Portainer utilisait exactement cette version du client, mais il fait de la compatibilité de l’API une vérification prioritaire.
Le fait que Portainer indique que Local est actif, puis le fasse disparaître, est un symptôme de la couche de gestion
La source a tenté de recréer un environnement Docker local en utilisant /var/run/docker.sock, sans succès. Avant de supprimer l’état de Portainer, vérifiez :
docker info
docker ps
ls -l /var/run/docker.sockSi l’interface de ligne de commande Docker fonctionne mais que Portainer ne fonctionne pas, concentrez-vous sur la version de Portainer, la compatibilité de l’API et l’accès au socket. Si Docker lui-même échoue, corrigez d’abord le daemon.
« Chargement des applications » dans CasaOS indique que la panne dépassait probablement Portainer
CasaOS rencontrait également des difficultés à répertorier les applications. Cela peut se produire si Docker est indisponible, si l’API Docker a changé de manière incompatible, si la racine de données Docker est absente ou si l’hôte démarré ne correspond plus à l’état système attendu.
L’événement ultérieur « Sélectionnez le périphérique de démarrage approprié » modifie les priorités de récupération
Après un redémarrage, la machine a cessé de démarrer normalement jusqu’à ce que l’utilisateur modifie la sélection de démarrage. Une fois le système revenu, CasaOS n’avait plus aucune application, même si le gros disque dur restait connecté.
Cela laisse penser qu’un autre disque de démarrage ou système de fichiers racine a peut-être été sélectionné, ou que la partition ou l’état du système a changé. La source ne permet pas de déterminer lequel.
Préservez les données d’application avant de réinstaller CasaOS
Les éléments les plus importants pour l’utilisateur étaient :
-
les fichiers de projet dans
/home/casaos; - les métadonnées de Jellyfin dans AppData ;
- les fichiers multimédias sur le disque dur ;
- la configuration Docker/CasaOS, lorsqu’elle peut être récupérée.
Copiez ces dossiers persistants vers un autre disque ou système avant de réinstaller ou de réinitialiser Docker. Recréer les conteneurs est généralement plus simple que recréer les bases de données et les métadonnées des applications.
N’effectuez pas de nettoyage Docker agressif avant de savoir ce qui est encore référencé
La suppression des images inutilisées peut libérer de l’espace, mais la suppression des volumes ou des répertoires de la racine de données peut supprimer l’état des applications que vous essayez de sauvegarder. Identifiez d’abord les conteneurs, les volumes, les montages liés et les chemins AppData.
Considérez les mises à jour Debian et Docker comme faisant partie de la plateforme CasaOS
CasaOS repose sur l’hôte Linux sous-jacent. Une commande apt upgrade globale peut mettre à jour Docker, le noyau, systemd, le réseau et les paquets de stockage dont dépend CasaOS. Testez volontairement les mises à niveau majeures de l’hôte et conservez une sauvegarde du système et des applications avant de les appliquer à un NAS fonctionnel.
FAQ sur la récupération de Portainer/CasaOS
La source prouve-t-elle que Docker 29 est à lui seul à l’origine de toutes les pannes ?
Non. Le système était également presque plein et a ensuite rencontré un problème lié au périphérique ou à l’état de démarrage.
Une incompatibilité de l’API Docker a-t-elle été confirmée ?
Oui. Une interface de ligne de commande Docker 24 utilisant l’API 1.43 a été rejetée, car le daemon Docker 29 exigeait au minimum la version 1.44.
L’utilisateur doit-il réinstaller CasaOS avant de copier les données AppData ?
Non. Préservez d’abord les données AppData importantes, les fichiers du répertoire personnel et les fichiers multimédias lorsque les disques restent accessibles.
