Perché Immich ricrea i file mancanti con il proprietario sbagliato?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Why Does Immich Recreate Missing Files With the Wrong Owner? - Zima Store Online

Immich non dovrebbe ricreare silenziosamente un originale sorgente mancante come funzionalità generica di ripristino. Se un oggetto eliminato ricompare, identifica innanzitutto se si tratta di una miniatura generata, di un video codificato, di un elemento del profilo, di un file sidecar XMP o di un altro file scrivibile; questi possono essere ricreati o riscritti da processi diversi e acquisire un proprietario differente.

Usa un oggetto rigenerato usa e getta e la relativa directory padre. Confronta UID/GID numerici e ACL sull'host con l'utente effettivo che scrive all'interno del container, quindi identifica se a creare il file è stato Immich, una funzionalità di scrittura dei sidecar, un protocollo NAS o un altro processo dell'host. Evita chown ricorsivi o chmod 777 finché non avrai identificato quel processo.

Confronta il file ricreato con la directory padre e con un file vicino noto come corretto

Registra proprietario, gruppo, modalità, ACL, attributi estesi se pertinenti e UID/GID numerici del file ricreato, della directory padre e di un file più vecchio che funziona correttamente. I nomi possono essere fuorvianti tra un NAS e un container; gli ID numerici rivelano se “immich” su un sistema corrisponde alla stessa identità sull'altro.

Il flusso di lavoro di ZimaSpace per i file spostati su un NAS si applica direttamente: i nuovi oggetti sono regolati dall'ACL della destinazione, dall'identità del container, dalla mappatura del protocollo e dalle regole di creazione. Un file sostitutivo può quindi essere leggibile, ma acquisire comunque un proprietario che interrompe il flusso di lavoro di un altro strumento. Se il file ricreato corrisponde all'ereditarietà della directory padre e solo il nome visualizzato sembra insolito, mappa l'ID numerico prima di modificare qualsiasi cosa. Se differisce sia dalla directory padre sia dai file noti come corretti, continua verificando l'identità del processo di scrittura; il problema potrebbe trovarsi nella configurazione del container anziché nell'ACL del filesystem.

Identifica il processo e l'UID/GID effettivo che scrivono il file sostitutivo

Avvia una rigenerazione sicura osservando contemporaneamente i log e il filesystem pertinenti. Controlla l'utente effettivo e i gruppi all'interno del container che esegue la scrittura. Se invece il file viene creato da un sidecar, uno strumento per i metadati, un processo di backup o uno script dell'host, controlla quel servizio anziché modificare l'identità di runtime di Immich.

La proprietà nei container è numerica, non basata sui nomi. Una spiegazione della proprietà dei file Docker mostra perché lo stesso file montato con bind può visualizzare un nome utente diverso sull'host e nel container quando le mappature UID/GID non corrispondono. Usa gli ID numerici come riferimento comune.

Una discussione sulla proprietà delle librerie esterne di Immich ha documentato sidecar XMP scritti come root in una distribuzione. È una prova a supporto della verifica del processo di scrittura effettivo e dell'identità di runtime supportata, non l'affermazione che ogni installazione attuale di Immich scriva ogni file rigenerato come root.

Se il container è intenzionalmente eseguito come utente non root, conferma che l'UID/GID esista effettivamente sull'host o sul NAS e disponga dell'accesso necessario al percorso montato. Un nome utente simbolico all'interno di un container non corrisponde automaticamente a un account dell'host con lo stesso nome.

Correggi la regola di creazione invece di correggere ripetutamente i file esistenti

Correggi il confine minimo confermato: allinea UID/GID del servizio dove supportato, correggi l'ereditarietà del gruppo o dell'ACL della directory padre, imposta un umask appropriato oppure modifica la mappatura della condivisione NAS che fornisce l'identità errata. Mantieni la possibilità per Immich e per ogni altro lettore legittimo di accedere agli originali e ai file generati.

Non usare i permessi di scrittura per tutti come soluzione predefinita. Questo nasconde la mancata corrispondenza dell'identità ed estende inutilmente l'accesso in scrittura. Allo stesso modo, non modificare ricorsivamente con un solo comando la proprietà di PostgreSQL, della cache dei modelli, dei caricamenti e delle librerie esterne; questi percorsi potrebbero intenzionalmente utilizzare identità di servizio diverse.

Se una libreria esterna deve essere immutabile, valuta la possibilità di montarla in sola lettura e di mantenere altrove lo stato scrivibile dell'app, ma solo se le funzionalità utilizzate non richiedono la scrittura di sidecar in quella posizione. La decisione riguarda la proprietà e il comportamento di scrittura desiderati, non l'imposizione dello stesso account per ogni file nell'archivio fotografico.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Ricrea nuovamente un file e convalida dopo un riavvio

Rimuovi solo un oggetto generato usa e getta o un sidecar di test che possa essere ricreato in sicurezza, quindi esegui nuovamente l'operazione esatta di Immich. Verifica il nuovo proprietario, gruppo, ACL e la leggibilità sia da Immich sia dall'altro programma che in precedenza aveva riscontrato problemi. Durante questo test, lascia intatti i file multimediali originali.

Riavvia il container e poi riavvia una volta l'host per assicurarti che l'identità e i montaggi corretti sopravvivano ai cambiamenti del ciclo di vita. Una correzione riuscita crea automaticamente il file di test successivo con la proprietà prevista; non dipende da uno script chown eseguito all'avvio che entra in conflitto con le scritture di Immich.

Interrompi il servizio e ripristina la configurazione salvaguardata se le modifiche alla proprietà si estendono inaspettatamente al database o agli originali, oppure se dopo il riavvio il servizio perde l'accesso in lettura o scrittura. Inoltra l'escalation includendo ID numerici, output delle ACL, opzioni di montaggio, utente effettivo del container, frammento Compose e il tipo esatto di file ricreato da Immich.