Utiliser des volumes Docker en lecture seule dans les applications personnalisées de ZimaOS

Docker sur ZimaOS prend en charge les montages bind en lecture seule, mais la WebUI des applications personnalisées de ZimaOS évoquée dans ce fil communautaire ne préserve pas toujours correctement les options telles que :ro ou :readonly lors de la modification d’un mappage de volume. Il s’agit d’une limitation de la WebUI, et non d’une limitation de Docker lui-même.

La solution de contournement proposée par la communauté consiste à exporter ou à rédiger manuellement le fichier YAML Compose, puis à créer l’application avec Docker Compose ou la CLI. IceWhale a reconnu en décembre 2025 que les futures interfaces WebGUI étaient conçues avec davantage d’options d’édition. Une réponse ultérieure, le 24 août 2026, indiquait toujours que le comportement de l’interface pour la lecture seule n’était pas résolu ; les utilisateurs actuels doivent donc vérifier le montage réel du conteneur plutôt que de supposer que l’interface a conservé l’option.

Docker prend en charge les montages bind en lecture seule

La documentation actuelle de Docker sur les montages bind prend en charge les options ro et readonly.

Avec la forme abrégée -v syntaxe :

docker run -v /host/path:/container/path:ro IMAGE

Docker accepte également lecture seule comme option dans sa syntaxe documentée pour les montages bind. Avec --mount:

docker run --mount type=bind,src=/host/path,dst=/container/path,readonly IMAGE

Un montage en lecture seule empêche le conteneur d’écrire via ce montage tout en lui permettant de lire les fichiers de l’hôte.

Ce que faisait la WebUI de ZimaOS

L’utilisateur d’origine a signalé que, lorsqu’un volume était modifié dans la WebUI, l’interface ne reconnaissait pas le suffixe :ro l’option. Une réponse de la communauté a décrit plus précisément le comportement : l’interface réécrivait le montage et supprimait silencieusement l’option de lecture seule lorsque l’application était enregistrée ou rouverte.

Cette distinction est importante. Le moteur Docker sous-jacent peut créer le montage correct en lecture seule, mais le champ de volume de l’interface graphique ne prend pas forcément en charge toutes les options de montage Docker.

Ce qu’IceWhale a déclaré au sujet de la limitation

Le 26 décembre 2025, Zima-Jerry a répondu que les futures interfaces WebGUI offriraient davantage d’options d’édition et que l’interface était encore en cours de conception. Le fil a ensuite reçu, le 24 août 2026, une réponse qualifiant l’absence d’indication du mode lecture seule de problème de sécurité et demandant une date prévisionnelle.

Le fil source ne contient aucune confirmation ultérieure d’IceWhale indiquant que la limitation de l’interface a été corrigée. Pour cette raison, ne supposez pas qu’un champ actuel de la WebUI est fiable pour :ro jusqu’à ce que vous ayez vérifié le montage réel du conteneur.

Utilisez Docker Compose pour les montages en lecture seule

La solution de contournement proposée par la communauté consistait à exporter depuis ZimaOS le fichier YAML Compose de l’application, à modifier le montage, puis à recréer le conteneur avec Docker Compose standard.

Docker Compose prend en charge un mode d’accès comme troisième champ de la syntaxe courte des volumes :

services:
  app:
    image: your/image:latest
    volumes:
      - /DATA/example:/data:ro

La documentation de référence actuelle de Docker sur les fichiers Compose documente ro comme mode d’accès en lecture seule pour un volume monté ou un chemin bind.

Une procédure pratique avec ZimaOS

1. Ouvrez les paramètres de l’application personnalisée.
2. Exportez le fichier YAML Compose si votre version actuelle de ZimaOS propose cette option.
3. Enregistrez une copie de sauvegarde avant toute modification.
4. Ajoutez :ro uniquement aux chemins hôtes que le conteneur ne doit pas modifier.
5. Validez le YAML.
6. Utilisez un terminal autorisé pour exécuter Docker Compose.
7. Vérifiez le montage obtenu avant de lui confier des fichiers sensibles.

Une commande Compose classique est :

docker compose up -d

Exécutez cette commande depuis le répertoire contenant le fichier Compose et gardez à l’esprit qu’un projet Compose géré manuellement peut ne plus se comporter exactement comme une application entièrement gérée depuis l’interface utilisateur de ZimaOS.

Vérifiez que le montage est réellement en lecture seule

Ne vous fiez pas uniquement au YAML ou au libellé de l’interface Web. Inspectez le conteneur en cours d’exécution :

docker inspect CONTAINER_NAME

Dans la Mounts section, Docker indique si le montage est accessible en écriture. Un montage bind correctement configuré en lecture seule doit afficher :

"RW" : false

