Une application Docker personnalisée peut nécessiter davantage qu’un simple chemin hôte-conteneur. Dans cette discussion ZimaOS de janvier 2026, un conteneur basé sur SSHFS avait besoin de la propagation des montages via une option :shared. La saisie de cette option dans le champ de volume des applications personnalisées de ZimaOS faisait échouer le conteneur, tandis que le même montage sans cette option ne fournissait pas le comportement côté hôte requis par l’application.
La distinction importante soulevée dans la discussion concerne l’éditeur WebUI de ZimaOS et la pile Docker sous-jacente. Des tests menés par la communauté ont montré que les options de volumes Docker et de montages bind pouvaient fonctionner avec Docker Compose ou via la CLI, tandis que la WebUI ne les analysait ni ne les conservait correctement, notamment pour des options telles que :shared, :ro et :readonly.
La limitation concernait la WebUI, pas Docker standard
L’auteur du message initial demandait d’abord si ZimaOS lui-même ne prenait pas en charge les indicateurs de volume avancés. Après différents tests, la discussion a abouti à une conclusion plus précise : le moteur Docker pouvait utiliser ces options, mais le formulaire d’application personnalisée de ZimaOS ne les exposait pas ou ne les conservait pas correctement.
Une discussion connexe de décembre 2025 est parvenue à la même conclusion pour les montages en lecture seule. Un membre de l’équipe ZimaOS, Zima-Jerry, a répondu que les futures versions de la WebGUI incluraient davantage d’options dans l’éditeur et que la conception était en cours.
Ce statut historique ne doit pas être transformé en promesse ou en date de sortie. Le 24 août 2026, un autre membre de la communauté a indiqué que le problème d’interface lié à la lecture seule n’était toujours pas résolu et a demandé une estimation de délai ; la discussion ne contenait aucune réponse ultérieure de l’équipe.
Pourquoi :shared est important pour certains conteneurs
Le cas d’origine concernait SSHFS. Le conteneur servait à monter un système de fichiers distant, et l’utilisateur avait besoin que le montage ainsi créé se propage au-delà de l’espace de noms du conteneur. Pour ce type de workflow, le simple fait de mapper un chemin hôte dans le conteneur n’équivaut pas à utiliser l’option de propagation de montage requise.
C’est pourquoi les conseils fondés uniquement sur des volumes de données persistantes classiques pour les applications n’ont pas résolu le cas d’utilisation SSHFS signalé. Selon les conteneurs, les sémantiques de montage nécessaires peuvent être différentes.
Pour connaître le comportement et la syntaxe actuels de Docker, consultez la documentation Docker sur les montages bind et la propagation.
Le même problème d’interface concernait :ro et :readonly
La discussion liée de décembre 2025 documentait un problème similaire avec les montages en lecture seule. Un intervenant de la communauté a indiqué que l’interface ZimaOS pouvait réécrire le montage et supprimer le suffixe :ro lorsque la configuration du volume était modifiée ou rouverte.
Ce problème ne relève pas seulement de la commodité. Un montage prévu pour être en lecture seule ne devrait pas devenir inscriptible sans avertissement. Si l’accès en lecture seule fait partie de votre modèle de sécurité ou de protection des données, vérifiez la configuration réelle du montage du conteneur au lieu de vous fier uniquement à ce qui a été saisi dans l’ancienne WebUI.
Docker Compose constituait la solution pratique
L’auteur du message initial a confirmé qu’une définition Docker Compose standard pouvait exprimer les options de montage requises, même si le formulaire graphique de ZimaOS ne le pouvait pas. La solution proposée dans la discussion consistait donc à gérer le montage avancé avec Compose plutôt qu’à utiliser le champ de volume.
La documentation actuelle de ZimaOS, mise à jour en août 2026, présente toujours Docker Compose comme la méthode avancée destinée aux utilisateurs expérimentés et indique que la configuration standard de l’environnement d’exécution des conteneurs doit être définie dans Docker Compose. Consultez la documentation actuelle des fonctionnalités de ZimaOS ainsi que la référence actuelle de ZimaOS sur Docker Compose.
Ces documents actuels confirment la prise en charge de Compose, mais ne documentent pas de commande WebUI dédiée pour chaque option de montage Docker. Si un indicateur de montage est essentiel, validez la configuration Compose et celle de l’environnement d’exécution obtenues au lieu de supposer que l’interface graphique l’a conservé.
Ce que cette discussion ne permet pas d’affirmer
- Elle ne signifie pas que les volumes de données ordinaires des applications ZimaOS nécessitent
:shared. - Elle ne signifie pas que Docker sur ZimaOS ne prend pas en charge les montages avancés.
- Elle n’établit pas que toutes les versions actuelles de la WebUI se comportent encore exactement comme la version de janvier 2026.
- Elle ne fournit pas de date officielle de disponibilité pour des commandes supplémentaires concernant les options de volume.
FAQ sur les options de volume de ZimaOS
La WebUI des applications personnalisées de ZimaOS peut-elle utiliser :shared ?
Dans la discussion source de janvier 2026, la WebUI ne gérait pas correctement cette option. Le comportement requis fonctionnait avec Docker Compose.
Docker dans ZimaOS prend-il en charge :ro et :readonly ?
La discussion distingue la prise en charge par Docker de la limitation historique de l’interface. Docker prend en charge les options de montage en lecture seule, tandis que la WebUI de ZimaOS évoquée dans ces discussions ne les conservait pas toujours correctement.
La limitation de la WebUI a-t-elle été officiellement reconnue ?
Oui. Dans la discussion connexe de décembre 2025, Zima-Jerry a indiqué que davantage d’options d’édition étaient en cours de conception pour les futures WebGUI. Aucune date de sortie n’a été communiquée.
Le problème est-il maintenant résolu ?
Les sources disponibles n’établissent pas l’existence d’un correctif confirmé. Un suivi publié par la communauté le 24 août 2026 décrivait encore le problème d’interface lié à la lecture seule comme non résolu, tandis que la documentation actuelle de ZimaOS continue de recommander Docker Compose pour les configurations avancées.
