Quando o Jellyfin, o Emby ou o Plex conseguem ver apenas o ZimaOS-HD e não o HDD, o NVMe ou o RAID onde os seus ficheiros multimédia estão realmente armazenados, o problema normalmente não é o facto de o Docker “não ter permissões para aceder ao NAS”. Um contentor só consegue navegar pelas pastas do anfitrião que o ZimaOS mapeia para dentro dele como volumes.
Esta foi a correção central na discussão de origem de junho de 2024. ETWang1991 disse aos utilizadores para abrirem as definições da aplicação e adicionarem o novo armazenamento como volume. O autor original respondeu que, depois disso, funcionou “às mil maravilhas”, e outro utilizador do Jellyfin chegou mais tarde à mesma conclusão depois de ver as capturas de ecrã.
Uma aplicação Docker não vê todo o sistema de ficheiros do anfitrião ZimaOS
O isolamento do contentor é intencional. O Jellyfin consegue ver /Media dentro do respetivo contentor apenas se esse caminho tiver sido mapeado para um diretório real do anfitrião que contenha os ficheiros multimédia.
O facto de uma unidade aparecer em Ficheiros do ZimaOS não a torna automaticamente visível dentro de todos os contentores da App Store.
Abra as definições da aplicação e edite os volumes
Escolha a pasta Media real no anfitrião
Escolha o diretório no espaço de armazenamento real que contém a sua biblioteca, em vez de introduzir um caminho de nível superior presumido, como /Main-Storage.
Os caminhos do anfitrião e do contentor têm funções diferentes
O caminho no lado do contentor deve ser simples e estável, como /media ou /Media. Dentro do Jellyfin, adicione bibliotecas utilizando esse caminho do contentor — não o caminho bruto do anfitrião.
Vários utilizadores confirmaram que o mapeamento de volumes era o passo em falta
O autor original disse que a alteração funcionou. Outro utilizador com um armazenamento principal RAID 5 via inicialmente apenas o disco do sistema operativo e, em seguida, respondeu que as capturas de ecrã lhe deram a ideia: “Tive de adicionar os volumes ao Jellyfin.”
Trata-se de uma resolução confirmada pela fonte, e não de uma solução alternativa especulativa relacionada com permissões.
Os discos adicionados individualmente foram um problema de usabilidade da interface em 2024
Alguns participantes tiveram dificuldades em selecionar discos ativados individualmente ou armazenamento RAID no seletor antigo. A equipa da IceWhale respondeu que era possível ativar e utilizar unidades individuais e, mais tarde, afirmou que a interface tinha sido melhorada.
Essas limitações de 2024 pertencem às primeiras versões do ZimaOS. Atualmente, as definições de armazenamento e das aplicações do ZimaOS apresentam o armazenamento gerido de forma muito mais clara.
O ZimaOS atual documenta explicitamente os caminhos de armazenamento das aplicações
A documentação atual da IceWhale explica agora que os contentores da App Store guardam os dados persistentes em pastas reais do anfitrião e que os mapeamentos de volumes de cada aplicação podem ser consultados e alterados nas respetivas definições.
Utilize o modelo atual de caminhos de aplicações Docker do ZimaOS ao mapear o Jellyfin, o Emby, o Plex ou outra aplicação.
A localização dos dados da aplicação e a localização dos conteúdos multimédia são separadas
Os ficheiros de configuração/base de dados da aplicação podem ficar na localização configurada para os dados da aplicação, enquanto os ficheiros multimédia grandes ficam noutro conjunto RAID ou de discos rígidos. Não aponte o volume de configuração da aplicação para a pasta de filmes nem parta do princípio de que mover os dados da aplicação move toda a biblioteca multimédia.
O ZimaOS atual pode mover dados de aplicações geridas
A migração de dados atual pode mover imagens Docker e dados de aplicações Docker para outro espaço de armazenamento. Isto resolve um problema diferente do da adição de um volume de multimédia: um controla onde a própria aplicação guarda o estado persistente; o outro dá ao contentor acesso aos conteúdos multimédia do utilizador.
Consulte o fluxo de trabalho atual para a migração de dados de aplicações geridas.
Escolha montagens de suportes só de leitura quando a aplicação não precisar de modificar ficheiros
Um servidor multimédia normalmente precisa de ler filmes e música, mas não necessita necessariamente de ter permissão para eliminar ou reorganizar a biblioteca de origem. Quando o pacote atual da aplicação o permite, mapear os ficheiros multimédia como só de leitura reduz os danos que um contentor comprometido ou mal configurado pode causar.
As aplicações que renomeiam, movem ou importam ficheiros intencionalmente — como algumas soluções de gestão de transferências ou fotografias — necessitam de um modelo diferente de permissões de escrita.
O mapeamento do volume e as permissões do sistema de ficheiros são verificações distintas
Adicionar a pasta correta do anfitrião é o primeiro requisito. O processo do contentor também tem de ter permissões suficientes no sistema de ficheiros para ler ou escrever nessa pasta. Se um diretório mapeado aparecer, mas abrir vazio ou devolver erros de permissão, identifique o UID/GID do contentor e o proprietário no anfitrião antes de utilizar permissões demasiado abrangentes. chmod 777 soluções alternativas.
O problema na fonte de 2024 era sobretudo a ausência do mapeamento do volume; os problemas de permissões posteriores só devem ser diagnosticados depois de o caminho correto estar efetivamente montado.
Mantenha o caminho do lado do contentor estável durante as reinstalações
Se a biblioteca do Jellyfin tiver sido criada com base em /Media, alterando o caminho do contentor para /mnt/media2 durante uma reinstalação pode fazer com que a biblioteca existente pareça desaparecida, mesmo que os ficheiros do anfitrião nunca tenham sido movidos.
Preserve o mesmo caminho do lado do contentor sempre que possível ou atualize deliberadamente a configuração da biblioteca da aplicação depois de alterar o mapeamento.
A interface atual é melhor do que o seletor de 2024, mas a regra do Docker não mudou
A IceWhale reconheceu na fonte que o antigo seletor de armazenamento era confuso e, mais tarde, melhorou a interface. O ZimaOS atual expõe agora de forma mais direta a localização dos dados das aplicações, os caminhos do anfitrião/contentor, a migração do armazenamento e a utilização da cache das aplicações.
A regra subjacente do Docker mantém-se: um contentor só vê aquilo que lhe é montado.
Perguntas frequentes sobre o acesso ao armazenamento das aplicações
Porque é que o Files do ZimaOS consegue ver uma unidade, mas o Jellyfin não?
O Files é executado ao nível do anfitrião; o Jellyfin é executado dentro de um contentor e vê apenas os volumes mapeados.
A adição do volume foi confirmada como funcional no tópico de origem?
Sim. Vários utilizadores relataram sucesso depois de adicionarem o volume de armazenamento.
O Jellyfin deve navegar pelo caminho bruto do anfitrião?
Não. O Jellyfin deve navegar pelo caminho do lado do contentor atribuído à pasta do anfitrião mapeada.
