Mover uma pasta de multimédia para outra unidade do ZimaOS não atualiza automaticamente todas as aplicações Docker que utilizavam o caminho antigo. Foi exatamente isso que aconteceu na fonte: os ficheiros de filmes foram movidos para um novo NVMe, o Radarr refletia a nova localização de armazenamento, mas o Jellyfin continuava a referenciar o antigo bind mount e já não conseguia encontrar o filme.
A solução é atualizar o caminho do volume no lado do anfitrião da aplicação, mantendo um caminho estável no lado do contentor, como /movies ou /media. O Zima-Giorgio mostrou tanto a deteção através da CLI como o seletor de pastas da interface gráfica, e o utilizador confirmou imediatamente que o método da interface gráfica resolveu o problema.
O Docker Tem um Caminho do Anfitrião e um Caminho do Contentor
Um mapeamento tem, conceptualmente, o seguinte aspeto:
/caminho/real/no/ZimaOS → /caminho/dentro/da/aplicaçãoO lado esquerdo tem de apontar para o dispositivo de armazenamento e a pasta onde os ficheiros estão realmente guardados. O lado direito é o caminho que o Jellyfin/Radarr vê dentro do contentor.
Um Segundo Dispositivo de Armazenamento do ZimaOS Não Fica Automaticamente Dentro de /DATA
/DATA/... criou uma pasta no armazenamento errado.Essa foi a principal confusão. /DATA/extra-movies referia-se à área de dados do sistema/predefinida, não automaticamente à pasta no novo NVMe.
O Zima-Giorgio Sugeriu Verificar /media
Para identificar manualmente o caminho do anfitrião, o Giorgio sugeriu:
ls /mediaNessa altura, o armazenamento autónomo/montado aparecia em /media. O caminho exato pode variar consoante a gestão atual do armazenamento e a designação do dispositivo, por isso use o caminho apresentado pela interface atual em vez de tentar adivinhá-lo.
O Seletor de Pastas da Interface Gráfica Foi a Solução Confirmada pela Fonte
O ZimaOS Atual Suporta Explicitamente a Atualização dos Caminhos dos Volumes Depois de Mover Dados
A documentação atual da IceWhale sobre os caminhos das aplicações indica agora que, quando uma unidade fica cheia, pode mover os dados de uma aplicação para outra unidade e atualizar o caminho nas definições da aplicação sem reinstalar a aplicação.
Utilize o fluxo de trabalho atual dos caminhos Docker do ZimaOS.
Mantenha o Caminho do Contentor Estável Sempre que Possível
Se o Jellyfin já utiliza internamente /Media, altere apenas o lado do anfitrião para a nova pasta física. Manter o caminho do contentor estável evita que a base de dados/biblioteca da aplicação passe a ver uma cadeia de caminho completamente diferente.
Atualize Todas as Aplicações Que Mapeiam a Pasta Movida
O Radarr, Sonarr, qBittorrent, Jellyfin, Plex e as ferramentas de importação podem ter os seus próprios mapeamentos de volumes. O facto de uma aplicação ver a nova pasta não atualiza as restantes.
Verifique Antes de Remover a Pasta Antiga
Abra um filme no Jellyfin, deixe o Radarr analisar a pasta raiz, teste os caminhos de importação do qBittorrent, se aplicável, e confirme as permissões. Mantenha a pasta de origem antiga até todas as aplicações utilizarem corretamente o novo mapeamento no anfitrião.
Mover Multimédia É Diferente de Mover AppData
As pastas de filmes e séries são bibliotecas de conteúdos comuns. A AppData pode conter bases de dados SQLite/PostgreSQL, miniaturas, índices e o estado da aplicação, que podem exigir que a aplicação seja parada ou que seja utilizada a Migração de Dados do ZimaOS para garantir a consistência. Não trate todos os volumes como uma simples pasta de multimédia que pode ser arrastada e largada.
Volte a Verificar as Permissões no Novo Armazenamento
Um novo caminho correto no anfitrião pode continuar a falhar se a identidade do contentor conseguir ler a unidade antiga, mas não a nova. Depois de alterar o mapeamento, verifique se a aplicação consegue ler — e, quando necessário, escrever — na pasta de destino, sem conceder permissões de escrita globais desnecessárias.
FAQ sobre Caminhos de Multimédia Movidos
Porque é que o Jellyfin deixou de encontrar os ficheiros depois de os mover?
O bind mount Docker continuava a apontar para a pasta antiga no anfitrião.
O utilizador da fonte confirmou que o seletor da interface gráfica ajudou?
Sim. Respondeu imediatamente que não sabia que o seletor de caminhos existia e que este resolveu a sua dúvida.
Devo escrever /DATA para cada nova unidade de armazenamento?
Não. Utilize o caminho real no anfitrião apresentado ou selecionado pelo ZimaOS para esse dispositivo de armazenamento.
