ZimaOS Docker :ro-volumes: beperking en oplossing van de WebUI

Docker op ZimaOS ondersteunt alleen-lezenbindkoppelingen, maar de ZimaOS WebUI voor aangepaste apps die in deze communitythread wordt besproken, behoudt opties zoals niet betrouwbaar. :ro of :readonly bij het bewerken van een volumetoewijzing. Dat is een beperking van de WebUI, niet van Docker zelf.

De oplossing vanuit de community is om de Compose-YAML handmatig te exporteren of te schrijven en de toepassing met Docker Compose of de CLI aan te maken. IceWhale erkende in december 2025 dat toekomstige WebGUI's werden ontworpen met meer bewerkingsopties. Een latere reactie op 24 augustus 2026 beschreef het gedrag van de gebruikersinterface voor alleen-lezen nog steeds als onopgelost. Huidige gebruikers moeten daarom de daadwerkelijke containeraankoppeling controleren in plaats van ervan uit te gaan dat de gebruikersinterface de vlag heeft behouden.

Docker ondersteunt alleen-lezenbindkoppelingen

De huidige documentatie van Docker over bindkoppelingen ondersteunt zowel de opties ro als readonly.

Met de korte -v syntaxis:

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

Docker accepteert ook alleen-lezen als optie in de gedocumenteerde syntaxis voor bindkoppelingen. Met --mount:

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

Een alleen-lezenkoppeling voorkomt dat de container via die koppeling naar de bestanden van de host schrijft, terwijl de container deze wel kan lezen.

Wat de ZimaOS WebUI deed

De oorspronkelijke gebruiker meldde dat de interface bij het bewerken van een volume in de WebUI de afsluitende :ro vlag. Een reactie uit de community beschreef het gedrag specifieker: de gebruikersinterface herschreef de koppeling en verwijderde de optie voor alleen-lezen stilzwijgend wanneer de toepassing werd opgeslagen of opnieuw geopend.

Dat onderscheid is belangrijk. De onderliggende Docker-engine kan de juiste alleen-lezenkoppeling maken, maar het volumepad in de GUI vertegenwoordigt mogelijk niet alle Docker-opties voor koppelingen.

Wat IceWhale zei over de beperking

Op 26 december 2025 antwoordde Zima-Jerry dat toekomstige WebGUI's meer bewerkingsopties zouden hebben en dat de interface nog werd ontworpen. Later, op 24 augustus 2026, verscheen in de thread een antwoord waarin het ontbreken van feedback over alleen-lezen als een beveiligingsprobleem werd aangemerkt en om een planning werd gevraagd.

De oorspronkelijke thread bevat geen latere bevestiging van IceWhale dat de beperking van de gebruikersinterface is opgelost. Ga er daarom niet van uit dat een huidig WebUI-veld veilig is voor :ro totdat u de daadwerkelijke containeraankoppeling hebt gecontroleerd.

Docker Compose gebruiken voor alleen-lezenkoppelingen

De workaround van de community was om de Compose-YAML van de app uit ZimaOS te exporteren, de koppeling te bewerken en de container opnieuw aan te maken met standaard Docker Compose.

Docker Compose ondersteunt een toegangsmodus als het derde veld in de korte volumesyntaxis:

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

De huidige referentie voor Compose-bestanden van Docker documenteert ro als de modus voor alleen-lezen-toegang voor een gekoppeld volume of bind-pad.

Een praktische ZimaOS-werkwijze

Open de instellingen van de aangepaste applicatie.
Exporteer de Compose-YAML als je huidige ZimaOS-build die optie biedt.
Sla een reservekopie op voordat je bewerkingen uitvoert.
Voeg toe :ro tot alleen de hostpaden die de container niet mag wijzigen.
Valideer de YAML.
Gebruik een geautoriseerde terminal om Docker Compose uit te voeren.
Controleer de resulterende koppeling voordat je deze vertrouwt met gevoelige bestanden.

Een normale Compose-opdracht is:

docker compose up -d

Voer dit uit vanuit de map met het Compose-bestand en houd er rekening mee dat een handmatig beheerd Compose-project zich mogelijk niet exact hetzelfde gedraagt als een app die volledig via de ZimaOS-interface wordt beheerd.

Controleer of de koppeling daadwerkelijk alleen-lezen is

Vertrouw niet alleen op de YAML of het label in de webinterface. Inspecteer de actieve container:

docker inspect CONTAINER_NAME

In de Mounts sectie toont Docker of de koppeling beschrijfbaar is. Een correct alleen-lezen bind-mount zou het volgende moeten rapporteren:

"RW": false

