Uma aplicação Docker personalizada pode exigir mais do que um simples caminho do anfitrião para o contentor. Numa discussão de janeiro de 2026 sobre o ZimaOS, um contentor baseado em SSHFS precisava de propagação de montagem através da opção :shared. Introduzir essa opção no campo de volumes da aplicação personalizada do ZimaOS fazia o contentor falhar, enquanto a mesma montagem sem a opção não fornecia o comportamento do lado do anfitrião de que a aplicação necessitava.
A distinção importante no tópico é entre o editor da WebUI do ZimaOS e a stack Docker subjacente. Os testes da comunidade mostraram que as opções de volumes Docker e de bind mounts podiam funcionar através de fluxos de trabalho com Docker Compose ou CLI, enquanto a WebUI não analisava nem preservava corretamente opções como :shared, :ro e :readonly.
A limitação estava na WebUI, não no Docker padrão
O autor original perguntou inicialmente se o próprio ZimaOS não tinha suporte para sinalizadores de volumes avançados. Após os testes, a discussão convergiu para uma conclusão mais específica: o motor Docker conseguia utilizar as opções, mas o formulário de aplicações personalizadas do ZimaOS não as expunha nem preservava corretamente.
Um tópico relacionado, de dezembro de 2025, chegou à mesma conclusão relativamente às montagens só de leitura. Um membro da equipa do ZimaOS, Zima-Jerry, respondeu que versões futuras da WebGUI incluiriam mais opções no editor e que o trabalho de conceção estava em curso.
Esse estado histórico não deve ser transformado numa promessa ou numa data de lançamento. Em 24 de agosto de 2026, outro membro da comunidade relatou que o problema da interface relativo às montagens só de leitura continuava por resolver e pediu uma previsão; o tópico não continha uma resposta posterior da equipa.
Porque é que :shared é importante para alguns contentores
O caso de origem envolvia SSHFS. O contentor estava a ser utilizado para montar um sistema de ficheiros remoto, e o utilizador precisava que a montagem resultante se propagasse para além do espaço de nomes do contentor. Neste tipo de fluxo de trabalho, mapear simplesmente um caminho do anfitrião para o contentor não equivale a utilizar a opção de propagação de montagem necessária.
É por isso que as recomendações baseadas apenas em volumes normais e persistentes para dados de aplicações não resolveram o caso de utilização SSHFS relatado. Contentores diferentes podem exigir semânticas de montagem diferentes.
Para consultar o comportamento e a sintaxe atuais do Docker, veja a documentação do Docker sobre bind mounts e propagação.
O mesmo problema da interface afetava :ro e :readonly
A discussão relacionada de dezembro de 2025 documentou um problema semelhante com montagens só de leitura. Um participante da comunidade relatou que a interface do ZimaOS podia reescrever a montagem e remover o sufixo :ro quando a configuração do volume era editada ou reaberta.
Isto é mais importante do que uma simples questão de conveniência. Uma montagem destinada a ser só de leitura não deve tornar-se silenciosamente gravável. Se o acesso só de leitura fizer parte do seu modelo de segurança ou proteção de dados, verifique a configuração efetiva da montagem do contentor em vez de confiar apenas no que foi introduzido na WebUI histórica.
O Docker Compose era a solução prática
O autor original confirmou que uma definição normal do Docker Compose conseguia expressar as opções de montagem necessárias, mesmo quando o formulário gráfico do ZimaOS não conseguia. A solução apresentada no tópico consistia, portanto, em gerir a montagem avançada através do Compose, em vez de depender da caixa de texto dos volumes.
A documentação atual do ZimaOS, atualizada em agosto de 2026, continua a descrever o Docker Compose como o caminho avançado para utilizadores experientes e afirma que a configuração padrão do runtime dos contentores deve ser feita no Docker Compose. Consulte a documentação atual das funcionalidades do ZimaOS e a referência atual do Docker Compose do ZimaOS.
Estes documentos atuais confirmam o suporte para Compose, mas não documentam um controlo específico da WebUI para todas as opções de montagem do Docker. Se um sinalizador de montagem for essencial, valide a configuração resultante do Compose/runtime em vez de presumir que a interface gráfica o preservou.
O que este tópico não comprova
- Não significa que os volumes normais de dados de aplicações do ZimaOS precisem de
:shared. - Não significa que o Docker no ZimaOS não tenha suporte para montagens avançadas.
- Não estabelece que todas as versões atuais da WebUI continuem a comportar-se exatamente como a versão de janeiro de 2026.
- Não fornece uma data oficial para a disponibilização de controlos adicionais para opções de volumes.
Perguntas frequentes sobre as opções de volumes do ZimaOS
A WebUI de aplicações personalizadas do ZimaOS pode utilizar :shared?
No tópico de origem, de janeiro de 2026, a WebUI não tratava corretamente a opção. O comportamento necessário funcionava através do Docker Compose.
O Docker do ZimaOS suporta :ro e :readonly?
A discussão distingue o suporte do Docker da limitação histórica da interface. O Docker suporta opções de montagem só de leitura, enquanto a WebUI do ZimaOS discutida nestes tópicos não as preservava de forma fiável.
A limitação da WebUI foi oficialmente reconhecida?
Sim. No tópico relacionado de dezembro de 2025, Zima-Jerry afirmou que estavam a ser concebidas mais opções de edição para futuras WebGUIs. Não foi indicada qualquer data de lançamento.
O problema já foi corrigido?
O material de origem não estabelece uma correção confirmada. Um acompanhamento da comunidade, em 24 de agosto de 2026, ainda descrevia o problema da interface relativo às montagens só de leitura como não resolvido, enquanto a documentação atual do ZimaOS continua a recomendar o Docker Compose para configurações avançadas.
