Un'app Docker personalizzata può richiedere più di un semplice percorso dall'host al container. In questa discussione di gennaio 2026 su ZimaOS, un container basato su SSHFS richiedeva la propagazione del mount tramite un'opzione :shared. L'inserimento di questa opzione nel campo dei volumi delle app personalizzate di ZimaOS causava il mancato avvio del container, mentre lo stesso mount senza l'opzione non forniva il comportamento lato host richiesto dall'applicazione.
La distinzione importante emersa dalla discussione riguarda l'editor WebUI di ZimaOS e lo stack Docker sottostante. I test della community hanno dimostrato che le opzioni per i volumi Docker e i bind mount potevano funzionare tramite Docker Compose o i flussi di lavoro da CLI, mentre la WebUI non analizzava né conservava correttamente opzioni come :shared, :ro e :readonly.
Il limite era nella WebUI, non in Docker standard
Inizialmente l'autore del post chiedeva se fosse ZimaOS a non supportare i flag avanzati per i volumi. Dopo i test, la discussione è giunta a una conclusione più circoscritta: il motore Docker poteva usare le opzioni, ma il modulo per le app personalizzate di ZimaOS non le esponeva né le conservava correttamente.
Una discussione correlata del dicembre 2025 è giunta alla stessa conclusione per i mount in sola lettura. Un membro del team ZimaOS, Zima-Jerry, ha risposto che le versioni future della WebGUI avrebbero incluso più opzioni nell'editor e che la progettazione era in corso.
Questo stato storico non deve essere trasformato in una promessa o in una data di rilascio. Il 24 agosto 2026, un altro membro della community ha riferito che il problema dell'interfaccia per i mount in sola lettura non era ancora stato risolto e ha chiesto una stima dei tempi; la discussione non conteneva una risposta successiva del team.
Perché :shared è importante per alcuni container
Il caso originale riguardava SSHFS. Il container veniva usato per montare un filesystem remoto e l'utente aveva bisogno che il mount risultante si propagasse al di fuori del namespace del container. In questo tipo di flusso di lavoro, mappare semplicemente un percorso dell'host nel container non equivale a usare l'opzione di propagazione del mount richiesta.
Per questo motivo, i suggerimenti basati solo sui normali volumi persistenti per i dati delle app non hanno risolto il caso d'uso SSHFS segnalato. Container diversi possono richiedere semantiche di mount diverse.
Per il comportamento e la sintassi attuali di Docker, consulta la documentazione Docker sui bind mount e sulla propagazione dei mount.
Lo stesso problema della UI riguardava :ro e :readonly
La discussione collegata del dicembre 2025 documentava un problema simile con i mount in sola lettura. Un partecipante della community ha riferito che la UI di ZimaOS poteva riscrivere il mount e rimuovere il suffisso :ro quando la configurazione del volume veniva modificata o riaperta.
Questo è importante, non solo una questione di comodità. Un mount destinato a essere in sola lettura non dovrebbe diventare silenziosamente scrivibile. Se l'accesso in sola lettura fa parte del tuo modello di sicurezza o di protezione dei dati, verifica l'effettiva configurazione del mount del container invece di affidarti soltanto a ciò che è stato inserito nella WebUI storica.
Docker Compose era la soluzione pratica
L'autore del post originale ha confermato che una definizione Docker Compose standard poteva esprimere le opzioni di mount richieste anche quando il modulo grafico di ZimaOS non era in grado di farlo. La soluzione alternativa discussa consisteva quindi nel gestire il mount avanzato tramite Compose invece di affidarsi al campo di testo dei volumi.
La documentazione attuale di ZimaOS, aggiornata nell'agosto 2026, descrive ancora Docker Compose come il percorso avanzato per gli utenti esperti e specifica che la configurazione standard del runtime dei container rientra in Docker Compose. Consulta la documentazione attuale sulle funzionalità di ZimaOS e il riferimento attuale di ZimaOS per Docker Compose.
Questi documenti attuali confermano il supporto a Compose, ma non documentano un controllo dedicato nella WebUI per ogni opzione dei mount Docker. Se un flag di mount è essenziale, verifica la configurazione risultante di Compose/runtime invece di presumere che la GUI lo abbia conservato.
Cosa non dimostra questa discussione
- Non significa che i normali volumi per i dati delle app di ZimaOS richiedano
:shared. - Non significa che Docker su ZimaOS non supporti i mount avanzati.
- Non dimostra che ogni versione attuale della WebUI si comporti ancora esattamente come la build di gennaio 2026.
- Non fornisce una data ufficiale per l'introduzione di ulteriori controlli sulle opzioni dei volumi.
Domande frequenti sulle opzioni dei volumi di ZimaOS
La WebUI delle app personalizzate di ZimaOS può usare :shared?
Nella discussione originale di gennaio 2026, la WebUI non gestiva correttamente l'opzione. Il comportamento richiesto funzionava tramite Docker Compose.
Docker su ZimaOS supporta :ro e :readonly?
La discussione distingue il supporto di Docker dal limite storico della UI. Docker supporta le opzioni per i mount in sola lettura, mentre la WebUI di ZimaOS discussa in questi thread non le conservava in modo affidabile.
Il limite della WebUI è stato riconosciuto ufficialmente?
Sì. Nella discussione correlata del dicembre 2025, Zima-Jerry ha affermato che per le future WebGUI erano in fase di progettazione ulteriori opzioni dell'editor. Non è stata fornita alcuna data di rilascio.
Il problema è stato risolto?
Il materiale di origine non dimostra l'esistenza di una soluzione confermata. Un seguito della community del 24 agosto 2026 descriveva ancora il problema dell'interfaccia per la sola lettura come irrisolto, mentre la documentazione attuale di ZimaOS continua a consigliare Docker Compose per la configurazione avanzata.
