Perché il mio comando docker compose fallisce con un errore di opzione sconosciuta?

Quasi certamente stai usando il vecchio binario autonomo invece del plugin. La documentazione tratta questo caso in modo esplicito: se ottieni un errore del tipo unknown shorthand flag 'd' in -d, probabilmente non hai la versione giusta di Docker, e il comando corretto è docker compose, con uno spazio, non docker-compose con il trattino. Segnala a parte una seconda trappola di versione: un errore che indica che healthcheck.start_interval richiede Docker Engine v25 o successivo, che suggerisce di aggirare commentando quella riga.

Dove finiscono davvero le mie foto sul disco?

Dove punta UPLOAD_LOCATION, che la documentazione descrive come il percorso in cui vengono archiviati i file caricati, chiedendoti di indicarvi il percorso che preferisci per conservare quei dati. È la riga più gravida di conseguenze del file, perché decide quale cartella dovrai includere nei backup. Impostala deliberatamente su un percorso che già proteggi, invece di accettare un valore predefinito e scoprire più tardi che la tua fototeca vive in un posto che i tuoi backup non guardano mai.

Posso mettere il database sul mio NAS?

Il database no. La documentazione lo dice senza giri di parole per DB_DATA_LOCATION: le condivisioni di rete non sono supportate per il database. I database hanno bisogno di un locking dei file di basso livello che i filesystem di rete non garantiscono in modo affidabile, e ignorarlo produce di solito corruzione anziché un errore pulito. La tua fototeca può vivere su storage di rete se ne accetti il costo in prestazioni; la cartella del database resta su un disco locale.

Basta auto-ospitare Immich per mettere al sicuro le foto?

Il progetto stesso dice di no, e lo dice sulla propria homepage: segui sempre un piano di backup 3-2-1 per le tue foto e i tuoi video preziosi. Far girare il server da te cambia chi possiede la tua fototeca, non ne crea una seconda copia. Un'istanza auto-ospitata su una sola macchina dista un guasto di disco, un aggiornamento andato male o una cancellazione accidentale dalla perdita totale, che è esattamente ciò che la regola 3-2-1 esiste per evitare.

Immich con Docker Compose: l'installazione sta in due file, e ciò che decide la sorte delle tue foto viene dopo

Immich è la risposta auto-ospitata a Google Foto: il tuo server, i tuoi dischi, un'app mobile che salva il rullino. L'installazione si legge come se richiedesse cinque minuti, e meccanicamente è così. Le decisioni che determineranno se fra tre anni avrai ancora le tue foto si prendono tutte nel file che modifichi prima di lanciarla.

Cos'è davvero l'installazione ufficiale

Due download e un comando. La documentazione li riporta testualmente:

wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

Nota l'asimmetria di quella seconda riga: il file è pubblicato con il nome example.env e tu lo salvi come .env. Poi, una volta compilate le variabili, tutta l'installazione si riduce a docker compose up -d.

Se quest'ultimo comando fallisce, la documentazione nomina la causa abituale prima che tu debba cercarla. Avverte che se ottieni un errore del tipo unknown shorthand flag: 'd' in -d, probabilmente non hai la versione giusta di Docker, e che la forma corretta è docker compose con uno spazio anziché il vecchio binario docker-compose. Segnala a parte una seconda trappola di versione: un errore che riporta can't set healthcheck.start_interval as feature require Docker Engine v25 or later, che suggerisce di aggirare commentando quella riga.

Sono due disallineamenti di versione, non errori nel tuo file. Nessuno dei due merita una serata.

I due percorsi che decidono la tua capacità di recuperare

Il file compose è breve, ma due delle sue variabili non sono impostazioni intercambiabili. Sono la risposta a « cosa devo salvare » e « cosa si corromperà da solo ».

