Waarom verliest Immich de toegang tot persistente gegevens nadat de stack opnieuw is aangemaakt?

Wanneer Immich leeg lijkt of de bibliotheek niet kan lezen nadat de stack opnieuw is aangemaakt, ga er dan eerst van uit dat de oude persistente gegevens niet gekoppeld of niet leesbaar zijn, voordat je aanneemt dat ze zijn verwijderd.

Het opnieuw aanmaken van containers kan de identiteit van het Compose-project, de bron van een bind-mount, de koppeling van een benoemd volume, het moment waarop een netwerkshare beschikbaar komt of de UID/GID waarmee de gegevens worden gelezen, wijzigen. Stop de nieuwe, leeg ogende instantie voordat deze veel nieuwe status wegschrijft, zoek de oude database- en mediapaden op de host en vergelijk de opnieuw aangemaakte stack met de laatst bekende werkende configuratie. Het doel is om eerst de bestaande status opnieuw te koppelen; herstel pas vanaf een back-up nadat je hebt bewezen dat die status daadwerkelijk ontbreekt of beschadigd is.

Stop de nieuwe instantie en bewijs dat de oude gegevens nog bestaan

Een installatiewizard, een lege tijdlijn of een ontbrekende externe bibliotheek direct na het opnieuw aanmaken is een waarschuwing voor een persistentieprobleem. Stop Immich en controleer de database- en medialocaties op de host voordat je nieuwe bestanden uploadt of een nieuwe lege configuratie accepteert. Nieuwe schrijfbewerkingen kunnen latere padvergelijkingen lastiger maken.

Controleer de oude mappen op verwachte aantallen bestanden, wijzigingsdatums, databasebestanden of dumps en enkele originele afbeeldingen. Als de gegevens op de host aanwezig zijn, gaat het probleem over toegang of koppeling en niet over verdwijning. Maak een momentopname of back-up die alleen-lezen is van die status voordat je eigenaarschap wijzigt of mappen verplaatst.

Als de oude gegevens niet op de verwachte paden kunnen worden gevonden, doorzoek dan de opslagpool en de Docker-volume-inventaris voordat je iets verwijdert. De beslissende uitkomst is binair: de bestaande status is gevonden en beveiligd, of deze is werkelijk niet beschikbaar en het herstel gaat verder vanaf een bekende goede back-up in plaats van met het repareren van mounts.

Vergelijk de opnieuw aangemaakte mounts met de vorige stack

Inspecteer de effectieve mounts op de opnieuw aangemaakte Immich-server- en databasecontainers, en niet alleen de Compose-tekst die je je herinnert te hebben bewerkt. Een relatief bind-pad kan vanuit een andere projectmap worden opgelost en een hernoemd Compose-project kan een nieuw benoemd volume koppelen, terwijl het oude intact maar ongebruikt blijft.

Een mislukte, gewijzigde of ontbrekende mount kan in een container een lege map tonen, terwijl de verwachte gegevens elders op de host nog bestaan. Gebruik controles voor Docker-volumemounts om Source, Destination, het mounttype en de identiteit van het benoemde volume voor elk persistent Immich-pad te vergelijken. Een afwijking hier verklaart rechtstreeks waarom de instantie er nieuw en leeg uitziet.

Corrigeer alleen de verkeerde mountkoppeling en maak of start de container vervolgens zonder volumes te verwijderen. Als de verwachte bestanden na de wijziging op hetzelfde containerpad verschijnen, laat de gegevens dan staan. Als de mountlijst klopt maar de toegang nog steeds mislukt, behoud dan de koppeling en onderzoek de beschikbaarheid van de hostopslag en de machtigingen in plaats van nog een volume aan te maken.

Controleer of externe opslag was aangekoppeld voordat Immich startte

