ZimaOS Docker :ro-volymer: Begränsning i webbgränssnittet och lösning

Docker på ZimaOS stöder skrivskyddade bindmonteringar, men ZimaOS WebUI för anpassade appar som diskuteras i den här communitytråden bevarar inte alltid tillförlitligt alternativ som :ro eller :readonly när en volymmappning redigerades. Det är en begränsning i WebUI, inte i Docker.

Communityns lösning är att exportera eller skriva Compose-YAML-filen manuellt och skapa applikationen med Docker Compose eller CLI:t. IceWhale bekräftade i december 2025 att framtida WebGUI:er utformades med fler redigeringsalternativ. Ett senare svar den 24 augusti 2026 beskrev fortfarande det skrivskyddade beteendet i användargränssnittet som olöst, så aktuella användare bör verifiera den faktiska containermonteringen i stället för att anta att gränssnittet bevarade flaggan.

Docker stöder skrivskyddade bindmonteringar

Dockers aktuella dokumentation om bindmonteringar stöder både alternativen ro och readonly.

Med den korta -v syntaxen:

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

Docker accepterar även skrivskyddad som ett alternativ i den dokumenterade syntaxen för bindmonteringar. Med --mount:

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

En skrivskyddad montering hindrar containern från att skriva via den monteringen, samtidigt som den fortfarande kan läsa värdfilerna.

Vad ZimaOS WebUI gjorde

Den ursprungliga användaren rapporterade att gränssnittet inte kände igen det avslutande :ro flaggan. Ett svar från communityn beskrev beteendet mer specifikt: användargränssnittet skrev om monteringen och tog tyst bort det skrivskyddade alternativet när applikationen sparades eller öppnades igen.

Den skillnaden är viktig. Den underliggande Docker-motorn kan skapa den korrekta skrivskyddade monteringen, men volymfältet i det grafiska gränssnittet kanske inte representerar alla Docker-monteringsalternativ.

Vad IceWhale sa om begränsningen

Den 26 december 2025 svarade Zima-Jerry att framtida WebGUI:er skulle ha fler redigeringsalternativ och att gränssnittet fortfarande var under utformning. Tråden fick senare ett svar den 24 augusti 2026 där avsaknaden av återkoppling om skrivskydd kallades ett säkerhetsproblem och där man frågade efter en tidsplan.

Källtråden innehåller ingen senare bekräftelse från IceWhale på att begränsningen i användargränssnittet har åtgärdats. Utgå därför inte från att ett aktuellt fält i WebUI är säkert för :ro tills du har verifierat den faktiska containermonteringen.

Använd Docker Compose för skrivskyddade monteringar

Den lösning som användes av communityn var att exportera appens Compose-YAML från ZimaOS, redigera monteringen och återskapa containern med standardiserad Docker Compose.

Docker Compose stöder ett åtkomstläge som det tredje fältet i den korta volymsyntaxen:

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

Dockers aktuella referens för Compose-filer dokumenterar ro som åtkomstläge för skrivskyddad åtkomst till en monterad volym eller bind-sökväg.

Ett praktiskt arbetsflöde i ZimaOS

Öppna inställningarna för den anpassade applikationen.
Exportera Compose-YAML-filen om din nuvarande ZimaOS-version erbjuder det alternativet.
Spara en säkerhetskopia innan du redigerar.
Lägg till :ro endast till de värdsökvägar som containern inte ska kunna ändra.
Validera YAML-filen.
Använd en behörig terminal för att köra Docker Compose.
Verifiera den resulterande monteringen innan du litar på den med känsliga filer.

Ett vanligt Compose-kommando är:

docker compose up -d

Kör det från katalogen som innehåller Compose-filen och tänk på att ett manuellt hanterat Compose-projekt kanske inte längre fungerar exakt som en app som hanteras helt via ZimaOS-gränssnittet.

Verifiera att monteringen faktiskt är skrivskyddad

Lita inte enbart på YAML-filen eller etiketten i webbgränssnittet. Inspektera den körande containern:

docker inspect CONTAINER_NAME

I Mounts I avsnittet visas om monteringen är skrivbar. En korrekt skrivskyddad bind-montering ska rapportera:

"RW": false

Dockers egen dokumentation använder denna inspektionsmetod för att verifiera skrivskyddade monteringar.