UPLOAD_LOCATION è descritta nella documentazione come il percorso in cui vengono archiviati i file caricati, con l'indicazione di inserirvi il percorso che preferisci per conservare quei dati. È la cartella che conterrà ogni foto che caricherai. Sceglierla con leggerezza è il modo più comune di ritrovarsi una fototeca collocata fuori da tutti i backup che già fai girare.

DB_DATA_LOCATION è il database, e la documentazione vi associa un vincolo netto: le condivisioni di rete non sono supportate per il database. Non è una raccomandazione di prestazioni. I motori di database si appoggiano a garanzie di locking e di ordinamento delle scritture che i filesystem di rete offrono in modo disomogeneo, e la modalità di guasto è di solito una corruzione silenziosa scoperta settimane dopo, non un rifiuto di avviarsi.

In pratica: la tua fototeca può vivere su storage di rete se accetti che sia più lenta. La cartella del database resta su un disco locale. E qualunque cosa tu scelga per la prima, annotala, perché è il percorso che i tuoi backup devono includere.

Uno scaffale di sala server con un mucchio di transceiver SFP e connettori USB, e davanti un'etichetta stampata su cui si legge STORAGE ENGINEER.

L'avvertenza che il progetto mette sulla propria homepage

La maggior parte delle guide di auto-hosting la salta, quindi vale la pena citare il progetto invece di parafrasarlo. Il repository di Immich porta, in cima, questa riga: « Always follow 3-2-1 backup plan for your precious photos and videos! »

Quell'avvertenza fa una cosa precisa. Non dice che il software sia inaffidabile. Dice che ospitare il proprio server di foto non è di per sé un backup, e chi l'ha scritta sa che gli auto-hoster credono abitualmente il contrario. Un'istanza singola su una macchina singola detiene esattamente una copia della tua fototeca. Un disco che cede, un aggiornamento raffazzonato, una cancellazione accidentale o un percorso digitato male la fa sparire, e non c'è nessun fornitore a cui chiederla.

Il progetto è sotto licenza AGPL-3.0, il che spiega in parte perché tu possa verificarlo ed eseguirlo. Non cambia però l'aritmetica di una copia sola.

Cosa sposta l'auto-hosting, e cosa no

L'auto-hosting viene spesso presentato come l'opzione privata, punto. È più esatto, e più utile, dire che sposta la fiducia invece di eliminarla.

Ciò che cambia davvero: nessuna azienda possiede la tua fototeca, nessun fornitore può essere obbligato per legge a consegnarla, nessuna condizione d'uso cambia alle tue spalle e non c'è nessun account da perdere. Per molte persone è tutto il senso della cosa, e il guadagno è reale.

Ciò che non cambia da solo: la cifratura a riposo sui tuoi dischi, la sicurezza fisica della macchina, tenerla aggiornata e avere più di una copia. Tutto questo diventa il tuo lavoro nel momento in cui lo togli a un fornitore. È lo scambio, ed è ragionevole accettarlo consapevolmente. Lo è molto meno accettarlo per distrazione, avendo dato per scontato che auto-ospitato significasse protetto.

Choix éditorial

4.5 / 5

Vuoi la fototeca privata senza amministrare il server? pCloud a vita + Crypto

Giurisdizione svizzera · Zero-knowledge con l'opzione Crypto · Pagamento unico, nessun aggiornamento da seguire e nessun database da salvare

Société suisse depuis 2013Satisfait ou remboursé 10jFree 10 GB

Voir l'offre

Scegliere onestamente tra le due

Auto-ospita Immich se vuoi le tue foto su hardware che controlli, accetti di farti carico di backup e aggiornamenti, e la manutenzione ti interessa invece di pesarti fra otto mesi.

Usa un servizio gestito zero-knowledge se quello che volevi davvero è che nessuna azienda possa leggere le tue foto, senza diventare la persona reperibile il giorno in cui il disco cede. Quel risultato si ottiene senza server, e sceglierlo non è una rinuncia sulla privacy: è una diversa ripartizione dello stesso lavoro.