De eigen documentatie van Docker gebruikt deze inspectiemethode om alleen-lezen-koppelingen te verifiëren.

Test de toegangsgrens zorgvuldig

Je kunt dit ook testen vanuit een wegwerpcontainer of een niet-kritieke container door te proberen een bestand aan te maken in het gekoppelde pad. Een correct geconfigureerde alleen-lezen-koppeling zou de schrijfactie moeten weigeren.

Test dit niet door een belangrijk bestand te overschrijven. Gebruik een onschadelijke tijdelijke bestandsnaam en verwijder testartefacten van de host als schrijven onverwacht toch lukt.

:ro en :readonly zijn Docker-opties, maar de syntaxis is belangrijk

De oorspronkelijke titel vermeldt beide :ro en :readonly. De huidige documentatie van Docker over bind-mounts accepteert beide namen in toepasselijke contexten met mountopties. De meest gebruikte korte syntaxis in Compose is:

/host/path:/container/path:ro

Voor lange of --mount syntaxis, alleen-lezen wordt ook gedocumenteerd. Stem de optie af op de Docker-syntaxis die je daadwerkelijk gebruikt, in plaats van een achtervoegsel te plakken in een ZimaOS-veld dat alleen een containerpad verwacht.

Een alleen-lezen-koppeling verschilt van een alleen-lezen-containerbestandssysteem

Docker Compose heeft ook een serviceniveau read_only optie. Daarmee wordt het rootbestandssysteem van de container alleen-lezen. Het is niet hetzelfde als één bindmount als alleen-lezen markeren.

Bijvoorbeeld:

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

Gebruik dat alleen wanneer de applicatie ontworpen is om met een alleen-lezen rootbestandssysteem te werken en de benodigde schrijfbare paden afzonderlijk zijn gemount.

Sla het volume niet opnieuw op in een interface die de vlag laat vallen

Een antwoord uit de community adviseerde om de ZimaOS WebUI voor volume-instellingen feitelijk als alleen-schrijven te behandelen nadat handmatig een alleen-lezenmount is gemaakt. De zorg is dat het opnieuw openen en opslaan van de app via een grafische interface die de optie niet begrijpt, de mount opnieuw kan wegschrijven zonder :ro.

Exporteer vóór latere wijzigingen in de interface de huidige Compose-configuratie en controleer de mount daarna.

Waarom dit belangrijk is voor de beveiliging

Alleen-lezenmounts worden vaak gebruikt om een applicatie toegang te geven tot configuratie, media, certificaten, back-ups of brongegevens, zonder die bestanden te mogen wijzigen.

Als een interface een mount stilzwijgend van alleen-lezen naar lezen-schrijven wijzigt, krijgt de container meer toegang tot het hostbestandssysteem dan de beheerder bedoeld had. Daarom is verificatie met docker inspect is belangrijk totdat de interface de optie zelf betrouwbaar weergeeft.

Checklist voor alleen-lezen Docker-mounts in ZimaOS

Bevestig dat de applicatie echt alleen-lezen toegang nodig heeft.
Ga er niet van uit dat de ZimaOS WebUI :ro.
Exporteer of schrijf een Compose-bestand.
Gebruik /host:/container:ro voor de bedoelde mount.
Start het project met standaard Docker Compose.
Controleer de mount met docker inspect.
Bevestigen RW is false.
Wees voorzichtig bij het opnieuw openen of opnieuw opslaan van de applicatie in de WebUI.
Bewaar een kopie van het werkende Compose YAML-bestand voor herstel.

Veelgestelde vragen over alleen-lezenmounts in ZimaOS Docker

Ondersteunt ZimaOS Docker :ro?

Ja, op het niveau van de Docker-engine/Compose. De brondiscussie identificeert de beperking als de manier waarop de ZimaOS WebUI mountopties verwerkt.

Is bevestigd dat het WebUI-probleem is opgelost?

Niet in deze brondiscussie. Een antwoord van 24 augustus 2026 beschreef het gedrag van de alleen-lezenoptie in de interface nog steeds als onopgelost.

Wat is momenteel de beste workaround?

Exporteer of maak een Compose YAML-bestand, voeg daar de alleen-lezenmount aan toe en voer het uit docker compose up -den controleer de actieve container met docker inspect.

Is service read_only hetzelfde als een :ro-volume?

Nee. Serviceniveau- read_only: true heeft invloed op het rootbestandssysteem van de container. Een :ro volume heeft alleen invloed op die specifieke mount.

Waarom is het stilzwijgend verliezen van :ro een beveiligingsprobleem?

Omdat de container schrijftoegang kan krijgen tot bestanden op de host die de beheerder alleen-lezen wilde vrijgeven.