Solução da comunidade

A partilha de rede do ZimaOS desaparece após reiniciar: por que motivo o Plex e o Emby perdem os dados do NAS remoto

A December 2025 thread where Plex and Emby running on ZimaOS lost access to an Unraid network share after about a week or a reboot. Reconnecting the share in Files and restarting apps restored access, but the thread ended without an IceWhale-confirmed persistent app-mount solution.

A configuração de origem utilizava o ZimaOS como servidor de aplicações, mantendo todos os conteúdos multimédia num NAS Unraid existente. O Plex, o Emby e o OpenWebUI eram executados no ZimaOS e, inicialmente, acediam aos dados remotos sem problemas. Após cerca de uma semana — e novamente depois de um reinício — a partilha de rede desapareceu do ambiente das aplicações. Voltar a ligá-la em Ficheiros e reiniciar as aplicações repôs o acesso.

Isto expõe um limite de conceção importante nas implementações com “nó de computação + NAS separado”: uma localização de rede visível na aplicação Ficheiros não é automaticamente o mesmo que uma montagem persistente no anfitrião, da qual todos os contentores Docker possam depender após reinícios e eventos de reconexão.

As aplicações perderam os conteúdos multimédia porque a partilha remota desapareceu

Não foi reportado que o Plex e o Emby tivessem falhas nas bases de dados. Simplesmente perderam os caminhos que apontavam para os dados no Unraid. Quando o utilizador voltou a adicionar a partilha, as aplicações começaram a reconstruir as bibliotecas ou a procurar novamente os conteúdos.

Isto aponta para um problema de acessibilidade do armazenamento, não para uma instalação corrompida do Plex ou do Emby.

O acesso através de Ficheiros e o acesso a volumes Docker são camadas diferentes

O Ficheiros do ZimaOS pode ligar-se ao Armazenamento LAN através de SMB. Essa ligação permite ao utilizador procurar e mover ficheiros a partir da interface Web.

Uma aplicação Docker precisa de um caminho no anfitrião que permaneça disponível quando o contentor é iniciado. Se a montagem de rede subjacente desaparecer ou for recriada com um ciclo de vida diferente, a aplicação pode ver um caminho vazio ou inexistente, mesmo que o Ficheiros consiga voltar a ligar-se mais tarde.

A recomendação sobre UUID não se aplica a uma partilha SMB normal

Uma resposta sugeria montar a partilha “utilizando um UUID”. Outro participante observou corretamente que a partilha Unraid remota estava ligada através de IP/SMB, e não como um dispositivo de blocos local.

Os UUID são úteis para identificar sistemas de ficheiros e dispositivos de blocos locais. Uma partilha SMB é identificada através do caminho do servidor/partilha de rede, das credenciais e da configuração de montagem.

Uma resposta da comunidade sugeriu o uso de /etc/fstab

Outro participante afirmou que uma montagem SMB persistente em /etc/fstab tinha sido estável no seu caso. Esta é uma prática convencional de administração Linux e pode funcionar, mas tratava-se de um conselho da comunidade e o autor original não confirmou uma configuração final funcional.

Num sistema operativo de tipo appliance, a configuração manual de montagens no anfitrião também significa que ficará responsável pela ordem de arranque, pelas credenciais, pelo comportamento de reconexão e pela compatibilidade entre atualizações.

O ZimaOS atual continua a suportar o Armazenamento LAN no Ficheiros

A documentação atual da IceWhale mostra como adicionar Armazenamento LAN a partir da barra lateral do Ficheiros, introduzindo o endereço IP do NAS remoto e as credenciais. Esta é a forma suportada de procurar ou migrar dados de outro NAS.

Utilize o fluxo de ligação atual ao Armazenamento LAN quando o objetivo for aceder a ficheiros ou migrar dados.

O tópico não estabeleceu um método suportado para montagens persistentes de aplicações

Nenhum programador da IceWhale respondeu com um procedimento documentado para “montar permanentemente esta partilha SMB para aplicações Docker”, e o autor original continuou cético quanto à capacidade de a ligação através do Ficheiros sobreviver ao ciclo de vida observado.

Um artigo rigoroso deve preservar este estado não resolvido, em vez de apresentar a sugestão da comunidade relativa ao fstab como a solução oficial.

Para um servidor multimédia, decida onde fica o limite da montagem estável

Se o Plex e o Emby tiverem de recuperar automaticamente após uma falha de energia, o caminho remoto para os conteúdos multimédia tem de ser montado antes de os contentores serem iniciados e permanecer estável durante as reconexões. Isto pode ser conseguido através de várias arquiteturas Linux, mas a opção exata deve ser testada na versão atual do ZimaOS.

Em configurações permanentes de grande importância, valide um reinício a frio, o reinício do NAS remoto, o reinício do switch e uma perda temporária de rede antes de considerar o caminho de armazenamento pronto para produção.

Evite novas análises desnecessárias dos conteúdos multimédia

Quando uma partilha multimédia desaparece temporariamente, o Plex ou o Emby podem interpretar isso como remoção de conteúdos, dependendo das definições da biblioteca. Evite a limpeza automática e destrutiva da biblioteca até o comportamento da montagem remota estar comprovadamente estável.

Perguntas frequentes sobre montagens de aplicações a partir de NAS remoto

Voltar a ligar a partilha no Ficheiros repôs o acesso das aplicações?

Os utilizadores relataram que voltar a ligar a partilha e reiniciar as aplicações repôs o acesso.

É possível montar uma partilha SMB através do UUID do sistema de ficheiros?

Não no mesmo sentido que um disco local. O SMB utiliza um caminho de partilha de rede e credenciais.

A IceWhale publicou neste tópico uma solução confirmada para montagens persistentes de aplicações Docker?

Não. O tópico público terminou sem uma solução desse tipo.