Solução da comunidade

Corrigir erros de permissões de pastas do Docker no ZimaOS com exFAT e PUID/PGID

A February 2026 ZimaOS permissions thread where HandBrake could read but not write to an exFAT drive. The discussion showed why changing container PUID/PGID does not create POSIX ownership on exFAT and why host mount behavior matters.

Alterar PUID e PGID dentro de uma aplicação Docker não garante que o contentor possa escrever em todos os sistemas de ficheiros do anfitrião. Neste tópico de fevereiro de 2026, o HandBrake não conseguia escrever num SSD montado em /media/sda2, mesmo depois de o utilizador experimentar vários IDs de utilizador e de grupo.

O detalhe decisivo era o sistema de ficheiros: a unidade era exFAT e estava montada como pertencente ao root. O exFAT não fornece a propriedade normal de UID/GID por ficheiro do Linux da mesma forma que o ext4, pelo que alterar apenas o utilizador do contentor não podia corrigir as permissões do ponto de montagem no anfitrião.

O problema não era apenas o utilizador do contentor

O utilizador mostrou que o contentor do HandBrake já tinha valores de PUID e PGID, mas a pasta do anfitrião continuava a aparecer como pertencente ao root. Um membro da comunidade distinguiu corretamente a identidade do Docker da semântica do sistema de ficheiros do anfitrião.

Esta distinção aplica-se a muitas aplicações auto-hospedadas: o contentor só pode utilizar as permissões disponibilizadas pelo ponto de montagem do anfitrião.

O exFAT utiliza mapeamento de permissões ao nível da montagem

O exFAT é útil para mover discos entre sistemas operativos, mas não armazena a propriedade e os bits de modo do Linux como o ext4. O UID, o GID e o comportamento das máscaras são definidos quando o sistema de ficheiros é montado.

É por isso que as tentativas normais de chown ou chmod podem parecer ineficazes num disco exFAT, apesar de os mesmos comandos funcionarem normalmente no ext4.

O ZimaOS atual apresenta o exFAT como um sistema de ficheiros suportado para leitura e escrita. Isto descreve o acesso básico ao sistema de ficheiros, não o comportamento específico das permissões POSIX para o Docker. Consulte a tabela atual de sistemas de ficheiros suportados ao decidir se a portabilidade ou as permissões nativas do Linux são mais importantes para um disco de servidor.

A reformatação através da interface também falhou neste caso

Formatador de armazenamento do ZimaOS a apresentar um erro de estado de saída 1 enquanto o utilizador tenta reformatar o disco exFAT
O utilizador tentou avançar para uma configuração de servidor baseada em ext4, mas o próprio formatador do ZimaOS devolveu um erro.

Uma inspeção posterior mostrou que o disco estava montado em várias localizações geridas pelo ZimaOS e continuava ocupado através do serviço Ficheiros. O tópico nunca chegou a uma sequência oficial de reparação da IceWhale, pelo que comandos destrutivos de desmontagem ou do fstab provenientes de respostas da comunidade não devem ser republicados como instruções oficiais.

Mapeie explicitamente a pasta do anfitrião para o contentor

Uma resposta posterior ilustrou o mapeamento conceptual correto de volumes: escolha um diretório real do anfitrião e mapeie-o para o caminho esperado pela aplicação dentro do contentor.

Mapeamento de um volume de uma pasta do anfitrião em /media para /app/miningcore dentro de um contentor Docker nas aplicações do ZimaOS
O mapeamento resolve a visibilidade do caminho no contentor; o sistema de ficheiros do anfitrião continua a ter de fornecer permissão de escrita ao utilizador do contentor.

Porque é que o ext4 é mais simples para armazenamento de contentores apenas Linux

A recomendação da comunidade foi utilizar ext4 num disco dedicado a cargas de trabalho Docker, porque o ext4 suporta os bits normais de propriedade e permissões do Linux. Trata-se de uma recomendação prática de administração Linux, não de um requisito da IceWhale para que todos os discos de dados do ZimaOS utilizem ext4.

Se a portabilidade entre plataformas for mais importante, o exFAT pode continuar a ser adequado, mas o modelo de propriedade ao nível da montagem tem de corresponder aos utilizadores que executam os seus contentores.

Mantenha o armazenamento das aplicações afastado do disco do sistema

O ZimaOS atual permite aos utilizadores escolher a localização dos dados das aplicações e mapear pastas de armazenamento reais para os contentores. A explicação de como as pastas do anfitrião se tornam volumes dos contentores é útil antes de alterar a propriedade ou reformatar um disco.

Perguntas frequentes sobre permissões de pastas Docker

Porque é que alterar o PUID e o PGID não resolveu o problema da unidade exFAT?

Porque o exFAT não armazena a propriedade normal dos ficheiros do Linux. O UID, o GID e a máscara do ponto de montagem determinam a forma como o sistema de ficheiros é apresentado aos processos Linux.

O ZimaOS suporta leitura e escrita em exFAT?

Sim. O ZimaOS atual apresenta o exFAT como suportado para leitura e escrita, mas isso não o torna equivalente ao ext4 relativamente à propriedade POSIX.

Todos os discos de dados Docker devem usar ext4?

Não universalmente, mas o ext4 é mais simples quando o disco é dedicado a contentores Linux que dependem de propriedade e permissões normais.

O erro de formatação foi resolvido no tópico?

Não foi publicada nenhuma correção final oficial. O disco continuava ocupado através de pontos de montagem e serviços geridos pelo ZimaOS.