Varför återskapar Immich saknade filer med fel ägare?

Eva Wong

IceWhale author

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.

Why Does Immich Recreate Missing Files With the Wrong Owner? - Zima Store Online

Immich bör inte i tysthet återskapa ett saknat källoriginal som en generell återställningsfunktion. Om ett borttaget objekt dyker upp igen bör du först fastställa om det är en genererad miniatyr, en kodad video, ett profilobjekt, en XMP-sidofil eller någon annan skrivbar fil. Sådana filer kan återskapas eller skrivas om av olika processer och får då en annan ägare.

Använd ett enda tillfälligt återskapat objekt och dess överordnade katalog. Jämför numeriskt UID/GID och ACL:er på värdsystemet med den effektiva skrivande användaren i containern. Fastställ sedan om Immich, en funktion som skriver sidofiler, ett NAS-protokoll eller någon annan process på värdsystemet faktiskt skapade filen. Undvik rekursiv chown eller chmod 777 tills den skrivande processen är känd.

Jämför den återskapade filen med dess överordnade katalog och en fungerande referensfil

Notera ägare, grupp, rättigheter, ACL:er, utökade attribut om det är relevant samt numeriskt UID/GID för den återskapade filen, dess överordnade katalog och en äldre fil som fungerar korrekt. Namn kan vara missvisande mellan ett NAS-system och en container; numeriska ID:n visar om ”immich” på det ena systemet motsvarar samma identitet på det andra.

ZimaSpaces behörighetsarbetsflöde för filer som flyttats till ett NAS gäller direkt: nya objekt styrs av målplatsens ACL, containeridentiteten, protokollmappningen och reglerna för skapande. En ersättningsfil kan därför vara läsbar men ändå få en ägare som stör en annan programvaras arbetsflöde. Om den återskapade filen följer den överordnade katalogens arv och endast visningsnamnet verkar obekant, bör du mappa det numeriska ID:t innan du ändrar något. Om den skiljer sig från både den överordnade katalogen och de fungerande referensfilerna fortsätter du med att fastställa den skrivande identiteten. Problemet kan ligga i containerkonfigurationen snarare än i filsystemets ACL.

Identifiera processen och det effektiva UID/GID som skriver ersättningen

Utlös en säker återskapning medan du övervakar relevanta loggar och filsystemet. Kontrollera den effektiva användaren och grupperna i containern som utför skrivningen. Om en sidotjänst, ett metadataverktyg, en säkerhetskopieringsprocess eller ett skript på värdsystemet skapar filen i stället, ska du granska den tjänsten i stället för att ändra Immichs körningsidentitet.

Ägarskap i containrar är numeriskt, inte namn-baserat. En förklaring av filägarskap i Docker visar varför samma bind-monterade fil kan visas med olika användarnamn på värdsystemet och i containern när UID/GID-mappningarna inte överensstämmer. Använd numeriska ID:n som gemensam referens.

En diskussion om ägarskap i Immichs externa bibliotek dokumenterade att XMP-sidofiler skrevs som root i en installation. Det är ett exempel på varför du bör kontrollera den effektiva skrivande processen och den stödda körningsidentiteten, inte ett påstående om att alla aktuella Immich-installationer skriver alla återskapade filer som root.

Om containern avsiktligt körs som en icke-rootanvändare ska du bekräfta att UID/GID faktiskt finns på värdsystemet eller NAS-systemet och har nödvändig åtkomst till den monterade sökvägen. Ett symboliskt användarnamn i en container motsvarar inte automatiskt ett värdkonto med samma namn.

Åtgärda regeln för skapande i stället för att upprepade gånger korrigera befintliga filer

Korrigera den minsta bekräftade gränsen: anpassa tjänstens UID/GID där det stöds, reparera den överordnade katalogens grupp eller ACL-arv, ställ in en lämplig umask eller ändra NAS-resursens mappning som tillhandahåller fel identitet. Bevara möjligheten för Immich och andra legitima läsare att komma åt original och genererade filer.

Använd inte skrivbehörighet för alla som standardlösning. Det döljer identitetsmismatchen och utökar skrivåtkomsten i onödan. Ändra inte heller ägarskapet rekursivt för PostgreSQL, modellcache, uppladdningar och externa bibliotek med ett enda kommando; dessa sökvägar kan avsiktligt använda olika tjänsteidentiteter.

Om ett externt bibliotek ska vara oföränderligt kan du överväga att montera det skrivskyddat och behålla appägt skrivbart tillstånd någon annanstans, men endast om de funktioner du använder inte kräver att sidofiler skrivs där. Beslutet handlar om önskat ägarskap och skrivbeteende, inte om att tvinga alla filer i fotoarkivet att dela ett konto.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Återskapa en fil igen och validera efter en omstart

Ta endast bort ett tillfälligt genererat objekt eller en test-sidofil som säkert kan återskapas och utlös sedan exakt samma Immich-åtgärd igen. Kontrollera den nya ägaren, gruppen, ACL:erna och läsbarheten från både Immich och det andra programmet som tidigare misslyckades. Låt originalmediet vara orört under testet.

Starta om containern och starta sedan om värdsystemet en gång för att säkerställa att den korrigerade identiteten och monteringarna överlever livscykelförändringar. En lyckad korrigering skapar nästa testfil med förväntat ägarskap automatiskt; den är inte beroende av ett chown-skript efter uppstart som konkurrerar med Immichs skrivningar.

Stoppa och återställ från den sparade konfigurationen om ägarskapsändringarna oväntat sprider sig till databasen eller originalfilerna, eller om tjänsten förlorar läs- eller skrivåtkomst efter omstart. Eskalera med numeriska ID:n, ACL-utdata, monteringsalternativ, effektiv containeranvändare, Compose-fragment och den exakta filtyp som Immich återskapade.