O utilizador de origem de março de 2026 estava a criar o seu primeiro NAS a partir de um thin client HP T640 com um disco de sistema NVMe de 128 GB e três discos rígidos ligados por USB. O plano era sensato: manter as fotografias num disco externo, fazer cópias de segurança para um segundo disco e colocar os conteúdos multimédia do Plex numa unidade separada de 4 TB. A principal falha não foi a impossibilidade de utilizar armazenamento USB. O Immich parou porque os mapeamentos dos volumes da aplicação foram editados incorretamente.
A parte da discussão relativa às capacidades de armazenamento também precisa de uma delimitação temporal atual. Em março de 2026, o utilizador e o respondente consideravam as unidades USB mais limitadas do que o armazenamento interno. A documentação atual do ZimaOS afirma explicitamente que as unidades USB seguem a mesma lógica de armazenamento que os HDD/SSD internos e podem ser utilizadas para armazenamento, adicionadas a uma matriz ou utilizadas para expandir o espaço existente.
O NAS de origem dependia inteiramente do armazenamento USB
A configuração utilizava:
- thin client HP T640 com AMD R1505G, 8 GB de RAM e NVMe de 128 GB;
- dois HDD Seagate de 2,5 polegadas em caixas USB separadas;
- um HDD externo WD de 4 TB para conteúdos multimédia do Plex.
Como o thin client não tinha compartimentos internos para discos de fácil acesso, o utilizador precisava que o armazenamento USB funcionasse como armazenamento NAS principal, e não como suporte amovível temporário.
Os discos apareceram como armazenamento USB
O utilizador acreditava que as unidades externas não podiam ser tratadas como armazenamento interno nem utilizadas para RAID. Isso refletia o comportamento e as expectativas associados à sua configuração de março de 2026, não o modelo de armazenamento atual do ZimaOS.
O ZimaOS atual trata as unidades USB como armazenamento normal
A documentação atual da IceWhale indica que as unidades USB seguem a mesma lógica que os HDD e SSD internos: podem ser utilizadas como armazenamento individual, adicionadas a uma matriz ou utilizadas para expandir o espaço existente.
Utilize o fluxo de trabalho atual de armazenamento do ZimaOS para unidades USB em vez de criar um novo sistema com base na antiga ideia de que o RAID USB não é suportado de forma alguma.
A falha do Immich foi um erro de mapeamento entre ficheiro e diretório
O utilizador de origem alterou as definições de volumes do Immich e o Docker devolveu um erro a indicar que não conseguia montar:
/media/Photos/Immich
→ /etc/localtime/etc/localtime dentro do contentor é um ficheiro, não um diretório da biblioteca de fotografias. Por isso, o Docker rejeitou a tentativa de montar uma pasta sobre esse ficheiro.
/etc/localtime mapeamento de ficheiro.Mantenha o armazenamento de fotografias e /etc/localtime como montagens separadas
O autor da resposta da comunidade separou corretamente as duas funções:
- pasta de fotografias no anfitrião → diretório de carregamento/dados do Immich;
- anfitrião
/etc/localtimeficheiro → contentor/etc/localtimeficheiro.
As regras atuais de montagem bind do Docker continuam a exigir que os tipos da origem e do destino correspondam. Um diretório não pode ser montado sobre um ficheiro como se fossem elementos permutáveis.
A solução alternativa de montagem bind em /DATA era uma sugestão histórica da comunidade
O autor da resposta também sugeriu criar um diretório estável em /DATA e montar por bind o caminho USB nesse local, pois os discos externos podem ainda não estar prontos quando as aplicações arrancam após um reinício.
Essa era uma orientação da comunidade para a versão original. O ZimaOS atual tem um suporte mais robusto para armazenamento USB gerido, pelo que uma instalação nova deve começar por utilizar a interface de Armazenamento e o seletor de volumes geridos da aplicação, em vez de criar uma montagem bind personalizada no arranque.
Aponte o Immich para o armazenamento gerido, não para um caminho de dispositivo bruto
O ZimaOS atual recomenda colocar os dados das aplicações e as bibliotecas multimédia de grandes dimensões no espaço de armazenamento destinado a esse fim, em vez de encher a unidade do sistema. Utilize o caminho do anfitrião selecionado pelo ZimaOS e, em seguida, preserve o caminho no contentor esperado pelo Immich.
Para os mapeamentos atuais de aplicações, o modelo de caminhos de armazenamento de aplicações do ZimaOS explica como os caminhos do anfitrião e do contentor se relacionam.
O RAID e as cópias de segurança continuam a resolver problemas diferentes
Embora o ZimaOS atual possa utilizar unidades USB em arrays, o RAID 1 não substitui uma segunda cópia de segurança independente. Dois discos USB num único array protegem contra a falha de um disco-membro, mas não contra eliminação acidental, malware, problemas na caixa ou no controlador, nem contra a perda de todo o NAS.
A ideia do utilizador original de manter uma cópia adicional continua a ser útil, apesar de o conjunto de funcionalidades de armazenamento ter mudado.
Os conteúdos multimédia do Plex são mais simples do que o estado da aplicação Immich
O utilizador considerou descartável a unidade Plex de 4 TB, pois o conteúdo de vídeo podia ser substituído. Essa é uma distinção de risco razoável: os ficheiros multimédia, as fotografias do Immich, o estado da base de dados do Immich e a configuração da aplicação não têm necessariamente de seguir a mesma política de redundância ou cópia de segurança.
Perguntas frequentes sobre armazenamento USB externo
O ZimaOS atual pode usar unidades USB como armazenamento gerido?
Sim. A documentação atual do Armazenamento suporta explicitamente unidades USB como armazenamento e membros de arrays.
Porque é que o Immich deixou de funcionar depois de o diretório ser alterado?
A pasta de fotografias foi acidentalmente mapeada para o /etc/localtime caminho do ficheiro.
Os utilizadores atuais devem criar montagens bind manuais em /DATA para todas as unidades USB?
Não. Essa era uma solução alternativa histórica da comunidade. Comece pelos controlos atuais de Armazenamento gerido e de volumes de aplicações.