La documentation officielle de Docker utilise cette méthode d’inspection pour vérifier les montages en lecture seule.

Testez soigneusement la limite d’accès

Vous pouvez également tester depuis l’intérieur d’un conteneur jetable ou non critique en essayant de créer un fichier dans le chemin monté. Un montage correctement configuré en lecture seule doit refuser l’écriture.

Ne faites pas de test en écrasant un fichier important. Utilisez un nom de fichier temporaire inoffensif et supprimez de l’hôte tout fichier créé lors du test si l’écriture réussit de manière inattendue.

:ro et :readonly sont des options Docker, mais la syntaxe compte

Le titre original mentionne à la fois :ro et :readonly. La documentation actuelle de Docker sur les montages bind accepte les deux noms dans les contextes d’options de montage applicables. La syntaxe courte Compose la plus couramment utilisée est :

/host/path:/container/path:ro

Pour les syntaxes longues ou --mount syntaxe, lecture seule est également documenté. Faites correspondre l’option à la syntaxe Docker que vous utilisez réellement, plutôt que de coller un suffixe dans un champ ZimaOS qui attend uniquement un chemin de conteneur.

Un montage en lecture seule est différent d’un système de fichiers de conteneur en lecture seule

Docker Compose dispose également d’une option au niveau du service read_only option. Cela rend le système de fichiers racine du conteneur accessible en lecture seule. Ce n’est pas la même chose que de marquer un montage de liaison individuel comme étant en lecture seule.

Par exemple :

services:
  app:
    image: your/image:latest
    read_only: true

Utilisez cette option uniquement lorsque l’application est conçue pour fonctionner avec un système de fichiers racine en lecture seule et que ses chemins nécessitant l’écriture sont montés séparément.

Évitez d’enregistrer à nouveau le volume dans une interface qui supprime l’indicateur

Une réponse de la communauté suggérait de considérer l’interface Web de ZimaOS comme effectivement en écriture seule pour les paramètres de volume après la création manuelle d’un montage en lecture seule. Le problème est que le fait de rouvrir et d’enregistrer l’application via une interface graphique qui ne comprend pas l’option peut réécrire le montage sans :ro.

Avant d’effectuer d’autres modifications dans l’interface, exportez la configuration Compose actuelle et vérifiez ensuite le montage.

Pourquoi est-ce important pour la sécurité ?

Les montages en lecture seule sont souvent utilisés pour donner à une application accès à des configurations, des médias, des certificats, des sauvegardes ou des données sources sans lui accorder l’autorisation de modifier ces fichiers.

Si une interface transforme silencieusement un montage en lecture seule en montage en lecture-écriture, le conteneur reçoit un accès au système de fichiers de l’hôte plus étendu que prévu par l’administrateur. C’est pourquoi il est important de vérifier avec docker inspect est important tant que l’interface elle-même ne représente pas correctement et de manière fiable cette option.

Liste de contrôle des montages Docker en lecture seule de ZimaOS

1. Confirmez que l’application nécessite réellement un accès en lecture seule.
2. Ne supposez pas que l’interface Web de ZimaOS conserve :ro.
3. Exportez ou rédigez un fichier Compose.
4. Utilisez /host:/container:ro pour le montage concerné.
5. Démarrez le projet avec Docker Compose standard.
6. Vérifiez le montage avec docker inspect.
7. Confirmer RW est false.
8. Soyez prudent lorsque vous rouvrez ou enregistrez à nouveau l’application dans l’interface Web.
9. Conservez une copie du fichier YAML Compose fonctionnel pour la récupération.

FAQ sur les montages Docker en lecture seule de ZimaOS

Docker sur ZimaOS prend-il en charge :ro ?

Oui, au niveau du moteur Docker/de Compose. Le fil source identifie la limitation comme étant liée à la gestion des options de montage par l’interface Web de ZimaOS.

Le problème de l’interface Web a-t-il été confirmé comme corrigé ?

Pas dans ce fil source. Une réponse du 24 août 2026 décrivait encore le comportement de l’interface en lecture seule comme non résolu.

Quelle est la meilleure solution de contournement actuelle ?

Exportez ou créez un fichier YAML Compose, ajoutez-y le montage en lecture seule, puis exécutez docker compose up -d, et vérifiez le conteneur en cours d’exécution avec docker inspect.

La propriété read_only du service est-elle identique à un volume :ro ?

Non. Au niveau du service, read_only: true affecte le système de fichiers racine du conteneur. Un :ro volume n’affecte que ce point de montage spécifique.

Pourquoi la perte silencieuse de :ro pose-t-elle un problème de sécurité ?

Parce que le conteneur peut obtenir un accès en écriture aux fichiers de l’hôte que l’administrateur voulait exposer uniquement en lecture.