Testa åtkomstgränsen noggrant

Du kan också testa från en tillfällig eller icke-kritisk container genom att försöka skapa en fil i den monterade sökvägen. En korrekt konfigurerad skrivskyddad montering ska avvisa skrivningen.

Testa inte genom att skriva över en viktig fil. Använd ett ofarligt tillfälligt filnamn och ta bort eventuella testfiler från värden om skrivningen oväntat lyckas.

:ro och :readonly är Docker-alternativ, men syntaxen spelar roll

Den ursprungliga titeln nämner båda :ro och :readonly. Dockers aktuella dokumentation om bind-monteringar accepterar båda namnen i tillämpliga sammanhang för monteringsalternativ. Den mest använda korta syntaxen i Compose är:

/host/path:/container/path:ro

För långa eller --mount syntax, skrivskyddad finns också dokumenterat. Matcha alternativet mot den Docker-syntax du faktiskt använder i stället för att klistra in ett suffix i ett ZimaOS-fält som bara förväntar sig en containersökväg.

En skrivskyddad montering skiljer sig från ett skrivskyddat containerfilsystem

Docker Compose har också en servicenivå read_only option. Det gör containerns rotfilsystem skrivskyddat. Det är inte samma sak som att markera en bind-montering som skrivskyddad.

Till exempel:

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

Använd endast det när programmet är utformat för att köras med ett skrivskyddat rotfilsystem och dess nödvändiga skrivbara sökvägar monteras separat.

Undvik att spara volymen igen i ett gränssnitt som tar bort flaggan

Ett svar från communityn föreslog att behandla ZimaOS WebUI som effektivt skrivskyddat för volyminställningar efter att en skrivskyddad montering har skapats manuellt. Problemet är att när appen öppnas och sparas via ett grafiskt gränssnitt som inte förstår alternativet kan monteringen skrivas om utan :ro.

Innan du gör senare ändringar i gränssnittet bör du exportera den aktuella Compose-konfigurationen och verifiera monteringen efteråt.

Varför detta är viktigt för säkerheten

Skrivskyddade monteringar används ofta för att ge ett program åtkomst till konfiguration, media, certifikat, säkerhetskopior eller källdata utan att ge det behörighet att ändra dessa filer.

Om ett gränssnitt utan förvarning ändrar en montering från skrivskyddad till läs- och skrivbar får containern större åtkomst till värdfilsystemet än administratören avsåg. Därför är verifiering med docker inspect är viktigt tills själva gränssnittet på ett tillförlitligt sätt återger alternativet.

Checklista för skrivskyddade Docker-monteringar i ZimaOS

Bekräfta att programmet verkligen endast behöver läsåtkomst.
Utgå inte från att ZimaOS WebUI bevarar :ro.
Exportera eller skriv en Compose-fil.
Använd /host:/container:ro för den avsedda monteringen.
Starta projektet med standard-Docker Compose.
Verifiera monteringen med docker inspect.
Bekräfta RW är false.
Var försiktig när du öppnar eller sparar programmet igen i WebUI.
Spara en kopia av den fungerande Compose YAML-filen för återställning.

Vanliga frågor om skrivskyddade Docker-monteringar i ZimaOS

Har ZimaOS Docker stöd för :ro?

Ja, på Docker Engine-/Compose-nivå. Källtråden identifierar begränsningen som ZimaOS WebUI:s hantering av monteringsalternativ.

Har WebUI-problemet bekräftats vara åtgärdat?

Inte i den här källtråden. Ett svar från den 24 augusti 2026 beskrev fortfarande det skrivskyddade beteendet i gränssnittet som olöst.

Vilken är den bästa aktuella lösningen?

Exportera eller skapa en Compose YAML-fil, lägg till den skrivskyddade monteringen där och kör docker compose up -doch verifiera den körande containern med docker inspect.

Är read_only på tjänsten samma sak som en :ro-volym?

Nej. Tjänstenivåns read_only: true påverkar containerns rotfilsystem. Ett :ro volymen påverkar endast den specifika monteringen.

Varför är det ett säkerhetsproblem att :ro försvinner utan förvarning?

Eftersom containern kan få skrivåtkomst till värdfiler som administratören avsåg att endast exponera för läsning.