Eine benutzerdefinierte Docker-App benötigt möglicherweise mehr als nur einen einfachen Host-zu-Container-Pfad. In dieser ZimaOS-Diskussion vom Januar 2026 benötigte ein SSHFS-basierter Container die Mount-Propagation mithilfe der Option :shared. Die Eingabe dieser Option in das Volume-Feld für benutzerdefinierte Apps in ZimaOS führte dazu, dass der Container fehlschlug, während derselbe Mount ohne die Option nicht das vom Host benötigte Verhalten bereitstellte.
Die wichtige Unterscheidung aus dem Thread besteht zwischen dem ZimaOS-WebUI-Editor und dem zugrunde liegenden Docker-Stack. Tests aus der Community zeigten, dass Docker-Volume- und Bind-Mount-Optionen über Docker-Compose- oder CLI-Workflows funktionieren konnten, während die WebUI Optionen wie :shared, :ro und :readonly nicht korrekt analysierte oder beibehielt.
Die Einschränkung lag in der WebUI, nicht in Standard-Docker
Der ursprüngliche Verfasser fragte zunächst, ob ZimaOS selbst keine Unterstützung für erweiterte Volume-Flags biete. Nach Tests kam die Diskussion zu einer enger gefassten Schlussfolgerung: Die Docker-Engine konnte die Optionen verwenden, aber das Formular für benutzerdefinierte Apps in ZimaOS stellte sie nicht korrekt bereit oder behielt sie nicht korrekt bei.
Ein verwandter Thread vom Dezember 2025 kam bei schreibgeschützten Mounts zur gleichen Schlussfolgerung. Ein Mitglied des ZimaOS-Teams, Zima-Jerry, antwortete, dass künftige WebGUI-Versionen weitere Editor-Optionen enthalten würden und die entsprechenden Designarbeiten im Gange seien.
Dieser historische Stand sollte nicht in ein Versprechen oder einen Veröffentlichungstermin umgedeutet werden. Am 24. August 2026 berichtete ein weiteres Community-Mitglied, dass das Problem mit der schreibgeschützten UI weiterhin ungelöst sei, und fragte nach einem Zeitplan; der Thread enthielt keine spätere Antwort des Teams.
Warum :shared für manche Container wichtig ist
Im Ausgangsfall ging es um SSHFS. Der Container wurde verwendet, um ein entferntes Dateisystem einzubinden, und der Benutzer musste dafür sorgen, dass der daraus resultierende Mount über den Namespace des Containers hinaus propagiert wurde. Bei einem solchen Workflow ist das bloße Einbinden eines Host-Pfads in den Container nicht gleichbedeutend mit der Verwendung der erforderlichen Mount-Propagation-Option.
Deshalb löste eine Beratung, die sich ausschließlich auf gewöhnliche persistente App-Daten-Volumes bezog, den gemeldeten SSHFS-Anwendungsfall nicht. Für unterschiedliche Container können unterschiedliche Mount-Semantiken erforderlich sein.
Die aktuelle Syntax und das aktuelle Verhalten von Docker findest du in der Docker-Dokumentation zu Bind-Mounts und Mount-Propagation.
Dasselbe UI-Problem betraf :ro und :readonly
Die verlinkte Diskussion vom Dezember 2025 dokumentierte ein ähnliches Problem mit schreibgeschützten Mounts. Ein Community-Mitglied berichtete, dass die ZimaOS-Oberfläche den Mount umschreiben und das Suffix :ro entfernen konnte, wenn die Volume-Konfiguration bearbeitet oder erneut geöffnet wurde.
Das ist mehr als eine reine Komfortfrage. Ein Mount, der als schreibgeschützt vorgesehen ist, sollte nicht unbemerkt beschreibbar werden. Wenn der schreibgeschützte Zugriff Teil deines Sicherheits- oder Datenschutzmodells ist, überprüfe die tatsächliche Mount-Konfiguration des Containers, statt dich ausschließlich darauf zu verlassen, was in die historische WebUI eingegeben wurde.
Docker Compose war der praktikable Workaround
Der ursprüngliche Verfasser bestätigte, dass eine standardmäßige Docker-Compose-Definition die erforderlichen Mount-Optionen ausdrücken konnte, auch wenn das grafische Formular von ZimaOS dies nicht ermöglichte. Der Workaround im Thread bestand daher darin, den erweiterten Mount über Compose zu verwalten, anstatt sich auf das Volume-Textfeld zu verlassen.
Die aktuelle, im August 2026 aktualisierte ZimaOS-Dokumentation beschreibt Docker Compose weiterhin als den erweiterten Weg für erfahrene Benutzer und erklärt, dass die standardmäßige Konfiguration der Container-Laufzeit in Docker Compose vorgenommen wird. Siehe die aktuelle ZimaOS-Funktionsdokumentation und die aktuelle ZimaOS-Referenz zu Docker Compose.
Diese aktuellen Dokumente bestätigen die Compose-Unterstützung, dokumentieren jedoch keine spezielle WebUI-Steuerung für jede Docker-Mount-Option. Wenn ein Mount-Flag unverzichtbar ist, überprüfe die resultierende Compose-/Laufzeitkonfiguration, anstatt davon auszugehen, dass die GUI es beibehalten hat.
Was dieser Thread nicht belegt
- Er bedeutet nicht, dass gewöhnliche ZimaOS-App-Daten-Volumes
:sharedbenötigen. - Er bedeutet nicht, dass Docker unter ZimaOS keine erweiterten Mounts unterstützt.
- Er stellt nicht fest, dass sich jede aktuelle WebUI-Version weiterhin exakt wie der Build vom Januar 2026 verhält.
- Er nennt keinen offiziellen Termin für die Bereitstellung zusätzlicher Steuerelemente für Volume-Optionen.
FAQ zu ZimaOS-Volume-Optionen
Kann die WebUI für benutzerdefinierte Apps in ZimaOS :shared verwenden?
Im Ausgangsthread vom Januar 2026 verarbeitete die WebUI die Option nicht korrekt. Das erforderliche Verhalten funktionierte stattdessen über Docker Compose.
Unterstützt Docker in ZimaOS :ro und :readonly?
Die Diskussion unterscheidet zwischen der Docker-Unterstützung und der historischen Einschränkung der UI. Docker unterstützt schreibgeschützte Mount-Optionen, während die in diesen Threads diskutierte ZimaOS-WebUI sie nicht zuverlässig beibehielt.
Wurde die Einschränkung der WebUI offiziell bestätigt?
Ja. Im verwandten Thread vom Dezember 2025 erklärte Zima-Jerry, dass weitere Editor-Optionen für künftige WebGUIs entwickelt würden. Ein Veröffentlichungstermin wurde nicht genannt.
Ist das Problem inzwischen behoben?
Das Ausgangsmaterial belegt keine bestätigte Behebung. Ein Community-Follow-up vom 24. August 2026 beschrieb das Problem mit der schreibgeschützten UI weiterhin als ungelöst, während die aktuelle ZimaOS-Dokumentation für erweiterte Konfigurationen weiterhin Docker Compose empfiehlt.
