Jellyfin-machtigingen herstellen na het verplaatsen van de gegevensmap
Nadat je de gegevensmap van Jellyfin hebt verplaatst, herstel je de rechten door de verplaatste bestanden te koppelen aan de identiteit waaronder Jellyfin daadwerkelijk draait en te controleren of de container of service naar het juiste pad verwijst. Begin niet met chmod -R 777.
Een verplaatsing kan numeriek eigenaarschap, overgenomen ACL's, mountopties, SELinux-labels of de UID/GID die door een opnieuw aangemaakte container wordt gebruikt, wijzigen. Diagnoseer die lagen in die volgorde, herstel alleen gegevens die eigendom zijn van Jellyfin, start de server en controleer vervolgens of de database, metadata, back-ups en geplande taken kunnen worden geschreven voordat je de rechten van de mediabibliotheek aanpast.
Bevestig het nieuwe pad en de runtime-identiteit van Jellyfin
Stop Jellyfin voordat je de verplaatste applicatiegegevens herstelt, zodat achtergrondschrijfacties je inspectie niet doorkruisen. Bevestig het nieuwe pad op de host, het pad dat Jellyfin binnen de container of service ziet en de UID/GID van de actieve Jellyfin-identiteit.
De migratierichtlijnen van Jellyfin raden expliciet aan de uid en gid van de Jellyfin-gebruiker te bepalen en de verwachte paden tijdens de migratie te behouden. Richtlijnen van Jellyfin voor UID/GID bij migratie
Als de container naar de verkeerde hostmap verwijst, corrigeer je eerst de koppeling. Rechten kunnen een padkoppeling die Jellyfin naar een lege map stuurt niet repareren; starten met dat lege pad kan bovendien een tweede, nieuwe gegevensstructuur aanmaken.
Inspecteer eigenaarschap, modusbits en ACL's voordat je ze wijzigt
Toon de numerieke eigenaar en groep van de verplaatste map en van een selectie van de submappen voor de database, configuratie, metadata en logboeken. Controleer de uitvoeringsrechten op bovenliggende mappen en eventuele ACL-vermeldingen die van het doelbestandssysteem kunnen zijn overgenomen.
Een NAS-verplaatsing kan een ander identiteits- en rechtenmodel introduceren, vooral bij SMB, NFS of containers. Het artikel over rechtenproblemen na een verplaatsing van ZimaSpace legt uit waarom een zichtbare mount de UID/GID-autorisatie van het containerproces niet omzeilt.
Wijzig niets totdat je de afwijking precies kunt benoemen: verkeerde eigenaar, ontbrekende groepsrechten, geblokkeerde toegang door bovenliggende mappen, onverwachte ACL of een alleen-lezen gemounte map. Die vaststelling bepaalt de kleinst mogelijke veilige reparatie.
Herstel het eigenaarschap alleen van applicatiegegevens die aan Jellyfin toebehoren
Als de verplaatste gegevensmap van Jellyfin eigendom hoort te zijn van het serviceaccount van Jellyfin, herstel je de bedoelde eigenaar en groep voor die applicatiegegevensstructuur. Behoud het eigenaarschap van gedeelde media die niets met Jellyfin te maken hebben, tenzij Jellyfin die bestanden daadwerkelijk moet beheren.
De migratiedocumentatie van Jellyfin bevat ook het corrigeren van het eigenaarschap van de Jellyfin-gegevensmap na een verplaatsing. Eigenaarschap corrigeren na migratie Beschouw dit als een gerichte bewerking van applicatiegegevens, niet als een reden om recursief het eigenaarschap van een volledige NAS-share over te nemen.
Inspecteer na het corrigeren van het eigenaarschap opnieuw een selectie en voer als de Jellyfin-identiteit een niet-destructieve schrijfbaarheidstest uit in een speciale testsubmap. Als schrijven nog steeds wordt geweigerd, stop dan met het toevoegen van chmod-wijzigingen en controleer vervolgens ACL's, de mountmodus of beveiligingslabels.
Controleer de mountmodus van de container en beveiligingslabels
Een correcte eigenaar op de host kan binnen een container nog steeds problemen geven als de bind-mount alleen-lezen is, de runtimegebruiker is gewijzigd of het beveiligingssysteem van de host de toegang tot het pad blokkeert. Vergelijk de huidige containerdefinitie met de laatst werkende versie.
De containerhandleiding van Jellyfin toont expliciete uitvoering met UID/GID, alleen-lezen mounts voor media en opties voor herlabeling in Podman voor SELinux-omgevingen. Containerrechten en herlabeling Deze instellingen kunnen bepalen wat gewone Unix-modusbits lijken toe te staan.
Wijzig alleen de laag waarvan je hebt vastgesteld dat die het probleem veroorzaakt. Maak de mount van de applicatiegegevens schrijfbaar als Jellyfin daar moet kunnen schrijven, herstel de juiste runtime-UID/GID of pas het platformgeschikte label op die mount toe. Maak de container vervolgens één keer opnieuw aan en controleer hetzelfde pad opnieuw vanuit de container.
Start Jellyfin en controleer schrijfacties naar de database en gegevensmap
Start Jellyfin en volg het opstartlogboek. Controleer of de bestaande serverstatus wordt geopend in plaats van een installatiewizard of lege bibliotheek, en let op rechtenfouten bij de database, configuratie, metadata of logboeken.
Als het opstarten het normale dashboard bereikt, start je één laag-risicobewerking die naar de status van Jellyfin schrijft, zoals een geplande taak of metadataactie in een testcontext. Controleer vervolgens of het verwachte bestand of de verwachte databasestatus verandert zonder rechtenfouten.
Start Jellyfin nogmaals opnieuw. De reparatie is pas voltooid als dezelfde gegevensmap na een nieuwe start probleemloos wordt geopend; succes tijdens één sessie kan een mount- of initialisatieprobleem verbergen dat bij het opnieuw aanmaken terugkeert.
Draai brede wijzigingen terug en escaleer met exacte bewijzen
Als je al brede recursieve rechten hebt toegepast en de server nog steeds niet werkt, geef dan niet steeds ruimere toegang. Herstel waar mogelijk vanuit de vastgelegde eigendomsgegevens of een back-up en ga vervolgens terug naar de specifieke afwijking in runtime-identiteit en pad.
Vergelijk voor servers in containers de huidige mountbron, het doelpad, de UID/GID, groepen en beveiligingscontext met de opgeslagen werkende definitie. Vergelijk voor native installaties de service-identiteit en het gedrag van het mount- en ACL-systeem van het doelbestandssysteem. Het doel is één verklaarbaar rechtenmodel.
Stop wanneer Jellyfin de oorspronkelijke database opent, naar de eigen gegevensmappen schrijft, de gekozen achtergrondbewerking voltooit en een herstart doorstaat. Escaleer met numeriek eigenaarschap, ACL-uitvoer, mountopties, runtime-UID/GID en de eerste rechtenfout in het logboek als een van die controles nog steeds mislukt.
Aanbevolen producten
Ondersteuning & Tips
Meer om te lezen
Moet Jellyfin één gedeeld account of afzonderlijke huishoudaccounts gebruiken?
Kies Jellyfin-huishoudaccounts op basis van de identiteits-, toegangs-, ouderlijketoezichts- en herstelgrenzen die je nodig hebt.
Waarom blijft het geheugengebruik van Jellyfin hoog nadat het werk is voltooid?
Maak onderscheid tussen geheugengroei van het Jellyfin-proces en de Linux-cache, en onderzoek het alleen wanneer het geheugengebruik blijft stijgen of daadwerkelijk voor druk zorgt.
Signalen dat een Jellyfin-opslagindeling een herstelrisico begint te vormen
Controleer de opslagrollen van Jellyfin, scheid de actieve toestand van back-ups en opnieuw opbouwbare gegevens, en toon met een herstel aan dat de indeling...
