Como reconstruir uma configuração do Jellyfin depois de mudar para uma nova rede

Reconstrua o Jellyfin após uma mudança de rede, restaurando primeiro o caminho do serviço local e, em seguida, validando os pontos de montagem do armazenamento, a identidade, o DNS e o acesso remoto em etapas separadas.

Um novo router, uma sub-rede, uma VLAN ou um domínio DNS podem fazer uma base de dados do Jellyfin em bom estado parecer avariada, porque os clientes, os pontos de montagem e os proxies inversos deixam de partilhar o mesmo caminho. Guarde as notas da rede antiga e uma cópia dos dados da aplicação. O objetivo é assegurar um caminho conhecido do cliente ao serviço e aos conteúdos multimédia, com um ponto de paragem claro caso a camada com falhas seja a própria rede e não o Jellyfin.

Registe o caminho antigo antes de alterar seja o que for

Anote o endereço do servidor, o nome do anfitrião, a sub-rede, o gateway, o nome DNS, os caminhos dos conteúdos multimédia montados, o destino do proxy inverso, o nome do certificado e quaisquer regras da firewall ou de encaminhamento de portas. Separe a transmissão local da transmissão remota. Se o anfitrião antigo ainda estiver disponível, exporte a configuração do Jellyfin e faça uma lista dos utilizadores e das bibliotecas antes de atribuir novos endereços.

Isto cria a base para a reconstrução: um utilizador acede ao serviço, o serviço acede à sua base de dados e aos conteúdos multimédia, e as cópias de segurança chegam ao seu destino. Não comece por abrir uma porta pública nem por criar uma nova regra de proxy.

Restaure o serviço local num endereço estável

Atribua ao servidor uma reserva DHCP ou um endereço estático e, em seguida, confirme que a interface Web do Jellyfin abre na mesma LAN. Verifique o endereço de associação do serviço e a firewall do anfitrião e teste um cliente local antes de alterar o DNS. Se a aplicação iniciar, mas as bibliotecas estiverem vazias, pare e verifique o caminho de armazenamento em vez de recriar a base de dados.

As orientações de migração do Jellyfin salientam que os dados internos dependem dos caminhos e que os caminhos dos contentores têm de corresponder às localizações dos conteúdos multimédia registadas (orientações de migração sensíveis aos caminhos). Considere uma incompatibilidade de caminhos uma falha de topologia, não uma falha de metadados.

Volte a ligar as montagens e configure as permissões antes do DNS

Volte a ligar os volumes de multimédia e de cópias de segurança em caminhos estáveis e, em seguida, teste o acesso de leitura com a conta de serviço do Jellyfin. Verifique um ficheiro por biblioteca e uma escrita no diretório de dados da aplicação. Mantenha a cache e as capas transferidas em armazenamento recuperável, enquanto os ficheiros multimédia dos utilizadores, a base de dados e as cópias de segurança permanecem em funções protegidas.

A verificação é APROVADA quando um reinício recria as montagens antes de o Jellyfin arrancar e uma análise da biblioteca não gera avisos de ficheiros em falta. Se a montagem depender de um início de sessão interativo, corrija a ordem de arranque antes de continuar.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Reconstrua a identidade, o DNS e o acesso remoto por esta ordem

Depois de a reprodução local funcionar, restaure o nome de anfitrião e o registo DNS interno. Teste um cliente usando o nome, não o IP, e depois valide o proxy inverso ou a VPN a partir do exterior de casa. Mantenha a autenticação e a autorização separadas do encaminhamento: uma falha de início de sessão não é prova de que o novo reencaminhamento de portas esteja errado.

Execute uma reprodução direta e uma transcodificação com a combinação real de clientes. Registe o ponto final observado, o modo de reprodução e o ponto da falha. Um caso de migração da comunidade é útil para comparar pressupostos sobre os caminhos e a rede, mas não generalize as definições de hardware ou do router (estudo de caso de migração).

Torne explícitos o rollback e a expansão

Mantenha o registo DNS antigo, a cópia de segurança da configuração e as notas anteriores sobre a rede até que a reprodução local, o acesso dos utilizadores, o encaminhamento remoto e a recuperação tenham sido todos testados com sucesso. Expanda apenas adicionando um caminho dedicado, como uma VLAN separada para gestão ou uma segunda interface de rede, quando o caminho partilhado sofrer degradação. Interrompa a reconstrução se o servidor não conseguir obter um endereço estável, montagens persistentes ou uma rota de recuperação testada; nenhuma reconfiguração dos clientes resolve a falta destas bases.