Schreibgeschützte Docker-Volumes in benutzerdefinierten Apps von ZimaOS verwenden

Docker unter ZimaOS unterstützt schreibgeschützte Bind-Mounts, aber das in diesem Community-Thread besprochene WebUI für benutzerdefinierte Apps von ZimaOS bewahrt Optionen wie nicht zuverlässig. :ro oder :readonly beim Bearbeiten einer Volume-Zuordnung. Das ist eine Einschränkung des WebUI, keine Einschränkung von Docker selbst.

Die Lösung aus der Community besteht darin, die Compose-YAML-Datei manuell zu exportieren oder zu schreiben und die Anwendung mit Docker Compose oder der CLI zu erstellen. IceWhale bestätigte im Dezember 2025, dass künftige WebGUIs mit mehr Bearbeitungsoptionen entwickelt würden. Eine spätere Antwort vom 24. August 2026 beschrieb das Verhalten des WebUI bei Schreibschutz weiterhin als ungelöst. Aktuelle Nutzer sollten daher den tatsächlichen Container-Mount überprüfen, statt anzunehmen, dass das WebUI das Flag beibehalten hat.

Docker unterstützt schreibgeschützte Bind-Mounts

Die aktuelle Dokumentation zu Bind-Mounts von Docker unterstützt sowohl die Optionen ro als auch readonly.

Mit der Kurzsyntax -v Syntax:

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

Docker akzeptiert auch readonly als Option in seiner dokumentierten Syntax für Bind-Mounts. Außerdem --mount:

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

Ein schreibgeschützter Mount verhindert, dass der Container über diesen Mount schreibt, ermöglicht ihm aber weiterhin, die Dateien des Hosts zu lesen.

Was das ZimaOS-WebUI tat

Der ursprüngliche Nutzer berichtete, dass die Benutzeroberfläche beim Bearbeiten eines Volumes im WebUI das abschließende :ro als Option in der dokumentierten Syntax für Bind-Mounts. Eine Antwort aus der Community beschrieb das Verhalten genauer: Die Benutzeroberfläche schrieb den Mount neu und entfernte die Schreibschutzoption stillschweigend, wenn die Anwendung gespeichert oder erneut geöffnet wurde.

Diese Unterscheidung ist wichtig. Die zugrunde liegende Docker-Engine kann den korrekten schreibgeschützten Mount erstellen, aber das Volume-Feld der GUI stellt möglicherweise nicht alle Docker-Mount-Optionen dar.

Was IceWhale über die Einschränkung sagte

Am 26. Dezember 2025 antwortete Zima-Jerry, dass künftige WebGUIs mehr Bearbeitungsoptionen bieten würden und die Benutzeroberfläche noch entwickelt werde. Später erhielt der Thread am 24. August 2026 eine Antwort, in der das fehlende Feedback zum Schreibschutz als Sicherheitsproblem bezeichnet und nach einem Zeitplan gefragt wurde.

Der Quellthread enthält keine spätere Bestätigung von IceWhale, dass die Einschränkung der Benutzeroberfläche behoben wurde. Gehen Sie daher nicht davon aus, dass ein aktuelles WebUI-Feld für :ro bis Sie den tatsächlichen Container-Mount überprüft haben.

Docker Compose für schreibgeschützte Mounts verwenden

Der Workaround der Community bestand darin, die Compose-YAML-Datei der App aus ZimaOS zu exportieren, den Mount zu bearbeiten und den Container mit Standard-Docker-Compose neu zu erstellen.

Docker Compose unterstützt einen Zugriffsmodus als drittes Feld in der kurzen Volume-Syntax:

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

Die aktuelle Referenz für Compose-Dateien von Docker dokumentiert ro als schreibgeschützten Zugriffsmodus für ein eingebundenes Volume oder einen Bind-Pfad.

Ein praxisnaher ZimaOS-Ablauf

1. Öffnen Sie die Einstellungen der benutzerdefinierten Anwendung.
2. Exportieren Sie die Compose-YAML-Datei, sofern Ihre aktuelle ZimaOS-Version diese Option bietet.
3. Speichern Sie vor der Bearbeitung eine Sicherungskopie.
4. Fügen Sie :ro auf die Hostpfade, die der Container nicht ändern soll.
5. Validieren Sie die YAML-Datei.
6. Verwenden Sie ein autorisiertes Terminal, um Docker Compose auszuführen.
7. Überprüfen Sie den resultierenden Mount, bevor Sie ihm vertrauliche Dateien anvertrauen.

Ein normaler Compose-Befehl lautet:

docker compose up -d

Führen Sie den Befehl in dem Verzeichnis aus, das die Compose-Datei enthält, und beachten Sie, dass sich ein manuell verwaltetes Compose-Projekt möglicherweise nicht mehr genau wie eine vollständig über die ZimaOS-Benutzeroberfläche verwaltete App verhält.

Überprüfen Sie, ob der Mount tatsächlich schreibgeschützt ist

Vertrauen Sie nicht nur auf die YAML-Datei oder die Bezeichnung in der WebUI. Prüfen Sie den laufenden Container:

docker inspect CONTAINER_NAME

Im Mounts Im Abschnitt zeigt Docker, ob der Mount beschreibbar ist. Ein korrekt schreibgeschützter Bind-Mount sollte Folgendes melden:

"RW": false

