Se Immich continua a indicare lo spazio libero dell'SSD di sistema di ZimaOS anche dopo l'aggiunta di un HDD più capiente, la domanda importante è quale directory host sia effettivamente associata al mount di upload/archiviazione di Immich. Nella discussione della community dell'aprile 2026, l'utente originale eseguiva Immich 2.7.4 su un SSD di sistema da 250 GB e voleva archiviare le foto su un HDD da 1 TB. La modifica ripetuta del percorso dopo l'installazione ha causato container non integri o errori di avvio.
La discussione originale ha prodotto diversi risultati. Un utente ha avuto successo dopo una reinstallazione pulita e l'uso di uno YAML personalizzato. L'autore originale ha infine riferito di aver avuto successo solo dopo aver scelto il percorso di archiviazione sull'HDD prima di installare Immich. Una risposta successiva ha collegato alcuni problemi di avvio ai controlli di integrità dell'archiviazione di Immich. Anche la documentazione upstream attuale di Immich è cambiata dalla versione 2.7.4, quindi il percorso esatto del container utilizzato in questo pacchetto storico di ZimaOS non dovrebbe essere copiato in ogni distribuzione attuale di Immich.
Cosa utilizzava la configurazione originale di Immich 2.7.4
Le istruzioni della community mostravano questa mappatura storica:
Host: /DATA/Gallery/immich
Container: /usr/src/app/uploadLa prima raccomandazione era modificare solo il lato host e mantenere invariato il percorso del container. Ad esempio, un'unità secondaria poteva essere esposta tramite un percorso host di ZimaOS, mentre Immich continuava a visualizzare la directory interna di upload prevista.
Perché la semplice modifica del percorso host non ha funzionato per tutti
Diversi utenti hanno provato a sostituire il percorso host predefinito dopo che Immich era già stato inizializzato. Alcuni hanno ricevuto uno stato di container non integro, alcuni hanno visualizzato un errore di filesystem di sola lettura e altri hanno riscontrato che l'app continuava a indicare l'unità di sistema.
Ciò significa che questa discussione non supporta l'affermazione universale secondo cui “modificare un volume e riavviare” funziona sempre. Immich conserva lo stato del database e gli indicatori di integrità dell'archiviazione, e modificare un bind mount dopo l'inizializzazione può rendere la nuova directory incoerente con lo stato previsto da Immich.
L'approccio funzionante confermato dall'autore originale
Dopo diversi tentativi falliti, Solid è tornato il 19 aprile e ha affermato che l'approccio funzionante consisteva nell'eseguire un'installazione pulita e modificare il percorso di installazione/archiviazione sull'HDD da 1 TB prima che inizializzasse l'installazione di Immich.
Un secondo utente ha confermato un percorso con reinstallazione pulita e YAML personalizzato
Un altro partecipante, scott492010, ha rimosso l'installazione non riuscita, ha conservato le foto esistenti, ha eliminato lo stato obsoleto di AppData/database di Immich, ha reinstallato l'app e poi ha utilizzato il file YAML personalizzato condiviso nella conversazione. Ha confermato esplicitamente che la nuova configurazione funzionava.
Non eliminare AppData o il database di Immich alla leggera. Quella procedura della community è stata utilizzata su un'installazione danneggiata/di test. Se la libreria contiene metadati, utenti, album o risorse caricate importanti, esegui un backup sia del database sia dello spazio di archiviazione delle foto prima della ricostruzione.
Percorso storico di ZimaOS: /DATA/.media/...
La conversazione ha sperimentato percorsi di unità esterne come:
/DATA/.media/Elements/Photos
/DATA/.media/Elements/Photos/uploadQuesti esempi erano specifici per le unità e il layout dei percorsi di ZimaOS discussi in quella conversazione. Non copiare il nome Elements oppure supporre che ogni unità compaia nello stesso percorso sull'host. Utilizza il percorso effettivo mostrato dalle impostazioni attuali di File/app di ZimaOS.
L'attuale Immich utilizza un layout di archiviazione upstream diverso
La documentazione upstream attuale di Docker Compose di Immich utilizza UPLOAD_LOCATION sull'host e lo monta su /data nel modello Compose attuale. Questo differisce dalla mappatura storica di ZimaOS Immich 2.7.4 a /usr/src/app/upload.
Consulta la documentazione attuale di Docker Compose di Immich.
Questo è un limite tra versioni, non una contraddizione. Se utilizzi un pacchetto dell'App Store di ZimaOS, mantieni la destinazione del container definita dal pacchetto attuale. Se gestisci autonomamente il Compose upstream, segui il modello upstream attuale.
Guida attuale di Immich per i percorsi dei file personalizzati
Immich ora dispone di una guida alle posizioni personalizzate dei file. Consiglia di modificare deliberatamente le posizioni sul lato host e di spostare i file esistenti corrispondenti, così Immich continuerà a trovarli.
Immich sconsiglia inoltre di dividere upload/ e library/ in mount bind separati sullo stesso dispositivo. Per un nuovo layout, segui l'attuale modello di archiviazione invece di ricostruire riga per riga lo YAML della community del 2026.
Perché la mancanza dei file .immich può impedire l'avvio
Una risposta di luglio 2026 nella discussione ha identificato errori come:
ENOENT: nessun file o directory
.../encoded-video/.immichL'attuale documentazione sull'integrità del sistema di Immich conferma che i file nascosti .immich sono marcatori dei mount utilizzati per rilevare permessi errati o mount di archiviazione mancanti o sostituiti.
La risposta sul forum suggeriva di creare manualmente le cartelle e i file marcatore previsti. L'attuale documentazione upstream è più cauta: in genere i file marcatore non dovrebbero essere creati o eliminati manualmente, salvo specifiche situazioni di ripristino. Se il mount è cambiato inaspettatamente, correggi prima il mount. Ricreare manualmente un marcatore è appropriato solo dopo aver verificato il motivo della sua assenza.
Non usare chmod 777 come correzione predefinita dei permessi
La risposta finale della community includeva anche:
sudo chmod -R 777 /DATA/Main-Storage/immichQuesto garantisce a ogni utente/processo locale un ampio accesso in scrittura. Potrebbe rimuovere una barriera di autorizzazione, ma non è il modello di permessi permanente preferito. Identifica invece l'UID/GID e i permessi di archiviazione previsti dal pacchetto Immich installato.
Mantieni il database PostgreSQL su un filesystem appropriato
Spostare gli elementi multimediali delle foto su un HDD capiente non significa che ogni componente di Immich debba risiedere lì. Gli attuali requisiti di Immich indicano che il database PostgreSQL dovrebbe risiedere preferibilmente su un'unità SSD locale e richiede un filesystem con normali semantiche Unix per la proprietà e i permessi; NTFS ed exFAT non sono supportati per la directory dei dati del database.
Consulta i requisiti di installazione di Immich.
Ciò significa che un'architettura ragionevole può mantenere il database e lo stato dell'app Immich su uno spazio di archiviazione SSD affidabile, collocando invece la posizione degli upload di foto e video, molto più grande, su un disco secondario adatto.
Esegui il backup prima di ricostruire o spostare i dati esistenti di Immich
La documentazione attuale di Immich raccomanda di proteggere sia il database sia le risorse del filesystem. Un backup del solo database non contiene le foto e i video originali.
Guida al backup e al ripristino di Immich
Ordine di risoluzione dei problemi più sicuro
- Identifica l'esatto pacchetto/la versione di Immich installato in ZimaOS.
- Annota l'attuale mappatura host-container degli upload.
- Esegui il backup delle foto importanti e del database Immich prima di modificare un'installazione esistente.
- Per una nuova installazione, scegli il percorso host destinato allo spazio di archiviazione più capiente prima della prima inizializzazione, quando il pacchetto ZimaOS lo consente.
- Mantieni il percorso lato container definito da quel pacchetto.
- Se l'app diventa non funzionante, leggi i log di Immich e cerca errori relativi alle autorizzazioni o all'integrità dello spazio di archiviazione.
- Verifica che la nuova cartella dell'host sia scrivibile dall'identità del container Immich.
- Se nei log viene indicata l'assenza di
.immichi marcatori; verifica il mount e la struttura delle directory prima di creare manualmente i file. - Evita
chmod 777come soluzione permanente.
FAQ sullo spazio di archiviazione del sistema di Immich
Perché Immich continua a mostrare la capacità del mio SSD di sistema?
Il bind mount attivo per gli upload potrebbe puntare ancora allo spazio di archiviazione del sistema, oppure il mount modificato potrebbe non essersi inizializzato correttamente. Verifica l'effettiva mappatura host-container utilizzata dal server in esecuzione.
L'autore originale ha risolto il problema?
Sì. Solid ha riferito che un'installazione pulita, con il percorso dell'HDD selezionato prima dell'installazione, ha funzionato dopo che le modifiche successive all'installazione avevano fallito.
Devo copiare /usr/src/app/upload in una nuova installazione di Immich?
Non alla cieca. Quello era il percorso del container nel pacchetto storico Immich 2.7.4 di ZimaOS. L'attuale Compose di Immich upstream usa /data. Segui il pacchetto/la versione effettivamente in uso.
Devo creare manualmente i file .immich?
Solo dopo aver verificato perché mancano. La documentazione attuale di Immich indica che questi marcatori normalmente non devono essere creati o eliminati manualmente, salvo in specifici casi di ripristino.
Posso mettere il database su un'unità USB exFAT?
Gli attuali requisiti di Immich non supportano exFAT/NTFS per la directory dei dati PostgreSQL. Mantieni il database su un filesystem locale adatto e, se necessario, sposta separatamente le risorse fotografiche.
