Hoe voorkom je dat machtigingen in Immich-gegevensmappen afwijken

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Toestemmingsdrift in Immich voorkomen betekent dat u bestandseigenaarschap en toegangsregels voorspelbaar maakt voordat verschillende containers, NAS-protocollen, updates of onderhoudstaken nieuwe bestanden met andere identiteiten aanmaken.

De duurzame oplossing is geen periodieke recursieve reset van rechten. Leg de numerieke UID/GID en de toegang vast die elke workflow daadwerkelijk nodig heeft, zorg bewust voor eigenaarschap van mounts en overerving van ACL's, scheid alleen-lezenpaden van schrijfbare paden en test het aanmaakproces na elke wijziging. Toestemmingsdrift is voorkomen wanneer het nieuwe bestand van morgen correct wordt aangemaakt zonder noodzaak voor een nood-`chown`, niet wanneer de bibliotheek van vandaag toevallig leesbaar is.

Leg de identiteiten vast die elk Immich-pad lezen en beschrijven

Maak een lijst van de hostpaden die in Immich zijn gemount en bepaal welke processen daarin bestanden moeten lezen, aanmaken, hernoemen of verwijderen. Noteer voor elke schrijver de numerieke UID en GID op de host en in de container. Numerieke ID's zijn belangrijker dan overeenkomende gebruikersnamen, omdat bestanden eigenaarschap als nummers opslaan.

Neem ook schrijvers buiten Immich op in de inventaris. SMB-uploads, NFS-clients, back-uptools, importscripts, containers voor mediabeheer en een beheerdersshell kunnen allemaal bestanden in dezelfde boomstructuur aanmaken. Als ze dit als verschillende identiteiten doen, kan de bibliotheek geleidelijk eigenaars en modi krijgen die voor het ene pad werken maar voor het andere falen.

Bewaar deze identiteitskaart samen met de Compose-configuratie. Een toekomstige image-update, servermigratie of hersteld NAS-account kan dan worden vergeleken met een bekende goede basis, in plaats van dat de afwijking pas wordt ontdekt wanneer nieuwe uploads beginnen te mislukken.

Gebruik een bewust model met eigenaar, gedeelde groep en minimale toegang

Bepaal welke identiteit eigenaar moet zijn van door de applicatie beheerde gegevens en welke gedeelde groep, indien van toepassing, toegang nodig heeft. Geef elke workflow alleen de lees- of schrijfrechten die nodig zijn. Maak niet de volledige Immich-structuur voor iedereen schrijfbaar alleen omdat één container geen miniatuur kan aanmaken of een geïmporteerd bestand kan verplaatsen.

Niet-overeenkomende UID/GID's en te ruime modi zijn veelvoorkomende oorzaken van problemen met gedeelde volumes. De veiligere aanpak is om rechten voor containers en volumes op elkaar af te stemmen in plaats van onbeperkte toegang te geven. Dat is belangrijk op een homeserver waar meerdere diensten dezelfde opslagpool kunnen gebruiken.

Als meerdere diensten schrijftoegang nodig hebben, gebruikt u een gedeelde groep en consistente groepsrechten of ACL's in plaats van het eigenaarschap afwisselend recursief aan verschillende applicaties toe te wijzen. Controleer eerst één representatieve map. Brede recursieve wijzigingen in de volledige fotobibliotheek moeten een laatste redmiddel zijn met een actuele back-up, geen routinematig onderhoud.

Maak de rechten voor nieuwe bestanden voorspelbaar

Bestaande bestanden kunnen er perfect uitzien terwijl nieuwe bestanden direct afwijken omdat de aanmaakregels verkeerd zijn. Controleer de ACL van de bovenliggende map, standaard-ACL-items, de umask, de service-identiteit en eventuele SMB- of NFS-instellingen voor het aanmaken die op het pad van toepassing zijn. Het doel van preventie is overerving, niet opschoning.

Vergelijk voordat u modi recursief wijzigt het numerieke eigenaarschap op de host met de UID/GID waaronder de container daadwerkelijk draait. Deze controle van UID/GID bij bind mounts maakt snel onderscheid tussen een identiteitsafwijking en een werkelijk ontbrekende toestemming. Herstel de relatie tussen eigenaar en groep in plaats van het probleem met ruime modi te verbergen.

Maak via elk normaal schrijfpad een klein testbestand: een Immich-upload, importworkflow, SMB/NFS-overdracht indien gebruikt en herstel van een back-up. Controleer na elke test de eigenaar, groep, modus en ACL. Als twee aanmaakpaden onverenigbare resultaten opleveren, los dat beleidsconflict dan op voordat u meer gegevens importeert.

-15% OFF
Single board computer zimaboard2

Voorkom dat mount- en updatewijzigingen het eigenaarschap herschrijven

Behandel een Compose-wijziging, image-update, NAS-herkoppeling of migratie als een wijziging die gevoelig is voor rechten. Noteer voordat u deze toepast de huidige bron en bestemming van de mount, of het pad alleen-lezen of lezen-schrijven is, de effectieve gebruiker in de container en een steekproef van het numerieke eigenaarschap van elke belangrijke map.

Overdrachten en netwerkopslag kunnen andere SMB/NFS-identiteiten, numerieke ID's, ACL-overerving en umask-gedrag introduceren. Gebruik controlepunten voor problemen met NAS-rechten als checklist vooraf wanneer Immich-gegevens tussen bestandssystemen of toegangsmethoden worden verplaatst.

Vergelijk na de wijziging dezelfde steekproeven voordat u bulkbewerkingen uitvoert. Als het eigenaarschap bij het opstarten plotseling verandert, stop dan de stack en bepaal welke entrypoint, onderhoudstaak of opnieuw toegewezen identiteit dit heeft veroorzaakt. Laat een onverklaarde recursieve herschrijving van het eigenaarschap niet doorgaan over een grote bibliotheek.

Controleer drift met kleine, herhaalbare tests

Voer volgens een schema of na upgrades een lichte controle van de rechten uit: controleer enkele stabiele originelen, een recente upload, een nieuw gegenereerde afgeleide en elke mount van een externe bibliotheek. Let op onverwachte eigenaars, ontbrekende groepstoegang, mounts die alleen-lezen waren maar schrijfbaar zijn geworden en ACL's die niet langer zoals verwacht worden overgenomen.

Voer daarna een end-to-end-schrijftest uit. Upload via de normale client een wegwerpbestand, laat Immich het verwerken, open het en verwijder het via de applicatie. Als externe bibliotheken of importpaden deel uitmaken van uw configuratie, voeg dan via die paden één representatief bestand toe en controleer of Immich het kan lezen zonder het eigenaarschap onverwacht te wijzigen.

De preventielus is pas voltooid wanneer nieuwe bestanden na een herstart van Immich en een herstart van de host de beoogde identiteit en toegang blijven krijgen. Als rechten na een van beide gebeurtenissen handmatig moeten worden hersteld, treedt er nog steeds drift op; herstel de aanmaakregel of identiteitsmapping voordat u de toegang uitbreidt.

Ondersteuning & Tips

Meer om te lezen

Dubbele taken of imports in Immich voorkomen
Sep 08, 2026

Dubbele taken of imports in Immich voorkomen

Scheid herhaalde taken van dubbele assets. Gebruik één canoniek ingestiepad, beheer retries en padwijzigingen en test vervolgens opnieuw invoeren op een kleine groep.

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.