O objetivo original desta discussão de novembro de 2025 era simples: manter o ZimaOS e as aplicações no SSD interno de 512 GB do mini PC, utilizando simultaneamente um disco rígido externo Seagate USB de 5 TB para multimédia e transferências. A dificuldade surgiu por se tratar o disco externo como uma montagem genérica de um servidor Linux antes de compreender como o ZimaOS já gere o armazenamento.
O utilizador experimentou fazer a montagem manual em /var, o servidor sofreu posteriormente uma falha e o utilizador reinstalou o ZimaOS. Depois, montou o disco num caminho de dados do ZimaOS e mapeou-o para o SABnzbd, mas a aplicação continuou a devolver um erro de permissões. Esta discussão contém, portanto, duas lições distintas: primeiro, escolha um caminho de anfitrião seguro e gerido; depois, resolva as permissões do contentor separadamente.
Não utilize /var como ponto de montagem USB arbitrário
O ZimaOS é um sistema operativo ao estilo de um dispositivo dedicado, com caminhos do sistema geridos. O utilizador de origem afirmou ter montado o disco externo em /var parecia funcionar inicialmente, mas foi seguido por uma falha completa do servidor e pela reinstalação.
A discussão não prova que a montagem, por si só, tenha causado diretamente a falha, mas é motivo suficiente para não promover diretórios do sistema a localizações normais de armazenamento para discos de suporte multimédia.
Deixe o ZimaOS atual gerir o disco externo
O ZimaOS atual oferece um suporte de armazenamento USB muito mais abrangente do que o ambiente de 2025 referido nesta discussão. É possível adicionar um disco USB através de Definições > Armazenamento e utilizá-lo como armazenamento normal, em vez de o associar manualmente a um ponto de montagem Linux inventado.
Numa nova implementação, comece por o fluxo de trabalho atual do ZimaOS para adicionar armazenamento USB. Depois de o disco ser gerido, utilize a pasta de armazenamento real no mapeamento de volumes da aplicação.
O disco de origem acabou por aparecer nos caminhos geridos pelo ZimaOS
O caminho exato apresentado numa instalação de 2025 não deve ser copiado para outro servidor. Os nomes dos dispositivos, como sda, sdb, e sdc pode mudar consoante a ordem de arranque e o hardware ligado.
Mapeie uma pasta, não o dispositivo de bloco bruto
Normalmente, as aplicações Docker devem receber um diretório, como uma pasta de transferências ou de multimédia, e não o dispositivo bruto /dev/sda1. O ZimaOS monta o sistema de ficheiros; o contentor recebe uma pasta do anfitrião pertencente a esse sistema de ficheiros montado.
A explicação atual de como o armazenamento do anfitrião se transforma num volume do contentor ajuda a evitar confundir o dispositivo de disco, o ponto de montagem e o caminho do contentor.
Uma montagem correta ainda pode gerar um erro de permissões
O utilizador de origem acedeu a /DATA/HDD1 e mapeou-a para o SABnzbd, mas a aplicação não conseguiu utilizar o diretório de transferências selecionado. Isso significa que a visibilidade do armazenamento já não era o único problema.
Os processos Docker são executados como um utilizador ou grupo dentro do contentor. Se a pasta no anfitrião pertencer a outro utilizador e tiver permissões restritivas, o contentor pode conseguir aceder ao caminho, mas continuar sem conseguir criar ficheiros.
Não copie o PUID 999 cegamente
Uma resposta da comunidade disse ao utilizador para alterar o PUID de 1000 para 999. Isso pode ter correspondido ao modelo de contas do ZimaOS do autor da resposta, mas não é uma constante universal.
Antes de alterar PUID ou PGID, identifique o proprietário da pasta real no anfitrião e o utilizador com que se espera que a aplicação seja executada. Um valor numérico que funciona numa instalação pode corresponder a uma conta diferente noutra.
chmod e chown recursivos são poderosos e destrutivos
Uma resposta posterior da comunidade sugeriu executar recursivamente chmod 775 e chown no caminho de transferências. Esses comandos podem ser ferramentas úteis de administração do Linux, mas alteram todos os ficheiros e diretórios dentro do destino. Não foram publicados por membros da equipa da IceWhale nesta discussão.
Antes de alterar recursivamente a propriedade:
- confirme o caminho de destino exato;
- confirme se o sistema de ficheiros suporta a propriedade normal do Linux;
- compreenda que utilizadores ou serviços já dependem da pasta;
- faça uma cópia de segurança dos metadados ou das permissões importantes se a pasta for partilhada por várias aplicações.
O tipo de sistema de ficheiros pode alterar o modelo de permissões
Um disco ext4 armazena diretamente o UID, o GID e os bits de modo do Linux. O exFAT e algumas configurações NTFS podem apresentar a propriedade através de opções de montagem. Se as alterações ao PUID não tiverem efeito, verifique o sistema de ficheiros antes de alterar repetidamente as definições da aplicação.
Uma organização mais simples para aplicações de multimédia
Uma configuração prática é:
- SSD interno: sistema ZimaOS e ambiente de execução de aplicações pequenas;
- HDD externo de grande capacidade: multimédia, transferências, cópias de segurança e outros dados volumosos;
- AppData persistente: colocado numa localização de armazenamento com capacidade suficiente e cobertura de cópias de segurança;
- cada aplicação: mapeamentos de volumes explícitos apenas para as pastas de que necessita.
Isto impede que uma transferência de multimédia encha a unidade do sistema e facilita a criação de cópias de segurança da configuração da aplicação separadamente dos ficheiros de multimédia de grandes dimensões.
Perguntas frequentes sobre HDDs externos no ZimaOS
Devo montar manualmente um HDD externo em /var?
Não, para a utilização normal atual do ZimaOS. Utilize a interface Armazenamento e os caminhos de armazenamento geridos.
O SABnzbd deve mapear diretamente /dev/sda1?
Não. Mapeie um diretório normal do anfitrião, a partir do sistema de ficheiros montado, para o caminho de transferências esperado pelo contentor.
Porque é que a aplicação vê a pasta, mas não consegue escrever?
As permissões, a propriedade do sistema de ficheiros do anfitrião ou o PUID/PGID do contentor podem não permitir escritas.
O PUID 999 é um valor padrão do ZimaOS?
Não. Foi uma sugestão específica da comunidade e deve ser verificada no sistema real.
