Se o Immich continuar a indicar espaço livre no SSD do sistema ZimaOS mesmo depois de adicionar um HDD maior, a questão importante é saber que diretório do anfitrião está efetivamente associado à montagem de carregamentos/armazenamento do Immich. No tópico da comunidade de abril de 2026, o utilizador original executava o Immich 2.7.4 num SSD do sistema de 250 GB e queria armazenar as fotografias num HDD de 1 TB. Alterar repetidamente o caminho depois da instalação provocou contentores não íntegros ou falhas de arranque.
O tópico de origem produziu vários resultados diferentes. Um utilizador teve sucesso após uma reinstalação limpa e com um YAML personalizado. O autor original acabou por relatar sucesso apenas depois de escolher o caminho de armazenamento do HDD antes de instalar o Immich. Uma resposta posterior associou algumas falhas de arranque às verificações de integridade do armazenamento do Immich. A documentação atual do Immich a montante também mudou desde a versão 2.7.4, pelo que o caminho exato do contentor neste pacote histórico do ZimaOS não deve ser copiado para todas as implementações atuais do Immich.
O que a configuração original do Immich 2.7.4 utilizava
As instruções da comunidade apresentavam este mapeamento histórico:
Anfitrião: /DATA/Gallery/immich
Contentor: /usr/src/app/uploadA primeira recomendação consistia em alterar apenas o lado do anfitrião e preservar o caminho do contentor. Por exemplo, uma unidade secundária poderia ser exposta através de um caminho do anfitrião do ZimaOS, enquanto o Immich continuaria a ver o diretório interno de carregamentos esperado.
Porque é que alterar simplesmente o caminho no anfitrião não funcionou para todos
Vários utilizadores tentaram substituir o caminho predefinido no anfitrião depois de o Immich já ter sido inicializado. Alguns receberam um estado de contentor não íntegro, alguns viram um erro de sistema de ficheiros só de leitura e outros descobriram que a aplicação continuava a indicar a unidade do sistema.
Isto significa que este tópico não sustenta a afirmação universal de que “editar um volume e reiniciar” funciona sempre. O Immich persiste o estado da base de dados e marcadores de integridade do armazenamento, e alterar uma montagem bind após a inicialização pode tornar o novo diretório inconsistente com o estado esperado pelo Immich.
A abordagem de funcionamento confirmada pelo autor original
Após várias tentativas falhadas, o Solid voltou a 19 de abril e disse que a abordagem funcional era efetuar uma instalação limpa e alterar o caminho de instalação/armazenamento para o HDD de 1 TB antes de a instalação do Immich ser inicializada.
Um segundo utilizador confirmou um novo processo de instalação e um caminho YAML personalizado
Outro participante, scott492010, removeu a instalação falhada, preservou as fotografias existentes, eliminou o estado obsoleto dos AppData/base de dados do Immich, reinstalou e utilizou depois o YAML personalizado partilhado na discussão. Confirmou explicitamente que a nova configuração funcionava.
Não elimine casualmente os AppData ou a base de dados do Immich. Esse procedimento da comunidade foi utilizado numa instalação avariada/de teste. Se a biblioteca contiver metadados, utilizadores, álbuns ou recursos carregados importantes, faça uma cópia de segurança da base de dados e do armazenamento de fotografias antes de reconstruir.
Caminho histórico do ZimaOS: /DATA/.media/...
A discussão experimentou caminhos de unidades externas, como:
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadEstes exemplos eram específicos das unidades e da disposição de caminhos do ZimaOS dessa discussão. Não copie o nome Elements ou assuma que todas as unidades aparecem no mesmo caminho do anfitrião. Utilize o caminho real apresentado pelas definições atuais de Ficheiros/aplicações do ZimaOS.
O Immich atual utiliza uma disposição de armazenamento upstream diferente
A documentação upstream atual do Docker Compose do Immich utiliza UPLOAD_LOCATION no anfitrião e monta-o em /data no modelo atual do Compose. Isto difere do mapeamento histórico do Immich 2.7.4 no ZimaOS para /usr/src/app/upload.
Consulte a documentação atual do Docker Compose do Immich.
Isto é uma diferença de versão, não uma contradição. Se utilizar um pacote da App Store do ZimaOS, preserve o destino do contentor definido pelo pacote atual. Se gerir o Compose upstream por sua conta, siga o modelo upstream atual.
Orientação atual do Immich para localizações de ficheiros personalizadas
O Immich dispõe agora de um guia de localizações personalizadas de ficheiros dedicado. Recomenda alterar deliberadamente as localizações no anfitrião e mover os ficheiros existentes correspondentes para que o Immich continue a encontrá-los.
O Immich também desaconselha dividir upload/ e library/ em pontos de montagem bind separados no mesmo dispositivo. Para um novo esquema, siga o modelo de armazenamento atual em vez de reconstruir linha a linha o YAML da comunidade de 2026.
Porque é que a ausência de ficheiros .immich pode impedir o arranque
Uma resposta de julho de 2026 no tópico identificou erros como:
ENOENT: não existe tal ficheiro ou diretório
.../encoded-video/.immichA documentação de integridade do sistema do Immich confirma agora que os ficheiros ocultos .immich são marcadores de montagem utilizados para detetar permissões incorretas ou pontos de montagem de armazenamento em falta/substituídos.
A resposta no fórum sugeria criar manualmente as pastas e os ficheiros marcadores esperados. A documentação atual a montante é mais cautelosa: em geral, os ficheiros marcadores não devem ser criados nem eliminados manualmente, exceto em situações específicas de recuperação. Se o ponto de montagem tiver mudado inesperadamente, corrija primeiro o ponto de montagem. Recriar manualmente um marcador só é apropriado depois de verificar por que motivo está em falta.
Não utilize chmod 777 como solução de permissões predefinida
A resposta final da comunidade também utilizou:
sudo chmod -R 777 /DATA/Main-Storage/immichIsto concede a todos os utilizadores/processos locais amplo acesso de escrita. Pode remover uma barreira de permissões, mas não é o modelo de permissões permanente preferido. Em vez disso, identifique o UID/GID e as permissões de armazenamento esperadas pelo pacote Immich instalado.
Mantenha a base de dados PostgreSQL num sistema de ficheiros adequado
Mover os recursos fotográficos para um HDD grande não significa que todos os componentes do Immich devam ficar lá. Os requisitos atuais do Immich indicam que a base de dados PostgreSQL deve, idealmente, ficar num armazenamento SSD local e requer um sistema de ficheiros com semântica normal de propriedade/permissões Unix; NTFS e exFAT não são suportados para o diretório de dados da base de dados.
Consulte Requisitos de instalação do Immich.
Isto significa que uma arquitetura razoável pode manter a base de dados e o estado da aplicação do Immich num armazenamento SSD fiável, colocando a localização de upload das fotografias/vídeos, muito maior, num disco secundário adequado.
Faça uma cópia de segurança antes de reconstruir ou mover dados existentes do Immich
A documentação atual do Immich recomenda proteger tanto a base de dados como os recursos do sistema de ficheiros. Uma cópia de segurança apenas da base de dados não contém as fotografias e os vídeos originais.
Guia de cópia de segurança e restauro do Immich
Ordem de resolução de problemas mais segura
- Identifique o pacote/versão exato do Immich instalado no ZimaOS.
- Registe o mapeamento atual de upload entre o anfitrião e o contentor.
- Faça uma cópia de segurança das fotografias importantes e da base de dados do Immich antes de alterar uma instalação existente.
- Numa instalação nova, escolha o caminho pretendido no anfitrião para o armazenamento de grande capacidade antes da primeira inicialização, quando o pacote do ZimaOS o permitir.
- Preserve o caminho do lado do contentor definido por esse pacote.
- Se a aplicação ficar não íntegra, leia os registos do Immich e procure erros de permissões ou de integridade do armazenamento.
- Verifique se a nova pasta no anfitrião pode ser escrita pela identidade do contentor do Immich.
- Se os registos mencionarem a ausência de
.immichmarcadores; verifique a montagem e a estrutura de diretórios antes de criar ficheiros manualmente. - Evite
chmod 777como solução permanente.
Perguntas frequentes sobre o armazenamento do sistema do Immich
Porque é que o Immich continua a mostrar a capacidade do meu SSD do sistema?
A montagem bind ativa de upload pode ainda apontar para o armazenamento do sistema, ou a montagem alterada pode não ter sido inicializada corretamente. Verifique o mapeamento efetivo entre anfitrião e contentor utilizado pelo servidor em execução.
O autor original resolveu o problema?
Sim. A Solid indicou que uma instalação limpa, com o caminho do HDD selecionado antes da instalação, funcionou depois de as alterações pós-instalação terem falhado.
Devo copiar /usr/src/app/upload para uma nova instalação do Immich?
Não cegamente. Esse era o caminho do contentor no pacote histórico do Immich 2.7.4 para ZimaOS. O Compose atual do Immich upstream utiliza /data. Siga o pacote/versão que está efetivamente a executar.
Devo criar manualmente ficheiros .immich?
Só depois de confirmar por que motivo estão em falta. A documentação atual do Immich indica que estes marcadores normalmente não devem ser criados ou eliminados manualmente, exceto em casos específicos de recuperação.
Posso colocar a base de dados numa unidade USB exFAT?
Os requisitos atuais do Immich não suportam exFAT/NTFS para o diretório de dados do PostgreSQL. Mantenha a base de dados num sistema de ficheiros local adequado e, se necessário, mova os recursos fotográficos separadamente.
