Come ripristinare le autorizzazioni di Jellyfin dopo aver spostato la sua directory dei dati
Dopo aver spostato la directory dei dati di Jellyfin, ripristina i permessi assegnando ai file spostati l'identità con cui Jellyfin è effettivamente in esecuzione e verificando che il container o il servizio punti al percorso previsto. Non iniziare con chmod -R 777.
Uno spostamento può modificare la proprietà numerica, le ACL ereditate, le opzioni di montaggio, le etichette SELinux o l'UID/GID utilizzato da un container ricreato. Diagnostica questi livelli in quest'ordine, correggi solo i dati di proprietà di Jellyfin, quindi avvia il server e verifica le scritture nel database, nei metadati, nei backup e nelle attività pianificate prima di intervenire sui permessi della libreria multimediale.
Conferma il nuovo percorso e l'identità di runtime di Jellyfin
Arresta Jellyfin prima di riparare i dati dell'applicazione spostati, così le scritture in background non interferiscono con l'ispezione. Conferma il nuovo percorso host, il percorso visibile a Jellyfin all'interno del container o del servizio e l'UID/GID dell'identità con cui Jellyfin è in esecuzione.
Le indicazioni di migrazione di Jellyfin consigliano esplicitamente di determinare uid e gid dell'utente Jellyfin e di mantenere i percorsi previsti durante la migrazione. Indicazioni di Jellyfin sugli UID/GID per la migrazione
Se il container punta alla directory host sbagliata, correggi prima il montaggio. Le autorizzazioni non possono correggere una mappatura dei percorsi che indirizza Jellyfin a una cartella vuota; avviandolo su quel percorso vuoto potrebbe creare un secondo albero di dati nuovo.
Esamina la proprietà, i bit dei permessi e le ACL prima di modificarli
Elenca il proprietario e il gruppo numerici della directory spostata e di alcuni esempi delle sue sottodirectory di database, configurazione, metadati e log. Controlla i permessi di esecuzione delle directory genitrici e le eventuali voci ACL ereditate dal filesystem di destinazione.
Lo spostamento su un NAS può introdurre un modello diverso di identità e autorizzazioni, soprattutto quando sono coinvolti SMB, NFS o container. La diagnostica delle autorizzazioni dopo lo spostamento di ZimaSpace spiega perché un punto di montaggio visibile non aggira l'autorizzazione UID/GID del processo del container.
Non modificare nulla finché non puoi descrivere con precisione la discrepanza: proprietario errato, accesso al gruppo mancante, attraversamento della directory genitore bloccato, ACL imprevista o montaggio in sola lettura. Questa descrizione determina la riparazione sicura più circoscritta.
Ripristina la proprietà solo sui dati dell'applicazione di proprietà di Jellyfin
Se la directory dei dati di Jellyfin spostata deve appartenere all'account di servizio Jellyfin, ripristina il proprietario e il gruppo previsti su quell'albero di dati dell'applicazione. Mantieni la proprietà dei contenuti multimediali condivisi non correlati, a meno che Jellyfin non debba davvero gestire quei file.
La documentazione sulla migrazione di Jellyfin include la correzione della proprietà della directory dei dati di Jellyfin dopo lo spostamento. correzione della proprietà dopo la migrazione Considerala un'operazione mirata sui dati dell'applicazione, non un motivo per assegnare ricorsivamente la proprietà di un'intera condivisione NAS.
Dopo aver corretto la proprietà, controlla di nuovo un elemento di esempio ed esegui, con l'identità di Jellyfin, una verifica non distruttiva della possibilità di scrittura in una sottodirectory di test dedicata. Se la scrittura continua a essere negata, interrompi le modifiche a chmod e controlla le ACL, la modalità di mount o l'etichettatura di sicurezza.
Controlla la modalità di mount e l'etichettatura di sicurezza del container
Anche con la proprietà corretta sull'host, l'accesso può non funzionare all'interno di un container se il mount bind è in sola lettura, l'utente di runtime è cambiato o il sistema di sicurezza dell'host blocca il percorso. Confronta la definizione attuale del container con l'ultima funzionante.
La guida di Jellyfin per i container mostra l'esecuzione con UID/GID espliciti, i mount dei contenuti multimediali in sola lettura e le opzioni di rietichettatura di Podman per gli ambienti SELinux. autorizzazioni e rietichettatura dei container Questi controlli possono prevalere su ciò che i normali bit di autorizzazione Unix sembrano consentire.
Modifica solo il livello per cui hai confermato il problema. Rendi scrivibile il mount dei dati dell'applicazione se Jellyfin deve scriverci, ripristina l'UID/GID corretto del processo in esecuzione oppure applica a quel mount l'etichetta appropriata per la piattaforma. Poi ricrea il container una sola volta e ricontrolla lo stesso percorso dall'interno.
Avvia Jellyfin e verifica le scritture nel database e nella directory dati
Avvia Jellyfin e segui il log di avvio. Verifica che apra lo stato del server esistente e non una procedura guidata di configurazione o una libreria vuota, e controlla che non vi siano errori di autorizzazione relativi a database, configurazione, metadati o log.
Se l'avvio raggiunge il normale pannello di controllo, avvia un'operazione a basso rischio che scriva nello stato gestito da Jellyfin, ad esempio un'attività pianificata o un'azione sui metadati in un contesto di test, e verifica che il file o lo stato del database previsto cambi senza errori di autorizzazione.
Riavvia Jellyfin ancora una volta. La riparazione è completa solo se, dopo un nuovo avvio, si apre correttamente la stessa directory dati; un successo in una sola sessione può nascondere un problema di mount o inizializzazione che si ripresenta alla ricreazione.
Annulla le modifiche troppo ampie e procedi all'escalation con prove precise
Se hai già applicato autorizzazioni ricorsive troppo ampie e il server continua a non funzionare, non continuare ad ampliare l'accesso. Se possibile, ripristina la proprietà registrata o un backup, poi torna a verificare la specifica discrepanza tra identità del processo in esecuzione e percorso.
Per i server containerizzati, confronta l'origine e la destinazione del mount attuali, UID/GID, gruppi e contesto di sicurezza con la configurazione funzionante salvata. Per le installazioni native, confronta l'identità del servizio e il comportamento del mount e delle ACL del filesystem di destinazione. L'obiettivo è avere un unico modello di autorizzazioni facilmente spiegabile.
Fermati quando Jellyfin apre il database originale, scrive nelle proprie directory dati, completa l'operazione in background scelta e si riavvia senza problemi. Se anche uno solo di questi controlli continua a fallire, procedi all'escalation fornendo la proprietà numerica, l'output delle ACL, le opzioni di mount, UID/GID del processo in esecuzione e il primo errore di log relativo alle autorizzazioni, se presente.
Prodotti consigliati
Assistenza e consigli
Altre letture
Cosa controllare prima di caricare un modello della community in Transformers
Usa l’aggiornamento della sandbox Jinja di Transformers per esaminare la provenienza dei modelli, i template di chat, il codice remoto, i pesi serializzati e...
Esegui Mirage in locale: OCR e rilevamento degli oggetti da una sola immagine
Prova il piccolo modello di visione locale di Cactus Compute, verifica l’OCR e l’estrazione degli oggetti con input reali e comprendi i limiti di...
Come pianificare un agente di programmazione in Open WebUI su un server domestico
Configura un'automazione di un agente di programmazione in modalità di sola reportistica in Open WebUI, seleziona il terminale e l'area di lavoro, quindi verifica...
