Pourquoi /root/.cache est en lecture seule sur ZimaOS
L’erreur mkdir /root/.cache: read-only file system indique que ZimaOS traite une grande partie du système de fichiers de l’hôte comme étant gérée par l’appliance et en lecture seule. Dans le fil de discussion d’origine, une réponse officielle précisait explicitement que la plupart des dossiers système restent en lecture seule, même lorsque vous êtes connecté en tant que root, pour des raisons de sécurité.
Cette conception se reflète également dans le guide du gestionnaire de paquets de ZimaOS actuel ainsi que dans le guide des bibliothèques externes Immich sur ZimaOS associé.
Ne contournez pas ce problème en forçant l’écriture dans /root
Pour une application conteneurisée, la meilleure solution consiste généralement à placer les données de cache ou de configuration modifiables dans un répertoire persistant de données d’application, puis à le monter dans le conteneur. Pour un outil autonome tel qu’immich-go, définissez le chemin du cache ou du répertoire personnel sur un emplacement accessible en écriture au lieu de modifier la structure immuable de l’hôte.
Utilisez les chemins des conteneurs avec discernement
Les montages bind Docker associent un chemin hôte accessible en écriture au chemin attendu par l’application dans le conteneur. La documentation officielle de Docker sur les montages bind explique leur fonctionnement ainsi que leurs implications en matière de sécurité.
Pour Immich en particulier, les dossiers de photos existants peuvent être montés en lecture seule lorsque l’objectif est l’indexation plutôt que la modification. La documentation Immich sur les bibliothèques externes actuelle constitue la source de référence.
Une méthode plus sûre pour immich-go
- Créez ou choisissez un répertoire utilisateur/de données d’application accessible en écriture, géré en dehors des chemins système protégés.
- Lorsque cette possibilité est prise en charge, définissez la variable d’environnement ou l’option de commande du cache/de la configuration de l’outil sur cet emplacement.
- Si vous l’exécutez dans un conteneur, montez ce chemin accessible en écriture dans le répertoire de cache attendu.
- Montez la bibliothèque de photos source en lecture seule, sauf si le flux de travail doit volontairement modifier les originaux.
- Effectuez un test sur un petit ensemble de photos avant de traiter toute la bibliothèque.
Pourquoi l’accès root ne signifie pas que tous les chemins sont accessibles en écriture
Sur un système d’exploitation d’appliance, les privilèges root et la possibilité de modifier le système de fichiers sont deux contrôles distincts. Un shell root peut donc rencontrer un montage en lecture seule. Il est parfois possible de remonter les partitions système en lecture-écriture dans certains environnements Linux, mais cela peut compromettre les mécanismes de mise à jour et de récupération. Cette solution ne doit donc pas être privilégiée ici.
FAQ
L’erreur indique-t-elle que le disque est défectueux ?
Pas nécessairement. Dans ce cas communautaire, il s’agissait d’un chemin système volontairement configuré en lecture seule, et non d’un signe de défaillance du périphérique de stockage.
Puis-je utiliser /media pour les données d’application ?
Utilisez les chemins de stockage que ZimaOS expose pour vos disques gérés et mappez-les délibérément dans les conteneurs. Vérifiez la propriété et les permissions avant de déplacer l’état de l’application.
Dois-je remonter le système de fichiers racine en lecture-écriture ?
Pas comme solution habituelle. Préférez un chemin accessible en écriture destiné aux données d’application ou de l’utilisateur, qui résiste aux mises à jour et correspond au modèle de stockage de ZimaOS.