Als de Immich-gegevens op een HDD-pool, NAS-share, mergerlaag of andere externe mount staan, controleer dan of die opslag daadwerkelijk op de host is aangekoppeld voordat Docker de stack start. Een pad zoals /mnt/photos kan nog steeds bestaan als gewone lokale map terwijl het echte apparaat niet beschikbaar is.

Persistente Docker-gegevens blijven alleen behouden na het vervangen van containers wanneer het bedoelde volume of de bind-mount correct opnieuw wordt gekoppeld. Het onderliggende persistentiemodel van Docker-volumes zorgt er niet voor dat een ontbrekende hostschijf of netwerkshare automatisch verschijnt. Controleer daarom het opslagapparaat en een bekend bestand op de host voordat je hetzelfde pad binnen Immich test.

Als je ontdekt dat er terugvalbestanden zijn geschreven in het lege mountpunt terwijl de echte opslag niet beschikbaar was, stop Immich dan voordat je het apparaat daaroverheen mount. Verwerk die bestanden afzonderlijk, voeg een opstartafhankelijkheid of gezondheidscontrole voor de opslagmount toe en start de stack pas daarna opnieuw. Als de hostopslag stabiel is en het containerpad nog steeds niet leesbaar is, ga dan verder met de machtigingentak.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer UID, GID en mapmachtigingen zonder alles opnieuw te schrijven

Een opnieuw aangemaakte stack kan een service uitvoeren met een andere numerieke identiteit, gebruikersnaamruimte of beveiligingscontext dan de oude. Het resultaat ziet er anders uit dan een ontbrekende mount: het pad bestaat en bestanden zijn vanaf de host zichtbaar, maar de Immich-logboeken tonen machtigingsfouten of Immich kan verwachte bestanden niet aanmaken.

Vergelijk het numerieke eigenaarschap en de modusbits op de betreffende hostmappen met de gebruikersidentiteit binnen de opnieuw aangemaakte container. Test eerst een ongevaarlijke leesbewerking en daarna een omkeerbare schrijfbewerking in een tijdelijke map onder dezelfde mount. Vermijd een recursieve wijziging van het eigenaarschap van het volledige fotoarchief totdat je weet welke service schrijftoegang nodig heeft en welke originele bestanden ongemoeid moeten blijven.

Los de kleinst mogelijke afwijking in map of identiteit op die de fout verklaart, start eenmaal opnieuw en controleer de logboeken opnieuw. Als de toegang nog steeds mislukt met overeenkomende mounts en machtigingen, stop dan met wijzigingen aan het bestandssysteem en controleer de databaseverbinding, omgevingssubstitutie of beveiligingslaag die door het opnieuw aanmaken is veranderd.

Koppel de oorspronkelijke status opnieuw en valideer een volgende recreatie

Start Immich zodra de oude database- en mediapaden gekoppeld en leesbaar zijn en controleer of de oude gebruikers, albums, personen en representatieve bestanden zichtbaar zijn. Noem de reparatie niet voltooid alleen omdat de homepage wordt geladen; controleer of de toepassing de oorspronkelijke status leest en niet een nieuw geïnitialiseerde database die ernaast staat.

De belangrijke grens is dat containers vervangbaar kunnen zijn, terwijl de applicatiestatus op stabiele opslag buiten de levenscyclus van de container moet blijven. Documenteer de gecorrigeerde mountnamen en hostpaden en gebruik persistente opslagrollen van een fileserver om ervoor te zorgen dat de volgende recreatie van de stack aan dezelfde gegevens gekoppeld blijft.

Maak ten slotte de stack onder gecontroleerde omstandigheden nog één keer opnieuw aan en herhaal de oorspronkelijke controles. De oplossing is pas bewezen als dezelfde database en media na het opnieuw aanmaken én na een herstart van de host weer verschijnen. Als de oude status opnieuw verdwijnt of als de database corruptie meldt in plaats van toegangsproblemen, zet dan de beveiligde kopie terug en schakel over op database- of back-upherstel in plaats van verder te experimenteren met mounts.