L'unica risposta che non regge alla prova dei fatti è un'istanza auto-ospitata singola senza seconda copia. È esattamente per questo che il progetto lo dice da sé prima che tu installi qualsiasi cosa.

I comandi di installazione, la precisazione che il file di ambiente è pubblicato con il nome example.env, le descrizioni di UPLOAD_LOCATION e DB_DATA_LOCATION, l'affermazione che le condivisioni di rete non sono supportate per il database, e i due errori di versione di Docker provengono dalla documentazione ufficiale di installazione di Immich con Docker Compose. La riga sul backup 3-2-1 e la licenza AGPL-3.0 provengono dalla homepage del repository del progetto. Le citazioni sono lasciate nella lingua originale. Entrambe le fonti sono state consultate al momento della stesura; verifica sulla versione che stai installando, dato che il file compose viene distribuito con ogni release. I link commerciali portano l'attributo rel="sponsored nofollow"; può essere applicata una commissione di affiliazione, senza costi aggiuntivi per te.

Guide correlate

Miglior cloud storage per le foto - il versante gestito della stessa domanda, con i servizi che cifrano le foto lato client.
Cloud storage self-hosted - lo stesso compromesso applicato ai file anziché alle foto, con Nextcloud, Seafile e ownCloud.

Domande frequenti

Cosa bisogna scaricare davvero per installare Immich?: Due file, pubblicati con ogni versione. La documentazione riporta i comandi testualmente: wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml e wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env. Nota che il secondo viene pubblicato con il nome example.env e tu lo salvi come .env. Una volta compilate le variabili, tutta l'installazione sta in un comando: docker compose up -d.
Perché il mio comando docker compose fallisce con un errore di opzione sconosciuta?: Quasi certamente stai usando il vecchio binario autonomo invece del plugin. La documentazione tratta questo caso in modo esplicito: se ottieni un errore del tipo unknown shorthand flag 'd' in -d, probabilmente non hai la versione giusta di Docker, e il comando corretto è docker compose, con uno spazio, non docker-compose con il trattino. Segnala a parte una seconda trappola di versione: un errore che indica che healthcheck.start_interval richiede Docker Engine v25 o successivo, che suggerisce di aggirare commentando quella riga.
Dove finiscono davvero le mie foto sul disco?: Dove punta UPLOAD_LOCATION, che la documentazione descrive come il percorso in cui vengono archiviati i file caricati, chiedendoti di indicarvi il percorso che preferisci per conservare quei dati. È la riga più gravida di conseguenze del file, perché decide quale cartella dovrai includere nei backup. Impostala deliberatamente su un percorso che già proteggi, invece di accettare un valore predefinito e scoprire più tardi che la tua fototeca vive in un posto che i tuoi backup non guardano mai.
Posso mettere il database sul mio NAS?: Il database no. La documentazione lo dice senza giri di parole per DB_DATA_LOCATION: le condivisioni di rete non sono supportate per il database. I database hanno bisogno di un locking dei file di basso livello che i filesystem di rete non garantiscono in modo affidabile, e ignorarlo produce di solito corruzione anziché un errore pulito. La tua fototeca può vivere su storage di rete se ne accetti il costo in prestazioni; la cartella del database resta su un disco locale.
Basta auto-ospitare Immich per mettere al sicuro le foto?: Il progetto stesso dice di no, e lo dice sulla propria homepage: segui sempre un piano di backup 3-2-1 per le tue foto e i tuoi video preziosi. Far girare il server da te cambia chi possiede la tua fototeca, non ne crea una seconda copia. Un'istanza auto-ospitata su una sola macchina dista un guasto di disco, un aggiornamento andato male o una cancellazione accidentale dalla perdita totale, che è esattamente ciò che la regola 3-2-1 esiste per evitare.

Choix éditorial

4.5 / 5

Ottieni pCloud

Garanzia di rimborso di 10 giorni