Die eigene Dokumentation von Docker verwendet diese Prüfmethode, um schreibgeschützte Mounts zu verifizieren.

Testen Sie die Zugriffsgrenze sorgfältig

Sie können auch aus einem kurzlebigen oder unkritischen Container heraus testen, indem Sie versuchen, eine Datei im eingebundenen Pfad zu erstellen. Ein korrekt konfigurierter schreibgeschützter Mount sollte den Schreibvorgang ablehnen.

Testen Sie dies nicht, indem Sie eine wichtige Datei überschreiben. Verwenden Sie einen harmlosen temporären Dateinamen und entfernen Sie alle Testdateien vom Host, falls das Schreiben unerwartet erfolgreich ist.

:ro und :readonly sind Docker-Optionen, aber die Syntax ist entscheidend

Der ursprüngliche Titel erwähnt sowohl :ro und :readonly. Die aktuelle Dokumentation von Docker zu Bind-Mounts akzeptiert beide Bezeichnungen in den entsprechenden Kontexten für Mount-Optionen. Die am häufigsten verwendete Kurzsyntax von Compose lautet:

/host/path:/container/path:ro

Für lange oder --mount Syntax, readonly ist ebenfalls dokumentiert. Stimmen Sie die Option auf die tatsächlich verwendete Docker-Syntax ab, statt ein Suffix in ein ZimaOS-Feld einzufügen, das nur einen Containerpfad erwartet.

Ein schreibgeschützter Mount unterscheidet sich von einem schreibgeschützten Container-Dateisystem

Docker Compose verfügt außerdem über eine Dienstebene read_only Option. Dadurch wird das Root-Dateisystem des Containers schreibgeschützt. Das ist nicht dasselbe wie einen einzelnen Bind-Mount als schreibgeschützt zu markieren.

Zum Beispiel:

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

Verwende das nur, wenn die Anwendung für den Betrieb mit einem schreibgeschützten Root-Dateisystem ausgelegt ist und die benötigten beschreibbaren Pfade separat gemountet werden.

Volume nicht erneut in einer UI speichern, die das Flag entfernt

Eine Antwort aus der Community empfahl, das ZimaOS-WebUI für Volume-Einstellungen nach dem manuellen Erstellen eines schreibgeschützten Mounts praktisch als nur zum Schreiben geeignet zu behandeln. Das Problem besteht darin, dass das erneute Öffnen und Speichern der App über eine GUI, die diese Option nicht versteht, den Mount ohne :ro.

Bevor du später Änderungen an der UI vornimmst, exportiere die aktuelle Compose-Konfiguration und überprüfe den Mount anschließend.

Warum das für die Sicherheit wichtig ist

Schreibgeschützte Mounts werden häufig verwendet, um einer Anwendung Zugriff auf Konfigurationen, Medien, Zertifikate, Sicherungen oder Quelldaten zu geben, ohne ihr die Berechtigung zu erteilen, diese Dateien zu ändern.

Wenn eine UI einen Mount stillschweigend von schreibgeschützt auf Lese-/Schreibzugriff ändert, erhält der Container mehr Zugriff auf das Host-Dateisystem, als der Administrator vorgesehen hat. Deshalb ist die Überprüfung mit docker inspect ist wichtig, bis die UI selbst diese Option zuverlässig darstellt.

Checkliste für schreibgeschützte Docker-Mounts in ZimaOS

1. Bestätige, dass die Anwendung tatsächlich nur Lesezugriff benötigt.
2. Gehe nicht davon aus, dass das ZimaOS-WebUI :ro.
3. Exportiere eine Compose-Datei oder schreibe eine.
4. Verwende /host:/container:ro für den vorgesehenen Mount.
5. Starte das Projekt mit standardmäßigem Docker Compose.
6. Überprüfe den Mount mit docker inspect.
7. Bestätigen RW ist false.
8. Sei vorsichtig, wenn du die Anwendung im WebUI erneut öffnest oder speicherst.
9. Bewahre eine Kopie der funktionierenden Compose-YAML-Datei zur Wiederherstellung auf.

FAQ zu schreibgeschützten Docker-Mounts in ZimaOS

Unterstützt ZimaOS Docker :ro?

Ja, auf Ebene der Docker-Engine und von Compose. Im Quellthread wird die Einschränkung als Problem bei der Verarbeitung von Mount-Optionen durch das ZimaOS-WebUI beschrieben.

Wurde bestätigt, dass das WebUI-Problem behoben ist?

Nicht in diesem Quellthread. In einer Antwort vom 24. August 2026 wurde das Verhalten der schreibgeschützten UI weiterhin als ungelöst beschrieben.

Was ist derzeit der beste Workaround?

Exportiere eine Compose-YAML-Datei oder erstelle eine, füge dort den schreibgeschützten Mount hinzu und führe docker compose up -dund überprüfe den laufenden Container mit docker inspect.

Ist service read_only dasselbe wie ein :ro-Volume?

Nein. Die Dienstebene read_only: true betrifft das Root-Dateisystem des Containers. A :ro volume betrifft nur diesen spezifischen Mount.

Warum ist es ein Sicherheitsproblem, wenn :ro stillschweigend verloren geht?

Weil der Container möglicherweise Schreibzugriff auf Hostdateien erhält, die der Administrator eigentlich nur zum Lesen freigeben wollte.