Como restaurar as permissões do Jellyfin depois de mover o diretório de dados

Depois de mover o diretório de dados do Jellyfin, restaure as permissões associando os ficheiros movidos à identidade que realmente executa o Jellyfin e confirmando que o contentor ou serviço aponta para o caminho pretendido. Não comece por executar chmod -R 777.

Uma movimentação pode alterar a propriedade numérica, as ACL herdadas, as opções de montagem, as etiquetas SELinux ou o UID/GID utilizado por um contentor recriado. Diagnostique essas camadas por esta ordem, corrija apenas os dados pertencentes ao Jellyfin e, em seguida, inicie o servidor e verifique as escritas na base de dados, nos metadados, nas cópias de segurança e nas tarefas agendadas antes de mexer nas permissões da biblioteca multimédia.

Confirme o Novo Caminho e a Identidade de Execução do Jellyfin

Pare o Jellyfin antes de reparar os dados da aplicação movidos, para que as escritas em segundo plano não interfiram com a sua inspeção. Confirme o novo caminho no anfitrião, o caminho que o Jellyfin vê dentro do contentor ou serviço e o UID/GID da identidade Jellyfin em execução.

As orientações de migração do Jellyfin recomendam explicitamente determinar o uid e o gid do utilizador do Jellyfin e preservar os caminhos esperados durante a migração. Orientações do Jellyfin sobre UID/GID na migração

Se o contentor apontar para o diretório errado no anfitrião, corrija primeiro a montagem. As permissões não podem corrigir um mapeamento de caminho que envia o Jellyfin para uma pasta vazia, e iniciar o serviço nesse caminho vazio pode criar uma segunda árvore de dados nova.

Inspecione a Propriedade, os Bits de Modo e as ACL antes de os Alterar

Apresente o proprietário e o grupo numéricos do diretório movido e de uma amostra dos respetivos subdiretórios de base de dados, configuração, metadados e registos. Verifique as permissões de execução dos diretórios-pai e quaisquer entradas ACL que possam ter sido herdadas do sistema de ficheiros de destino.

Uma transferência para um NAS pode introduzir um modelo diferente de identidade e permissões, sobretudo quando estão envolvidos SMB, NFS ou contentores. O diagnóstico de permissões após a transferência da ZimaSpace explica por que razão uma montagem visível não contorna a autorização UID/GID do processo do contentor.

Não altere nada até conseguir descrever a incompatibilidade com precisão: proprietário incorreto, acesso de grupo em falta, passagem bloqueada pelo diretório-pai, ACL inesperada ou montagem só de leitura. Essa descrição determina a reparação segura mais pequena.

Restaure a Propriedade Apenas nos Dados da Aplicação Pertencentes ao Jellyfin

Se o diretório de dados movido do Jellyfin tiver de pertencer à conta de serviço do Jellyfin, restaure esse proprietário e grupo pretendidos nessa árvore de dados da aplicação. Preserve a propriedade de multimédia partilhada não relacionada, a menos que o Jellyfin precise realmente de gerir esses ficheiros.

A documentação de migração do Jellyfin inclui a correção da propriedade do diretório de dados do Jellyfin depois de uma transferência. correção da propriedade após a migração Considere isto uma operação direcionada aos dados da aplicação, não uma razão para assumir recursivamente a propriedade de uma partilha NAS inteira.

Depois de corrigir a propriedade, volte a inspecionar uma amostra e faça uma verificação não destrutiva da possibilidade de escrita, como a identidade Jellyfin, contra um subdiretório de teste dedicado. Se a escrita continuar a ser recusada, pare de adicionar alterações com chmod e inspecione em seguida as ACL, o modo de montagem ou a etiquetagem de segurança.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique o Modo de Montagem do Contentor e a Etiquetagem de Segurança

Um proprietário correto no anfitrião pode continuar a falhar dentro de um contentor se a montagem vinculada for só de leitura, se o utilizador de execução tiver mudado ou se o sistema de segurança do anfitrião bloquear o caminho. Compare a definição atual do contentor com a última que funcionava.

O guia de contentores do Jellyfin mostra a execução explícita com UID/GID, montagens de multimédia só de leitura e opções de reetiquetagem do Podman para ambientes SELinux. permissões e reetiquetagem de contentores Estes controlos podem sobrepor-se ao que os bits de modo Unix normais parecem permitir.

Altere apenas a camada confirmada. Torne a montagem dos dados da aplicação gravável se o Jellyfin tiver de escrever nela, restaure o UID/GID de execução correto ou aplique a etiqueta adequada à plataforma a essa montagem. Em seguida, recrie o contentor uma vez e volte a verificar o mesmo caminho a partir do interior.

Inicie o Jellyfin e Verifique as Escritas na Base de Dados e no Diretório de Dados

Inicie o Jellyfin e acompanhe o registo de arranque. Confirme que abre o estado existente do servidor, em vez de apresentar um assistente de configuração ou uma biblioteca vazia, e procure erros de permissões relativos à base de dados, configuração, metadados ou registos.

Se o arranque chegar ao painel normal, desencadeie uma operação de baixo risco que escreva no estado pertencente ao Jellyfin, como uma tarefa agendada ou uma ação de metadados num contexto de teste, e confirme que o ficheiro ou estado da base de dados esperado é alterado sem erros de permissões.

Reinicie o Jellyfin mais uma vez. A reparação só está concluída se o mesmo diretório de dados abrir corretamente depois de um arranque novo; um sucesso numa única sessão pode ocultar um problema de montagem ou inicialização que regressa quando o contentor é recriado.

Reverta Alterações Abrangentes e Escale o Problema com Evidências Exatas

Se já tiver aplicado permissões recursivas abrangentes e o servidor continuar avariado, não continue a alargar o acesso. Sempre que possível, restaure a partir da propriedade registada ou de uma cópia de segurança e volte a analisar a incompatibilidade específica entre a identidade de execução e o caminho.

Para servidores em contentores, compare a origem e o destino atuais da montagem, o UID/GID, os grupos e o contexto de segurança com a definição funcional guardada. Para instalações nativas, compare a identidade do serviço e o comportamento de montagem e ACL do sistema de ficheiros de destino. O objetivo é obter um modelo de permissões único e explicável.

Pare quando o Jellyfin abrir a base de dados original, escrever nos seus próprios diretórios de dados, concluir a operação em segundo plano escolhida e sobreviver ao reinício. Escale o problema com a propriedade numérica, o resultado das ACL, as opções de montagem, o UID/GID de execução e o primeiro erro de permissões no registo, caso alguma dessas verificações continue a falhar.