Esta fonte contém várias falhas do Immich superficialmente semelhantes, mas não uma solução universal. A aplicação Immich desativada do autor original recuperou imediatamente após executar sudo systemctl restart docker. Outro utilizador tentou o mesmo comando e continuou sem conseguir iniciar o Immich. O erro apresentado mais tarde indicava que a porta do anfitrião 2283 já estava atribuída, o que é um problema diferente de um daemon do Docker parado.
Essa distinção é a principal lição: após uma atualização do sistema operativo, determine primeiro se o próprio Docker está com problemas, se apenas um projeto Compose está com problemas ou se um contentor obsoleto/duplicado já está a utilizar a porta de que o Immich necessita.
Verifique primeiro o estado do serviço Docker
A primeira recomendação de 777-Spider foi verificar se o Docker estava a funcionar corretamente. O autor original reiniciou então o Docker e informou que tudo voltou a funcionar.
Reiniciar o Docker afeta todos os contentores no anfitrião, por isso faça-o deliberadamente e espere que as outras aplicações sejam reiniciadas.
O reinício do Docker não foi uma solução universal para o Immich
Chris informou que o mesmo reinício do Docker ajudou outras aplicações, mas não recuperou o Immich. Isto é uma prova direta de que systemctl restart docker não deve ser tratado como uma solução garantida.
Um dos erros da fonte mostrou explicitamente que a porta 2283 já estava atribuída
Para uma situação equivalente atual, identifique qual o contentor/processo que utiliza a porta 2283 antes de eliminar ou recriar qualquer elemento. Contentores antigos duplicados do Immich ou um projeto Compose recriado parcialmente podem deixar uma porta ocupada.
A falha ao iniciar uma aplicação Compose é um erro da pilha da aplicação
Se o Docker executa normalmente o Paperless ou outras aplicações, mas o Immich falha com um erro do Compose, inspecione os estados/registos dos serviços do Immich e a respetiva definição Compose atual, em vez de reinstalar todo o sistema operativo.
A reinstalação ajudou um utilizador, mas custou tempo e exigiu copiar novamente os dados
Chris acabou por reinstalar o Immich e copiar novamente as fotografias. Alertou explicitamente para a importância das cópias de segurança. Foi uma decisão de último recurso desse utilizador, não uma solução confirmada para todos.
Preserve os dados da aplicação e a base de dados do Immich antes de reinstalar
O estado do Immich não se resume à pasta das fotografias. Preserve a base de dados, a configuração da aplicação e os caminhos das bibliotecas antes de eliminar contentores/volumes. O ZimaOS atual mantém dados importantes das aplicações fora dos contentores descartáveis.
Utilize o modelo atual de dados persistentes das aplicações do ZimaOS.
Não trate isto como uma regressão atual do Immich 1.7.1
A fonte refere-se especificamente ao ZimaOS 1.5.4 e a uma geração mais antiga do Immich. O ZimaOS atual e o Immich v3 são substancialmente mais recentes, por isso reproduza o erro exato atual antes de aplicar uma solução de 2026.
Reverter o Immich pode ser inseguro após migrações da base de dados
Um utilizador da fonte afirmou ter revertido para uma versão anterior do Immich. As atualizações de versões principais atuais podem migrar o estado da base de dados/aplicação, pelo que o suporte para downgrade deve seguir as orientações da versão correspondente do Immich, em vez de simplesmente alterar uma etiqueta de imagem para uma versão anterior.
Um conflito de portas exige a identificação do processo que já está a escutar
O erro da fonte indica explicitamente que o Docker não conseguiu associar a porta 2283 do anfitrião porque ela já estava atribuída. Isto pode acontecer quando um contentor antigo do Immich ainda está em execução, quando uma segunda pilha utiliza a mesma porta ou quando outro serviço foi aí associado.
Antes de eliminar qualquer elemento, identifique o contentor/processo que está atualmente a utilizar a porta e decida qual a pilha que deve ser a sua proprietária.
Um mosaico de aplicação desativado pode ser um sintoma do estado do Docker, não de perda de dados do Immich
Para o autor original, reiniciar o Docker restaurou todas as aplicações. Isto significa que o estado desativado do Immich resultava do runtime dos contentores, não sendo prova de que a base de dados de fotografias ou a biblioteca tivessem sido apagadas.
Outro participante não recuperou o Immich com o mesmo reinício, demonstrando por que motivo o sintoma apresentado pela interface, por si só, não é suficiente para diagnosticar a causa principal.
Leia a falha do Compose antes de reinstalar
“Falha ao iniciar a aplicação Compose” é uma mensagem genérica. As informações úteis estão na mensagem do serviço/contentor subjacente: conflito de portas, volume em falta, falha de verificação da base de dados, problema ao obter a imagem, YAML inválido ou problema de permissões.
Preserve os registos da falha antes de recriar a pilha; uma reinstalação pode apagar as informações necessárias para a análise.
O Immich v3 atual torna os downgrades cegos mais perigosos
Desde então, o Immich passou por alterações importantes ao nível do esquema e da implementação. Uma base de dados moderna do v3 pode não ser segura para utilização com uma imagem antiga arbitrária, apenas porque um utilizador de 2026 conseguiu reverter uma versão v1.x no passado.
Siga as orientações atuais do Immich para migração/downgrade e mantenha cópias de segurança verificadas da base de dados e da biblioteca antes de efetuar alterações de versão principal.
Se for necessário reinstalar, preserve primeiro os caminhos persistentes
Registe a biblioteca de fotografias, os dados do PostgreSQL, a configuração, os caminhos de aprendizagem automática/cache e os mapeamentos de volumes atuais. Remover contentores descartáveis é muito diferente de eliminar essas pastas persistentes no anfitrião.
Uma reinstalação limpa bem-sucedida deve voltar a associar os dados persistentes pretendidos ou restaurá-los através de um método de cópia de segurança suportado — não exigir a cópia integral da única biblioteca de fotografias a partir do zero.
Perguntas frequentes sobre a falha do Immich 1.5.4
Reiniciar o Docker resolveu o problema do Immich para o autor original?
Sim.
Resolveu o problema de todos os utilizadores no tópico?
Não. O Immich de outro utilizador continuou a falhar e, mais tarde, apresentou um conflito na porta 2283.
Os utilizadores atuais devem reinstalar imediatamente o Immich?
Não. Verifique primeiro o estado do serviço Docker, o estado do Compose, a utilização da porta e os dados persistentes.
