Als Immich zelfs nadat je een grotere harde schijf hebt toegevoegd vrije ruimte van de ZimaOS-systeem-SSD blijft rapporteren, is de belangrijkste vraag welke hostmap daadwerkelijk aan de upload-/opslagmount van Immich is gekoppeld. In de communitythread van april 2026 draaide de oorspronkelijke gebruiker Immich 2.7.4 op een systeem-SSD van 250 GB en wilde hij foto's opslaan op een harde schijf van 1 TB. Het pad na de installatie herhaaldelijk wijzigen leidde tot ongezonde containers of opstartproblemen.
De brondiscussie leidde tot verschillende uitkomsten. Eén gebruiker slaagde na een schone herinstallatie en een aangepaste YAML-configuratie. De oorspronkelijke auteur meldde uiteindelijk alleen succes nadat hij vóór de installatie van Immich het opslagpad op de harde schijf had geselecteerd voordat Immich werd geïnstalleerd. Een latere reactie bracht sommige opstartproblemen in verband met de integriteitscontroles van Immich voor de opslag. De huidige upstream-documentatie van Immich is sinds versie 2.7.4 ook gewijzigd, dus het exacte containerpad in dit historische ZimaOS-pakket moet niet zonder meer worden overgenomen voor elke huidige Immich-implementatie.
Wat de oorspronkelijke Immich 2.7.4-installatie gebruikte
De community-instructies toonden deze historische koppeling:
Host: /DATA/Gallery/immich
Container: /usr/src/app/uploadDe eerste aanbeveling was om alleen de hostzijde te wijzigen en het containerpad te behouden. Een secundaire schijf kon bijvoorbeeld via een hostpad van ZimaOS beschikbaar worden gemaakt, terwijl Immich nog steeds de verwachte interne uploadmap zag.
Waarom het eenvoudig wijzigen van het hostpad niet voor iedereen werkte
Verschillende gebruikers probeerden het standaardpad op de host te vervangen nadat Immich al was geïnitialiseerd. Sommigen kregen de status van een ongezonde container, anderen zagen een foutmelding over een alleen-lezenbestandssysteem en weer anderen ontdekten dat de app nog steeds de systeemschijf rapporteerde.
Dat betekent dat deze thread geen universele bewering ondersteunt dat “één volume bewerken en opnieuw opstarten” altijd werkt. Immich bewaart de databasestatus en markeringen voor de opslagintegriteit, en het wijzigen van een bind mount na initialisatie kan ervoor zorgen dat de nieuwe map niet overeenkomt met de status die Immich verwacht.
De bevestigde werkende aanpak van de oorspronkelijke auteur
Na meerdere mislukte pogingen kwam Solid op 19 april terug en zei dat de werkende aanpak was om een schone installatie uit te voeren en het installatie-/opslagpad vóór het initialiseren van de Immich-installatie te wijzigen naar de harde schijf van 1 TB voordat de Immich-installatie werd geïnitialiseerd.
Een tweede gebruiker bevestigde een schone herinstallatie en een aangepast YAML-pad
Een andere deelnemer, scott492010, verwijderde de mislukte installatie, behield de bestaande foto's, verwijderde de verouderde Immich AppData-/databasestatus, installeerde de app opnieuw en gebruikte vervolgens de aangepaste YAML die in de thread werd gedeeld. Hij bevestigde expliciet dat de nieuwe configuratie werkte.
Verwijder AppData of de Immich-database niet zomaar. Die communityprocedure werd gebruikt voor een defecte/testinstallatie. Als de bibliotheek belangrijke metadata, gebruikers, albums of geüploade bestanden bevat, maak dan een back-up van zowel de database als de foto-opslag voordat je opnieuw opbouwt.
Historisch ZimaOS-pad: /DATA/.media/...
In de thread werd geëxperimenteerd met paden naar externe schijven, zoals:
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadDeze voorbeelden waren specifiek voor de schijven en padindeling van ZimaOS in die discussie. Kopieer de naam niet Elementen of ga ervan uit dat elke schijf op hetzelfde hostpad verschijnt. Gebruik het werkelijke pad dat wordt weergegeven in de huidige ZimaOS Files-/app-instellingen.
Huidige Immich gebruikt een andere upstream-opslagindeling
De huidige upstream Immich Docker Compose-documentatie gebruikt UPLOAD_LOCATION op de host en koppelt dit aan /data in de huidige Compose-template. Dat verschilt van de historische ZimaOS Immich 2.7.4-koppeling naar /usr/src/app/upload.
Zie de huidige Immich Docker Compose-documentatie.
Dit is een versiedrempel, geen tegenspraak. Als je een ZimaOS App Store-pakket gebruikt, behoud dan de containerbestemming die het huidige pakket definieert. Als je upstream Compose zelf beheert, volg dan de huidige upstream-template.
Huidige Immich-richtlijnen voor aangepaste bestandslocaties
Immich heeft nu een speciale handleiding voor aangepaste bestandslocaties. Daarin wordt aangeraden hostlocaties doelbewust te wijzigen en de bijbehorende bestaande bestanden te verplaatsen, zodat Immich ze kan blijven vinden.
Immich waarschuwt ook voor het opsplitsen van upload/ en library/ naar afzonderlijke bindkoppelingen op hetzelfde apparaat. Volg voor een nieuwe indeling het huidige opslagmodel in plaats van de YAML-regel uit de community uit 2026 regel voor regel te reconstrueren.
Waarom ontbrekende .immich-bestanden het opstarten kunnen verhinderen
Een antwoord uit juli 2026 in de thread vermeldde fouten zoals:
ENOENT: bestand of map bestaat niet
.../encoded-video/.immichDe actuele documentatie over systeemintegriteit van Immich bevestigt dat verborgen .immich-bestanden markeringsbestanden voor koppelingen zijn, die worden gebruikt om onjuiste toestemmingen of ontbrekende/vervangen opslagkoppelingen te detecteren.
In het forumbericht werd voorgesteld de verwachte mappen en markeringsbestanden handmatig aan te maken. De huidige upstreamdocumentatie is voorzichtiger: markeringsbestanden mogen doorgaans niet handmatig worden aangemaakt of verwijderd, behalve in specifieke herstelsituaties. Als de koppeling onverwacht is gewijzigd, herstel dan eerst de koppeling. Een markeringsbestand handmatig opnieuw aanmaken is alleen gepast nadat je hebt gecontroleerd waarom het ontbreekt.
Gebruik chmod 777 niet als standaardoplossing voor toestemmingsproblemen
Het uiteindelijke antwoord van de community gebruikte ook:
sudo chmod -R 777 /DATA/Main-Storage/immichHiermee krijgt elke lokale gebruiker en elk lokaal proces brede schrijftoegang. Dit kan een toestemmingsbarrière wegnemen, maar het is niet het aanbevolen permanente toestemmingsmodel. Bepaal in plaats daarvan welke UID/GID en opslagrechten het geïnstalleerde Immich-pakket verwacht.
Houd de PostgreSQL-database op een geschikt bestandssysteem
Foto-assets verplaatsen naar een grote HDD betekent niet dat elk onderdeel van Immich daarop moet staan. Volgens de huidige vereisten van Immich hoort de PostgreSQL-database idealiter op lokale SSD-opslag te staan en is een bestandssysteem met de gebruikelijke Unix-eigenaars- en toestemmingssemantiek vereist; NTFS en exFAT worden niet ondersteund voor de gegevensmap van de database.
Zie installatievereisten voor Immich.
Dit betekent dat een redelijke architectuur de Immich-database/appstatus op betrouwbare SSD-opslag kan bewaren, terwijl de veel grotere uploadlocatie voor foto's/video's op een geschikte secundaire schijf wordt geplaatst.
Maak een back-up voordat je bestaande Immich-gegevens opnieuw opbouwt of verplaatst
De huidige Immich-documentatie raadt aan zowel de database als de bestandssysteem-assets te beschermen. Een back-up van alleen de database bevat de oorspronkelijke foto's en video's niet.
Handleiding voor back-up en herstel van Immich
Veiligere volgorde voor probleemoplossing
- Identificeer het exacte Immich-pakket/de exacte versie die in ZimaOS is geïnstalleerd.
- Leg de huidige host-naar-containeruploadkoppeling vast.
- Maak een back-up van belangrijke foto's en de Immich-database voordat je een bestaande installatie wijzigt.
- Kies voor een nieuwe installatie het beoogde hostpad voor grote opslag vóór de eerste initialisatie, wanneer het ZimaOS-pakket dit toestaat.
- Behoud het containerpad dat door dat pakket is gedefinieerd.
- Als de app ongezond wordt, lees dan de Immich-logs en zoek naar fouten met betrekking tot rechten of opslagintegriteit.
- Controleer of de nieuwe hostmap schrijfbaar is voor de containeridentiteit van Immich.
- Als de logs melding maken van ontbrekende
.immichmarkeringen en controleer de mount en directorystructuur voordat je handmatig bestanden aanmaakt. - Vermijd
chmod 777als permanente oplossing.
Veelgestelde vragen over systeemopslag in Immich
Waarom toont Immich nog steeds de capaciteit van mijn systeem-SSD?
De actieve upload-bindmount kan nog steeds naar systeemopslag verwijzen, of de gewijzigde mount is mogelijk niet succesvol geïnitialiseerd. Controleer de daadwerkelijke host-naar-containerkoppeling die door de actieve server wordt gebruikt.
Heeft de oorspronkelijke auteur het probleem opgelost?
Ja. Solid meldde dat een schone installatie waarbij vóór de installatie het HDD-pad was geselecteerd, werkte nadat wijzigingen na de installatie waren mislukt.
Moet ik /usr/src/app/upload naar een nieuwe Immich-installatie kopiëren?
Niet zonder meer. Dat was het containerpad in het historische ZimaOS Immich 2.7.4-pakket. De huidige upstream Immich Compose gebruikt /data. Volg de versie van het pakket die je daadwerkelijk gebruikt.
Moet ik handmatig .immich-bestanden aanmaken?
Pas nadat is vastgesteld waarom ze ontbreken. In de huidige Immich-documentatie staat dat deze markeringen normaal gesproken niet handmatig mogen worden aangemaakt of verwijderd, behalve in specifieke herstelgevallen.
Kan ik de database op een exFAT-USB-schijf zetten?
De huidige Immich-vereisten ondersteunen exFAT/NTFS niet voor de PostgreSQL-datadirectory. Houd de database op een geschikt lokaal bestandssysteem en verplaats foto-assets indien nodig afzonderlijk.
