Cette discussion a commencé par une question sur la désactivation d’un système de fichiers en lecture seule dans ZimaOS, mais ce n’était pas le véritable problème. Après avoir vérifié la pile, l’auteur du message original a découvert que le fichier Compose utilisait des chemins de volumes relatifs.
Cette distinction est importante, car modifier les permissions du système de fichiers hôte ou remonter des chemins système aurait été la mauvaise solution dans ce cas.
Vérifiez le fichier Compose avant de modifier ZimaOS
Lorsqu’une pile de conteneurs ne peut pas créer ou écrire dans un chemin, commencez par identifier ce que le fichier Compose monte dans le conteneur. Un montage lié peut faire référence à un chemin de l’hôte, tandis qu’un volume nommé est géré par Docker. Les règles actuelles des volumes Docker Compose précisent que les chemins relatifs de l’hôte sont résolus à partir de l’emplacement du projet Compose.
Pour un NAS auto-hébergé, un chemin persistant explicite est souvent plus facile à comprendre qu’un chemin relatif ambigu, car vous pouvez vérifier que le répertoire source existe réellement et qu’il est accessible en écriture.
Pourquoi l’hypothèse de la lecture seule était trompeuse
Un véritable problème de système de fichiers en lecture seule affecte généralement plusieurs chemins Compose et doit être diagnostiqué à partir de l’état réel des montages et des journaux système. Dans cette discussion, l’utilisateur n’avait pas besoin de désactiver un mécanisme de protection de ZimaOS. Il a simplement corrigé sa configuration des volumes relatifs.
Ce que la communauté a suggéré
Avant que la cause profonde ne soit connue, une réponse de la communauté suggérait d’ouvrir le mode développeur de ZimaOS, d’utiliser le terminal web en tant que root et de créer manuellement le répertoire requis. Cela peut être utile lorsque le chemin hôte prévu n’existe réellement pas, mais cette étape doit suivre la vérification du chemin Compose et non la remplacer.
Un ordre de dépannage plus sûr
- Examinez chaque entrée
volumes:du fichier Compose. - Déterminez si chaque source est un volume nommé, un chemin absolu de l’hôte ou un chemin relatif.
- Vérifiez que le répertoire hôte attendu existe.
- Vérifiez que le conteneur n’est pas monté explicitement avec
:roouread_only: true. - N’examinez l’état des montages du système de fichiers hôte que si la même erreur d’écriture persiste en dehors de la configuration du conteneur.
Contexte actuel de Docker et Portainer
Pour les déploiements ZimaOS actuels, les exigences matérielles de Portainer fournissent le contexte général concernant la persistance et l’environnement d’exécution de Portainer, tandis que l’article sur la première application Docker explique comment les applications ZimaOS associent les données persistantes aux conteneurs. Si un montage est réellement en lecture seule, plutôt que simplement mal référencé, l’article sur la résolution des problèmes de montages liés Docker distingue un montage :ro configuré d’un système de fichiers hôte qui n’accepte plus les écritures.
Les règles des montages liés Docker confirment que les montages liés peuvent utiliser des chemins sources de l’hôte et que le comportement en lecture seule est contrôlé explicitement avec readonly ou ro. Le fonctionnement officiel des piles Portainer définit une pile Portainer comme un ensemble de services associés, raison pour laquelle il faut examiner le fichier Compose avant de modifier l’hôte ZimaOS lui-même.
En résumé
L’erreur signalée sur la pile Portainer n’a pas été résolue en désactivant un système de fichiers en lecture seule. L’utilisateur a corrigé les chemins de volumes relatifs dans docker-compose.yml. Pour des erreurs similaires de conteneurs ZimaOS, validez la définition des montages Compose avant d’apporter des modifications au système de fichiers de l’hôte.
