Waarom maakt Immich ontbrekende bestanden opnieuw aan met de verkeerde eigenaar?

Immich zou een ontbrekend origineel niet stilletjes opnieuw moeten aanmaken als algemene herstel functie. Als een verwijderd object opnieuw verschijnt, bepaal dan eerst of het een gegenereerde miniatuur, gecodeerde video, profielartefact, XMP-sidecar of ander beschrijfbaar bestand is; deze kunnen door verschillende processen opnieuw worden aangemaakt of herschreven en een andere eigenaar krijgen.

Gebruik één tijdelijk opnieuw gegenereerd object en de bovenliggende map ervan. Vergelijk de numerieke UID/GID en ACL's op de host met de effectieve schrijver in de container en bepaal vervolgens of Immich, een functie die sidecars schrijft, een NAS-protocol of een ander hostproces het bestand daadwerkelijk heeft aangemaakt. Vermijd recursieve chown of chmod 777 totdat die schrijver bekend is.

Vergelijk het opnieuw aangemaakte bestand met de bovenliggende map en een bekende goede buur

Noteer de eigenaar, groep, modus, ACL, uitgebreide attributen indien relevant, en numerieke UID/GID van het opnieuw aangemaakte bestand, de bovenliggende map en een ouder bestand dat correct werkt. Namen kunnen misleidend zijn tussen een NAS en een container; numerieke ID's laten zien of “immich” op het ene systeem naar dezelfde identiteit verwijst als op het andere.

De ZimaSpace-machtigingsworkflow voor bestanden die naar een NAS zijn verplaatst is hier rechtstreeks van toepassing: nieuwe objecten worden bepaald door de ACL van de bestemming, de containeridentiteit, de protocoltoewijzing en de aanmaakregels. Een vervangend bestand kan daarom leesbaar zijn en toch een eigenaar krijgen die de workflow van een ander hulpprogramma verbreekt. Als het opnieuw aangemaakte bestand overeenkomt met de overerving van de bovenliggende map en alleen de weergegeven naam onbekend lijkt, breng dan eerst de numerieke ID in kaart voordat je iets wijzigt. Als het afwijkt van zowel de bovenliggende map als de bekende goede bestanden, ga dan verder met de schrijversidentiteit; het probleem kan in de containerconfiguratie zitten en niet in de ACL van het bestandssysteem.

Identificeer het proces en de effectieve UID/GID die de vervanging schrijft

Start één veilige regeneratie terwijl je de relevante logs en het bestandssysteem controleert. Inspecteer de effectieve gebruiker en groepen in de container die de schrijfactie uitvoert. Als een sidecar, metadataprogramma, back-upproces of hostscrypt het bestand in plaats daarvan aanmaakt, inspecteer dan die service in plaats van de runtime-identiteit van Immich te wijzigen.

Eigenaarschap in containers is numeriek en niet op namen gebaseerd. Een uitleg over bestandseigenaarschap in Docker laat zien waarom hetzelfde bestand op een gekoppelde map op de host en in de container een andere gebruikersnaam kan tonen wanneer UID/GID-toewijzingen niet overeenkomen. Gebruik numerieke ID's als gemeenschappelijke referentie.

In een discussie over eigenaarschap van externe bibliotheken in Immich werd gedocumenteerd dat XMP-sidecars in één implementatie als root werden geschreven. Dat is aanleiding om de effectieve schrijver en de ondersteunde runtime-identiteit te controleren, niet om te beweren dat elke huidige Immich-installatie elk opnieuw gegenereerd bestand als root schrijft.

Als de container bewust als een niet-rootgebruiker draait, controleer dan of de UID/GID daadwerkelijk op de host of NAS bestaat en de vereiste toegang tot het gekoppelde pad heeft. Een symbolische gebruikersnaam in een container komt niet automatisch overeen met een hostaccount met dezelfde naam.

Herstel de aanmaakregel in plaats van bestaande bestanden steeds opnieuw te repareren

Corrigeer de kleinst mogelijke bevestigde grens: breng de service-UID/GID waar ondersteund op één lijn, herstel de groepsovererving of ACL-overerving van de bovenliggende map, stel een geschikte umask in of wijzig de toewijzing van de NAS-share die de verkeerde identiteit levert. Behoud de mogelijkheid voor Immich en andere legitieme lezers om originelen en gegenereerde bestanden te benaderen.

Gebruik wereldschrijfbare machtigingen niet als standaardoplossing. Daarmee verberg je de identiteitsmismatch en breid je de schrijftoegang onnodig uit. Wijzig PostgreSQL-eigenaarschap, modelcache, uploads en externe bibliotheken evenmin recursief met één opdracht; deze paden kunnen bewust verschillende service-identiteiten gebruiken.

Als een externe bibliotheek onveranderlijk moet zijn, kun je overwegen de koppeling alleen-lezen te maken en door de app beheerde schrijfbare status elders te bewaren, maar alleen als de functies die je gebruikt daar geen sidecar-schrijfacties vereisen. De keuze gaat over het gewenste eigenaarschap en schrijfgedrag, niet over het afdwingen dat elk bestand in het fotoarchief hetzelfde account gebruikt.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Maak opnieuw één bestand aan en valideer na een herstart

Verwijder alleen een tijdelijk gegenereerd object of een test-sidecar die veilig opnieuw kan worden aangemaakt en voer vervolgens exact dezelfde Immich-bewerking opnieuw uit. Controleer de nieuwe eigenaar, groep, ACL en leesbaarheid vanuit zowel Immich als het andere programma dat eerder faalde. Laat de oorspronkelijke media tijdens deze test ongemoeid.

Herstart de container en start daarna de host eenmaal opnieuw op om te controleren of de gecorrigeerde identiteit en koppelingen lifecyclewijzigingen overleven. Een geslaagde reparatie maakt het volgende testbestand automatisch met het verwachte eigenaarschap aan; deze mag niet afhankelijk zijn van een chown-script na het opstarten dat schrijfacties van Immich kan doorkruisen.

Stop en herstel vanuit de bewaarde configuratie als eigenaarschapswijzigingen zich onverwacht uitbreiden naar de database of originelen, of als de service na het herstarten lees- of schrijftoegang verliest. Escaleer met numerieke ID's, ACL-uitvoer, koppelopties, de effectieve containergebruiker, het Compose-fragment en het exacte bestandstype dat Immich opnieuw heeft aangemaakt.