Hur kan Immich och Nextcloud dela ett fotobibliotek utan att komma i konflikt?

Immich och Nextcloud kan samexistera kring samma fotofiler, men tillförlitligheten beror på att definiera vilket system som äger ändringar i filsystemet och hur Immich observerar dem.

Det finns inget magiskt lager för delat tillstånd som håller två oberoende databaser synkroniserade när någon av applikationerna flyttar, raderar eller redigerar en fil. En vanlig lösning är att låta Nextcloud fortsätta vara lagret för filhantering och synkronisering, medan Immich får en monterad vy av ett externt bibliotek för bläddring och igenkänning. Det skapar en användbar uppdelning, men också en tydlig gräns för omskanning.

Behandla filsystemet som den gemensamma gränsen

Nextcloud och Immich har olika applikationsdatabaser och olika antaganden om sitt eget tillstånd. Att dela samma underliggande media slår inte ihop dessa databaser. Den säkra integrationsfrågan är därför vilket filsystemsträd båda kan se och vilken applikation som får ändra det.

En diskussion i Nextcloud-communityt om integration av externa bibliotek beskriver hur användare exponerar Nextcloud-hanterade fotomappar för Immich i stället för att försöka ansluta produkterna via ett automatiskt databasprotokoll. Med den lösningen blir filsystemet integrationsytan.

Håll det gemensamma avtalet enkelt: en kanonisk uppsättning original, en förutsägbar monteringssökväg i Immich och en uttrycklig ägare för namnbyten och raderingar. Om båda applikationerna självständigt organiserar om samma träd kan ingen av databaserna härleda alla avsikter från den slutliga sökvägen ensam.

Skrivskyddad åtkomst för Immich minskar skrivkonflikter

När Nextcloud är källan till sanningen för filernas placering minskar risken kraftigt för att en radering eller metadataändring från fotogränssnittet ändrar filer som Nextcloud fortfarande anser sig äga, om trädet monteras skrivskyddat för Immich. Immich kan fortfarande indexera och visa objekten, medan ändringar i källfilerna lämnas till det överordnade systemet.

En användarrapport om att använda Immich som visare illustrerar denna arbetsfördelning: Nextcloud hanterar de lagrade filerna medan Immich erbjuder en mer avancerad upplevelse för fotovisning och igenkänning över monterat innehåll.

Skrivskyddad åtkomst har en gräns: ändringar som kräver att källsidans metadata eller sidofiler ändras kan inte behandlas som beständiga filändringar från Immich. Bestäm i förväg om betyg, beskrivningar eller ändringar på filnivå ska höra hemma i Nextcloud, i Immichs databas eller i ett separat arbetsflöde för metadata.

Skanningar av externa bibliotek är synkroniseringssteget

När Nextcloud lägger till, tar bort eller organiserar om filer måste Immich stämma av sin vy av det externa biblioteket mot filsystemet. Det är skanningen som omvandlar en förändring på filnivå till uppdaterat tillstånd för Immich-objekt, så det kan uppstå en fördröjning mellan en åtgärd i Nextcloud och det som fotogränssnittet visar.

Waterloo-communityts wiki visar genom sin metod med Nextcloud-bibliotek ett praktiskt sätt att exponera Nextcloud-användardata som externa Immich-bibliotek. De exakta skripten beror på miljön, men den övergripande principen är stabila monteringssökvägar och medvetna omskanningar.

Tolka inte fördröjningen som ett misslyckande i databassynkroniseringen innan skanningen är klar. Utgå samtidigt inte från att en lyckad montering innebär att ändringar visas omedelbart: synlighet i filsystemet, schemaläggning av skanningar samt efterföljande jobb för miniatyrbilder eller sökning är separata milstolpar.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Flyttningar och raderingar är den viktigaste konfliktgränsen

Ett namnbyte eller en mappflytt i Nextcloud kan för Immich se ut som att en sökväg försvinner och att en ny sökväg uppstår. Om fotoapplikationen inte kan bevara objektets identitet genom flytten kanske applikationsspecifika relationer, som album eller redigeringar, inte längre kopplas till samma logiska objekt efter avstämningen.

En aktuell Immich-diskussion om omorganiserade externa filer rapporterar att bearbetningen startade om när sökvägar ändrades. Det är precis därför ett gemensamt Nextcloud-träd bör ha försiktiga regler för omorganisation och varför stora flyttar av sökvägar först bör testas på en mindre grupp.

Modellen med en enda skrivande part räcker inte längre om ytterligare ett synkroniseringsverktyg skriver om tidsstämplar, skapar dubbletter eller ändrar filer under båda applikationerna. Dokumentera i så fall den tredje skrivande parten och behandla den som en del av integrationen i stället för att isolerat skylla på foto- eller molnapplikationen.

Validera integrationen med ett test i fyra steg

Skapa en testmapp med fyra bilder som kan tas bort. Utför från den utsedda ägarapplikationen en tilläggning, en ändring av metadata på filens sida, en flytt och en radering. Låt den avsedda skanningen slutföras efter varje åtgärd och dokumentera hur Immich representerar objektet, om applikationsmetadata finns kvar och om Nextcloud förblir konsekvent.

Använd ZimaSpaces ramverk för datasökvägar för att skilja mellan filägande, skanning, genererade derivat och databastillstånd. Integrationens tillförlitlighet bygger på att veta vilket lager som ska ändras efter varje åtgärd.

Godkänn lösningen först när de fyra åtgärderna ger förutsägbara resultat och ansvaret för återställning är dokumenterat. Om en flytt återskapar objekt, en radering återkommer eller metadata går förlorad bör du begränsa dessa åtgärder till ett enda system eller ändra integrationsmönstret innan hela familjebiblioteket exponeras.