Så förhindrar du behörighetsdrift i Immichs datafoldrar

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Att förhindra behörighetsdrift i Immich innebär att göra filägarskap och åtkomstregler förutsägbara innan olika containrar, NAS-protokoll, uppdateringar eller underhållsjobb skapar nya filer med andra identiteter.

Den hållbara lösningen är inte en periodisk rekursiv återställning av behörigheter. Dokumentera det numeriska UID/GID och den åtkomst som varje arbetsflöde faktiskt behöver, se till att monteringsägarskap och ACL-arv är genomtänkta, skilj skrivskyddade sökvägar från skrivbara sökvägar och testa skapandeflödet efter varje ändring. Behörighetsdrift förhindras när morgondagens nya fil skapas korrekt utan en akut chown, inte när dagens bibliotek råkar vara läsbart.

Dokumentera identiteterna som läser och skriver till varje Immich-sökväg

Lista värdsökvägarna som monteras i Immich och identifiera vilka processer som förväntas läsa, skapa, byta namn på eller ta bort filer i varje sökväg. Dokumentera för varje skrivande process dess numeriska UID och GID på värden och inuti containern. Numeriska ID:n är viktigare än matchande användarnamn, eftersom filer lagrar ägarskap som nummer.

Ta med skrivande processer som inte hör till Immich i inventeringen. SMB-uppladdningar, NFS-klienter, säkerhetskopieringsverktyg, importskript, containrar för mediehantering och ett administratörsskal kan alla skapa filer i samma träd. Om de gör det som olika identiteter kan biblioteket långsamt samla på sig ägare och lägen som fungerar för en sökväg men misslyckas för en annan.

Förvara denna identitetskarta tillsammans med Compose-konfigurationen. Då kan en framtida bilduppdatering, servermigrering eller återställd NAS-konto jämföras med en känd fungerande baslinje i stället för att avvikelsen upptäcks först när nya uppladdningar börjar misslyckas.

Använd en genomtänkt modell med ägare, delad grupp och minsta nödvändiga åtkomst

Bestäm vilken identitet som ska äga programhanterade data och vilken delad grupp, om någon, som behöver åtkomst. Ge varje arbetsflöde endast de läs- eller skrivrättigheter som krävs. Undvik att göra hela Immich-trädet skrivbart för alla bara för att en container inte kan skapa en miniatyrbild eller flytta en importerad fil.

UID/GID-avvikelser och alltför generösa lägen är vanliga orsaker till fel i delade volymer. Det säkrare mönstret är att anpassa behörigheterna för containrar och volymer i stället för att ge obegränsad åtkomst. Det är viktigt på en hemmaserver där flera tjänster kan behöva använda samma lagringspool.

Om flera tjänster behöver skrivåtkomst ska du använda en delad grupp och konsekventa gruppbehörigheter eller ACL:er i stället för att växelvis ändra ägarskapet rekursivt mellan program. Verifiera först en representativ katalog. Omfattande rekursiva ändringar i hela fotobiblioteket bör vara en sista utväg med en aktuell säkerhetskopia, inte rutinunderhåll.

Gör behörigheter för nya filer förutsägbara

Befintliga filer kan se perfekta ut medan nya filer omedelbart börjar avvika eftersom skapandereglerna är fel. Kontrollera den överordnade katalogens ACL, standard-ACL-poster, umask, tjänstens identitet samt eventuella SMB- eller NFS-inställningar för skapande som gäller för sökvägen. Målet med förebyggandet är arv, inte städning.

Innan du ändrar lägen rekursivt ska du jämföra det numeriska ägarskapet på värden med det UID/GID som faktiskt körs inuti containern. Denna kontroll av UID/GID för bindmontering skiljer snabbt en identitetsavvikelse från en faktiskt saknad behörighet. Korrigera relationen mellan ägare och grupp i stället för att dölja problemet med generösa lägen.

Skapa en liten testfil genom varje normalt skrivflöde: Immich-uppladdning, importarbetsflöde, SMB/NFS-överföring om det används samt återställning från säkerhetskopia. Kontrollera ägare, grupp, läge och ACL efter varje test. Om två skapandeflöden ger inkompatibla resultat ska du lösa den policykonflikten innan du importerar mer data.

-15% OFF
Single board computer zimaboard2

Förhindra att monterings- och uppdateringsändringar skriver om ägarskapet

Behandla en Compose-redigering, bilduppdatering, NAS-ommontering eller migrering som en behörighetskänslig ändring. Innan du tillämpar den ska du dokumentera den aktuella monteringskällan och målet, om sökvägen är skrivskyddad eller skrivbar, den effektiva containeranvändaren samt ett urval av det numeriska ägarskapet från varje viktig katalog.

Överföringar och nätverkslagring kan införa andra SMB/NFS-identiteter, numeriska ID:n, ACL-arv och umask-beteende. Använd kontrollpunkter för fel vid ändrade NAS-behörigheter som en checklista före ändringen när Immich-data flyttas mellan filsystem eller åtkomstmetoder.

Efter ändringen ska du jämföra samma urval innan du kör massjobb. Om ägarskapet plötsligt ändras vid uppstart ska du stoppa stacken och identifiera vilken startpunkt, underhållsuppgift eller ommappade identitet som orsakade det. Låt inte en oförklarad rekursiv omskrivning av ägarskapet fortsätta över ett stort bibliotek.

Granska avvikelser med små, repeterbara tester

Gör en enkel behörighetsgranskning enligt ett schema eller efter uppgraderingar: kontrollera några stabila original, en nyligen uppladdad fil, en nyskapad härledd fil och eventuell monterad extern samling. Leta efter oväntade ägare, saknad gruppåtkomst, skrivskyddade monteringar som blivit skrivbara eller ACL:er som inte längre ärvs som förväntat.

Gör sedan ett test av hela skrivflödet. Ladda upp ett testobjekt som kan tas bort via den vanliga klienten, låt Immich bearbeta det, öppna det och ta bort det genom programmet. Om externa samlingar eller importvägar ingår i din konfiguration ska du lägga till en representativ fil via dessa vägar och bekräfta att Immich kan läsa den utan att oväntat ändra ägarskapet.

Förebyggandeloopen är slutförd först när nya filer fortsätter att få avsedd identitet och åtkomst efter en omstart av Immich och en omstart av värden. Om behörigheterna kräver manuell reparation efter någon av dessa händelser pågår driften fortfarande. Korrigera skapanderegeln eller identitetsmappningen innan du utökar åtkomsten.

Support och tips

Mer att läsa

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.