Voor een aangepaste Docker-app is mogelijk meer nodig dan alleen een eenvoudig host-naar-containerpad. In deze ZimaOS-discussie van januari 2026 had een op SSHFS gebaseerde container mountpropagatie nodig met een optie :shared. Door die optie in het volumebestand van de aangepaste ZimaOS-app in te voeren, werkte de container niet meer, terwijl dezelfde mount zonder de optie niet het vereiste gedrag aan de hostzijde bood.
Het belangrijke onderscheid in de discussie is dat tussen de ZimaOS WebUI-editor en de onderliggende Docker-stack. Tests door de community lieten zien dat opties voor Docker-volumes en bind-mounts konden werken via Docker Compose of CLI-workflows, terwijl de WebUI opties zoals :shared, :ro en :readonly niet correct parseerde of behield.
De beperking zat in de WebUI, niet in standaard-Docker
De oorspronkelijke vraagsteller vroeg aanvankelijk of ZimaOS zelf geen ondersteuning bood voor geavanceerde volumeflags. Na tests kwam de discussie uit op een beperktere conclusie: de Docker-engine kon de opties gebruiken, maar het formulier voor aangepaste apps in ZimaOS stelde ze niet correct beschikbaar of behield ze niet.
Een gerelateerde discussie uit december 2025 kwam tot dezelfde conclusie voor alleen-lezen-mounts. Een ZimaOS-teamlid, Zima-Jerry, antwoordde dat toekomstige WebGUI-versies meer editoropties zouden bevatten en dat het ontwerpwerk in uitvoering was.
Die historische status mag niet worden omgezet in een belofte of releasedatum. Op 24 augustus 2026 meldde een ander communitylid dat het probleem met de alleen-lezenoptie in de UI nog steeds niet was opgelost en vroeg het om een verwachte datum; de discussie bevatte geen later antwoord van het team.
Waarom :shared voor sommige containers belangrijk is
In het oorspronkelijke geval ging het om SSHFS. De container werd gebruikt om een extern bestandssysteem te mounten, en de gebruiker moest ervoor zorgen dat de resulterende mount zich buiten de containernamespace kon verspreiden. Bij dit type workflow is het eenvoudig koppelen van een hostpad aan de container niet hetzelfde als het gebruik van de vereiste optie voor mountpropagatie.
Daarom loste advies dat alleen was gebaseerd op gewone permanente app-datavolumes de gemelde SSHFS-toepassing niet op. Verschillende containers kunnen verschillende mountsemantiek vereisen.
Raadpleeg voor het huidige gedrag en de syntaxis van Docker de documentatie van Docker over bind-mounts en mountpropagatie.
Hetzelfde UI-probleem gold voor :ro en :readonly
De gekoppelde discussie uit december 2025 beschreef een vergelijkbaar probleem met alleen-lezen-mounts. Een communitylid meldde dat de ZimaOS-UI de mount kon herschrijven en het achtervoegsel :ro kon verwijderen wanneer de volum configuratie werd bewerkt of opnieuw geopend.
Dit gaat om meer dan gemak. Een mount die bedoeld is als alleen-lezen, mag niet ongemerkt schrijfbaar worden. Als alleen-lezen-toegang deel uitmaakt van je beveiligings- of gegevensbeschermingsmodel, controleer dan de daadwerkelijke mountconfiguratie van de container in plaats van uitsluitend te vertrouwen op wat in de historische WebUI is ingevoerd.
Docker Compose was de praktische workaround
De oorspronkelijke vraagsteller bevestigde dat een standaarddefinitie voor Docker Compose de vereiste mountopties kon vastleggen, ook wanneer het grafische formulier van ZimaOS dat niet kon. De workaround in de discussie was daarom om de geavanceerde mount via Compose te beheren in plaats van te vertrouwen op het volumetekstvak.
De huidige ZimaOS-documentatie, bijgewerkt in augustus 2026, beschrijft Docker Compose nog steeds als de geavanceerde route voor ervaren gebruikers en vermeldt dat standaardconfiguratie van de container-runtime thuishoort in Docker Compose. Zie de huidige documentatie over ZimaOS-functies en de huidige referentie voor ZimaOS Docker Compose.
Deze actuele documenten bevestigen ondersteuning voor Compose, maar documenteren geen speciale WebUI-bediening voor elke Docker-mountoptie. Als een mountflag essentieel is, controleer dan de uiteindelijke Compose- en runtimeconfiguratie in plaats van ervan uit te gaan dat de GUI deze heeft behouden.
Wat deze discussie niet bewijst
- Het betekent niet dat gewone app-datavolumes in ZimaOS
:sharedvereisen. - Het betekent niet dat Docker op ZimaOS geen geavanceerde mountondersteuning biedt.
- Het bewijst niet dat elke huidige WebUI-versie zich nog precies gedraagt als de versie van januari 2026.
- Het geeft geen officiële leverdatum voor extra bedieningselementen voor volumeopties.
Veelgestelde vragen over volumeopties in ZimaOS
Kan de WebUI voor aangepaste apps in ZimaOS :shared gebruiken?
In de bron-discussie van januari 2026 verwerkte de WebUI de optie niet correct. Het vereiste gedrag werkte wel via Docker Compose.
Ondersteunt Docker in ZimaOS :ro en :readonly?
In de discussie wordt onderscheid gemaakt tussen ondersteuning door Docker en de historische beperking van de UI. Docker ondersteunt alleen-lezen-mountopties, terwijl de in deze discussies besproken ZimaOS-WebUI ze niet betrouwbaar behield.
Is de beperking van de WebUI officieel erkend?
Ja. In de gerelateerde discussie van december 2025 zei Zima-Jerry dat er voor toekomstige WebGUI's meer editoropties werden ontworpen. Er werd geen releasedatum gegeven.
Is het probleem inmiddels opgelost?
Het bronmateriaal stelt geen bevestigde oplossing vast. Een follow-up van de community op 24 augustus 2026 beschreef het UI-probleem met alleen-lezen-mounts nog steeds als onopgelost, terwijl de huidige ZimaOS-documentatie Docker Compose blijft aanbevelen voor geavanceerde configuratie.
