Vous ne devez pas créer un répertoire /app accessible en écriture sur l’hôte ZimaOS simplement parce qu’un installateur Linux traditionnel en attend un. ZimaOS conserve par conception un système de fichiers racine en lecture seule ; les applications Docker doivent mapper le stockage hôte persistant depuis /DATA vers le chemin accessible en écriture attendu par le conteneur.
Dans cette discussion de janvier 2026, l’utilisateur essayait d’installer ONLYOFFICE Workspace avec un installateur hôte qui supposait un système mutable de type Debian/RPM. Ce modèle d’installation ne convenait pas à ZimaOS.
Pourquoi / n’est pas le bon emplacement pour les données d’application
La réponse de la communauté distinguait correctement les chemins de l’hôte et du conteneur. Une image Docker peut utiliser /app à l’intérieur du conteneur sans que l’hôte dispose d’un répertoire physique /app. Un montage lié peut associer un chemin tel que /DATA/AppData/onlyoffice sur ZimaOS à /app dans le conteneur.
Le guide sur ZimaOS immuable explique la même séparation de type appliance du point de vue de SSH et des gestionnaires de paquets.
Utilisez Docker Compose lorsque le projet le prend en charge
L’utilisateur a ensuite trouvé le projet Docker Compose en amont, qui constitue l’approche la plus naturelle sur ZimaOS. N’importez un fichier Compose qu’après avoir vérifié chaque montage lié de l’hôte, port, variable d’environnement et exigence de privilèges.
Le guide d’importation Compose présente le fonctionnement actuel de Compose dans ZimaOS ainsi que les erreurs courantes liées aux montages liés.
Ne forcez pas un installateur hôte traditionnel sur ZimaOS
Si un installateur s’attend à écrire directement des paquets, des services et des données d’application dans les chemins racine de l’hôte, il peut tout simplement être incompatible avec un système NAS immuable. Tenter de remonter le système de fichiers racine en lecture-écriture ou de recréer manuellement une structure Linux traditionnelle peut perturber les mises à niveau et les mécanismes de récupération du système.
Lorsque le projet en amont fournit une pile de conteneurs maintenue, utilisez-la. S’il ne prend en charge qu’un hôte Linux mutable conventionnel, une machine virtuelle peut constituer une séparation de compatibilité plus propre.
ONLYOFFICE Workspace et DocumentServer sont deux déploiements différents
Ne supposez pas que « ONLYOFFICE dans Docker » signifie que tous les produits ONLYOFFICE utilisent la même structure de volumes. Workspace regroupe davantage de services et de dépendances qu’un serveur de documents autonome. Suivez la définition Compose en amont correspondant exactement au produit que vous déployez.
Le dépôt Docker d’ONLYOFFICE constitue une meilleure source qu’un script d’installation hôte conçu pour les systèmes Debian ou RPM.
En résumé
Laissez le système de fichiers racine de ZimaOS tranquille. Placez les données persistantes sous /DATA, mappez-les dans le conteneur vers le chemin attendu par l’application et utilisez Compose ou une machine virtuelle lorsque le logiciel en amont suppose un hôte mutable. Le problème vient d’une incompatibilité entre modèles d’installation, et non de l’absence d’une fonction permettant de rendre la racine accessible en écriture.
