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

Depois de mover o diretório de dados do Jellyfin, restaure as permissões fazendo corresponder 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 usar chmod -R 777.

Uma mudança pode alterar a propriedade numérica, as ACL herdadas, as opções de montagem, as etiquetas SELinux ou o UID/GID usado num contentor recriado. Diagnostique essas camadas por essa 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 alterar as permissões da biblioteca multimédia.

Confirme o novo caminho e a identidade do Jellyfin em execução

Pare o Jellyfin antes de reparar os dados da aplicação movidos, para evitar que as escritas em segundo plano interfiram com a 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 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 conseguem corrigir um mapeamento de caminhos que encaminha o Jellyfin para uma pasta vazia, e iniciar o serviço com esse caminho vazio pode criar uma segunda árvore de dados nova.

Inspecione a propriedade, os bits de modo e as ACL antes de os alterar

Identifique o proprietário e o grupo numéricos do diretório movido e de algumas das suas subpastas de base de dados, configuração, metadados e registos. Verifique as permissões de execução dos diretórios principais e quaisquer entradas ACL que possam ter sido herdadas do sistema de ficheiros de destino.

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

Não altere nada até conseguir identificar precisamente a incompatibilidade: proprietário incorreto, acesso ao grupo em falta, travessia do diretório principal bloqueada, ACL inesperada ou montagem só de leitura. Essa identificaçã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 do Jellyfin movido deve pertencer à conta de serviço do Jellyfin, restaure o proprietário e o grupo pretendidos nessa árvore de dados da aplicação. Preserve a propriedade dos ficheiros multimédia partilhados não relacionados, a menos que o Jellyfin precise genuinamente de os gerir.

A documentação de migração do Jellyfin inclui a correção da propriedade do diretório de dados do Jellyfin após uma mudança. correção da propriedade após a migração Trate isso como uma operação específica sobre os dados da aplicação, não como motivo para atribuir recursivamente a propriedade de uma partilha NAS inteira.

Depois de corrigir a propriedade, volte a inspecionar um exemplo e faça um teste não destrutivo de escrita, como a identidade do Jellyfin, numa subpasta de teste dedicada. 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

NAS de nuvem pessoal doméstica ZimaCube 2

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 ainda assim não ter acesso 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 com UID/GID explícitos, montagens de suportes em modo só de leitura e opções de reetiquetagem do Podman para ambientes SELinux. permissões de contentores e reetiquetagem Estes controlos podem sobrepor-se ao que os bits normais de permissões Unix parecem permitir.

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

Inicie o Jellyfin e verifique a base de dados e as escritas no diretório de dados

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

Se o arranque chegar ao painel normal, inicie uma operação de baixo risco que escreva no estado gerido pelo 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 se altera 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 sem problemas após um novo arranque; um sucesso numa única sessão pode ocultar um problema de montagem ou inicialização que volta a surgir quando o contentor é recriado.

Reverta as alterações amplas e escale o problema com provas exatas

Se já aplicou permissões recursivas amplas e o servidor continua avariado, não continue a alargar o acesso. Sempre que possível, restaure a propriedade registada ou a cópia de segurança e, em seguida, volte à incompatibilidade específica entre a identidade de execução e o caminho.

Nos servidores em contentores, compare a origem e o destino da montagem atuais, o UID/GID, os grupos e o contexto de segurança com a definição funcional guardada. Nas instalações nativas, compare a identidade do serviço e o comportamento de montagem e das ACL do sistema de ficheiros de destino. O objetivo é ter um modelo de permissões que possa ser explicado.

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 voltar a funcionar após um reinício. Se algum destes controlos continuar a falhar, recolha a propriedade numérica, o resultado das ACL, as opções de montagem, o UID/GID de execução e o primeiro erro de registo relacionado com permissões.