Solução da comunidade

As aplicações Docker do ZimaOS perdem um NAS SMB após um reinício: como corrigir o problema

Plex and Radarr lost access to a Synology SMB share after each reboot until the same ZimaOS folder mapping was manually reselected.

Se o Plex, o Radarr, o Sonarr ou outra aplicação Docker perder o acesso a um NAS SMB remoto após cada reinício do ZimaOS, verifique a montagem no anfitrião antes de alterar a aplicação. O contentor só consegue ver uma partilha de rede se o ZimaOS a tiver montado com sucesso e o caminho de ligação do Docker continuar a apontar para esse local montado.

Um caso da comunidade envolvendo uma partilha Synology recuperava sempre que o utilizador selecionava novamente a mesma pasta no seletor de caminhos do Docker Compose. Isso sugere fortemente um problema de persistência da montagem/caminho, mas a explicação no fórum de que o ZimaOS gerava sempre um novo ID interno de montagem era uma interpretação da comunidade, não uma causa-raiz confirmada pela IceWhale. Um bom guia deve, por isso, resolver separadamente os problemas de montagem, caminho e ordem de arranque.

Confirme primeiro se a partilha SMB está montada após o reinício

Antes de abrir o Plex ou o Radarr, abra os Ficheiros do ZimaOS e navegue até à partilha do NAS remoto. Se a própria partilha estiver indisponível, a aplicação Docker não é o primeiro problema.

Se a partilha estiver em falta

Verifique se o NAS remoto está online, se o respetivo IP/nome de anfitrião continua a ser resolvido, se o SMB está ativado e se as credenciais guardadas continuam válidas. Volte a ligar a partilha através do fluxo de armazenamento de rede do ZimaOS, se necessário.

Se a partilha estiver visível em Ficheiros

Em seguida, passe ao mapeamento do Docker. A montagem no anfitrião existe, mas a aplicação pode continuar a referenciar um caminho obsoleto ou indisponível.

Utilize o armazenamento de rede do ZimaOS em vez de uma entrada fstab escrita manualmente

O utilizador ponderou editar /etc/fstab. Essa não é a melhor solução inicial num sistema operativo do tipo appliance que já gere o armazenamento de rede através da sua interface.

A documentação atual do ZimaOS mostra o acesso baseado em SMB a outro NAS como parte dos fluxos de migração e armazenamento de rede. Utilize primeiro esse processo gerido, para que o ZimaOS possa tratar as credenciais e o estado da montagem de forma consistente.

O guia de migração de NAS do ZimaOS fornece a referência atual.

Verificar o caminho do anfitrião do Docker, não apenas o caminho do contentor

Os mapeamentos de volumes do Docker têm dois lados:

  • caminho do anfitrião: onde o ZimaOS vê a pasta Synology montada;
  • caminho do contentor: o caminho estável que o Plex, o Radarr ou o Sonarr vê dentro do contentor.

Se o lado do anfitrião for inválido após o reinício, o caminho do contentor poderá continuar a parecer correto na interface da aplicação, embora não aponte para nada útil.

O guia de caminhos Docker do ZimaOS atual explica esta distinção.

Voltar a selecionar a pasta uma vez como teste de diagnóstico

Se a partilha remota estiver visível em Ficheiros, mas a aplicação não conseguir aceder-lhe, abra a configuração da aplicação ou do Compose e volte a selecionar a pasta do anfitrião utilizando o seletor de caminhos do ZimaOS.

Se o acesso for reposto imediatamente sem alterar as credenciais nem os caminhos dos contentores, terá fortes indícios de que a falha está entre a montagem gerida e o mapeamento de ligação do Docker.

Verificar a ordem de arranque após cada reinício

O armazenamento SMB remoto depende da rede, da acessibilidade por DNS/IP, da autenticação e de o NAS estar pronto. Os contentores Docker podem iniciar mais depressa do que a montagem remota fica disponível.

Teste simples

  1. reinicie o ZimaOS;
  2. aguarde até a partilha remota estar navegável em Ficheiros;
  3. reinicie apenas a aplicação Docker afetada;
  4. verifique se os conteúdos multimédia ou as transferências reaparecem.

Se isso funcionar de forma fiável, o caminho poderá ser estável e o verdadeiro problema poderá estar no momento do arranque, e não na alteração dos identificadores da montagem.

Verificar as permissões em ambos os sistemas

A conta Synology utilizada para a montagem SMB tem de ter acesso às pastas multimédia. Depois, a montagem no ZimaOS tem de estar acessível ao processo do Docker. Por fim, a aplicação tem de utilizar o caminho correto dentro do contentor.

Os problemas de permissões podem parecer semelhantes a uma montagem em falta, por isso verifique separadamente “acesso negado” e “caminho não encontrado” ou “ficheiro inexistente”.

Porque as alterações manuais no fstab podem dificultar a recuperação

Uma montagem personalizada pode introduzir ficheiros de credenciais, dependências de arranque, opções de temporização e comportamentos de falha que o ZimaOS não gere na sua interface. Se essa montagem personalizada falhar durante o arranque, as aplicações podem continuar a iniciar utilizando um diretório vazio.

Utilize fstab apenas quando o fluxo de trabalho de armazenamento de rede gerido não conseguir satisfazer um requisito e estiver preparado para manter a montagem entre atualizações.

Como tornar as aplicações multimédia mais resilientes

  • Utilize um IP estável do NAS ou um nome DNS local fiável.
  • Mantenha a partilha remota configurada através do Armazenamento de rede.
  • Mapeie uma pasta estável do anfitrião para o contentor.
  • Utilize o mesmo caminho do contentor de forma consistente no Radarr, Sonarr, clientes de transferências e servidores multimédia.
  • Após atualizações ou alterações ao armazenamento, verifique a montagem antes de alterar as bibliotecas das aplicações.

O guia de resolução de problemas da LAN ajuda a determinar se a falha começa na camada de rede, enquanto os conceitos básicos dos caminhos Docker fornecem o contexto do Docker.

Perguntas frequentes

Porque é que as minhas aplicações Docker perdem uma partilha Synology depois de o ZimaOS reiniciar?

As camadas mais prováveis são a partilha SMB não voltar a ser montada, a aplicação utilizar um caminho do anfitrião desatualizado ou o contentor iniciar antes de a partilha remota estar pronta. Teste cada uma separadamente.

Devo editar o /etc/fstab?

Não como primeira solução. Prefira o Armazenamento de rede do ZimaOS, para que o sistema faça a gestão da partilha. As montagens manuais acrescentam manutenção e complexidade à ordem de arranque.

Porque é que voltar a selecionar a mesma pasta corrige a aplicação?

Atualiza o mapeamento de montagem do lado do anfitrião. Isso é uma indicação de um problema de montagem/caminho, mesmo quando o nome visível da pasta não mudou.

Posso utilizar uma partilha SMB remota para o Plex e as aplicações Arr?

Sim, desde que o ZimaOS o monte de forma fiável, as permissões estejam corretas e todos os contentores utilizem caminhos consistentes no anfitrião e no contentor.