Come prevenire la deriva delle autorizzazioni nelle cartelle dei dati di Immich
Prevenire la deriva delle autorizzazioni in Immich significa rendere prevedibili la proprietà dei file e le regole di accesso prima che container diversi, protocolli NAS, aggiornamenti o attività di manutenzione creino nuovi file con identità differenti.
La soluzione duratura non consiste nel reimpostare periodicamente e ricorsivamente le autorizzazioni. Registra gli UID/GID numerici e gli accessi effettivamente necessari a ogni flusso di lavoro, mantieni intenzionale la proprietà dei mount e l’ereditarietà degli ACL, separa i percorsi in sola lettura da quelli scrivibili e verifica il percorso di creazione dopo ogni modifica. La deriva delle autorizzazioni è prevenuta quando il nuovo file di domani viene creato correttamente senza un `chown` d’emergenza, non quando la libreria di oggi è semplicemente leggibile.
Registra le identità che leggono e scrivono in ogni percorso di Immich
Elenca i percorsi dell’host montati in Immich e identifica quali processi devono leggere, creare, rinominare o eliminare file in ciascuno di essi. Per ogni processo di scrittura, registra il suo UID e GID numerico sull’host e all’interno del container. Gli ID numerici sono più importanti della corrispondenza tra i nomi utente, perché i file memorizzano la proprietà come numeri.
Includi nell’inventario anche i processi di scrittura non appartenenti a Immich. I caricamenti SMB, i client NFS, gli strumenti di backup, gli script di importazione, i container per la gestione dei media e una shell dell’amministratore possono creare file nello stesso albero. Se operano con identità diverse, la libreria può accumulare gradualmente proprietari e modalità che funzionano per un percorso ma non per un altro.
Conserva questa mappa delle identità insieme alla configurazione Compose. Un futuro aggiornamento dell’immagine, una migrazione del server o un account NAS ripristinato potranno così essere confrontati con una baseline funzionante, invece di scoprire la discrepanza solo dopo che i nuovi caricamenti iniziano a fallire.
Usa un modello intenzionale di proprietario, gruppo condiviso e accesso minimo
Decidi quale identità deve essere proprietaria dei dati gestiti dall’applicazione e quale gruppo condiviso, se necessario, deve avere accesso. Concedi a ogni flusso di lavoro solo i diritti di lettura o scrittura necessari. Evita di rendere scrivibile da chiunque l’intero albero di Immich solo perché un container non riesce a creare una miniatura o a spostare un file importato.
Le discrepanze tra UID/GID e le modalità troppo permissive sono cause comuni dei problemi con i volumi condivisi. Il modello più sicuro consiste nell’allineare le autorizzazioni del container e del volume invece di concedere un accesso illimitato. Questo è importante su un server domestico in cui diversi servizi possono accedere allo stesso pool di archiviazione.
Se più servizi devono avere accesso in scrittura, usa un gruppo condiviso e autorizzazioni di gruppo o ACL coerenti, invece di alternare la proprietà ricorsiva tra le applicazioni. Verifica prima una directory rappresentativa. Le modifiche ricorsive estese all’intera libreria fotografica dovrebbero essere l’ultima risorsa, con un backup aggiornato, non una normale attività di manutenzione.
Rendi prevedibili le autorizzazioni dei nuovi file
I file esistenti possono sembrare perfetti mentre i nuovi file diventano subito incoerenti perché le regole di creazione sono errate. Controlla l’ACL della directory padre, le voci ACL predefinite, l’umask, l’identità del servizio e tutte le impostazioni di creazione SMB o NFS applicate al percorso. L’obiettivo della prevenzione è l’ereditarietà, non la pulizia.
Prima di modificare ricorsivamente le modalità, confronta la proprietà numerica sull’host con l’UID/GID effettivamente in esecuzione all’interno del container. Questo controllo UID/GID del bind mount distingue rapidamente una discrepanza di identità da un’autorizzazione realmente mancante. Correggi la relazione tra proprietario e gruppo invece di nasconderla con modalità permissive.
Crea un piccolo file di test attraverso ogni normale percorso di scrittura: caricamento in Immich, flusso di importazione, trasferimento SMB/NFS se utilizzato e ripristino da backup. Dopo ogni test, controlla proprietario, gruppo, modalità e ACL. Se due percorsi di creazione producono risultati incompatibili, risolvi il conflitto di criteri prima di importare altri dati.
Impedisci che modifiche ai mount e agli aggiornamenti riscrivano la proprietà
Considera una modifica a Compose, un aggiornamento dell’immagine, un nuovo mount del NAS o una migrazione come una variazione sensibile alle autorizzazioni. Prima di applicarla, registra l’origine e la destinazione del mount corrente, indica se il percorso è in sola lettura o in lettura-scrittura, l’utente effettivo del container e un campione della proprietà numerica di ogni directory importante.
I trasferimenti e lo storage di rete possono introdurre identità SMB/NFS diverse, ID numerici, ereditarietà degli ACL e comportamenti dell’umask differenti. Usa i punti critici dei problemi di autorizzazione del NAS come checklist preliminare ogni volta che i dati di Immich vengono spostati tra file system o metodi di accesso.
Dopo la modifica, confronta gli stessi campioni prima di eseguire attività in blocco. Se la proprietà cambia improvvisamente all’avvio, arresta lo stack e individua quale entrypoint, attività di manutenzione o identità rimappata l’ha causato. Non permettere che una riscrittura ricorsiva della proprietà, di cui non conosci la causa, continui su una libreria di grandi dimensioni.
Verifica la deriva con test piccoli e ripetibili
Esegui un controllo leggero delle autorizzazioni secondo una pianificazione oppure dopo gli aggiornamenti: verifica alcuni originali stabili, un caricamento recente, un derivato appena generato e qualsiasi mount di una libreria esterna. Cerca proprietari imprevisti, accesso di gruppo mancante, mount in sola lettura diventati scrivibili o ACL che non vengono più ereditati come previsto.
Esegui quindi un test di scrittura completo. Carica un elemento di prova eliminabile tramite il client abituale, lascia che Immich lo elabori, aprilo e rimuovilo dall’applicazione. Se la tua configurazione include percorsi di librerie esterne o importazioni, aggiungi un file rappresentativo attraverso tali percorsi e verifica che Immich possa leggerlo senza modificare in modo imprevisto la proprietà.
Il ciclo di prevenzione è completo solo quando i nuovi file continuano a ricevere l’identità e l’accesso previsti dopo il riavvio di Immich e il riavvio dell’host. Se dopo uno dei due eventi è necessaria una riparazione manuale delle autorizzazioni, il sistema è ancora soggetto a deriva: correggi la regola di creazione o la mappatura delle identità prima di ampliare l’accesso.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come ottimizzare le connessioni al database di Immich per container simultanei
Non aumentare prima max_connections. Misura le sessioni di Immich, somma la richiesta totale di ogni container, mantieni un margine per l'amministratore e ottimizza solo...
Come impedire la duplicazione di processi o importazioni in Immich
Separa i processi ripetuti dalle risorse duplicate. Utilizza un unico percorso di acquisizione canonico, controlla i nuovi tentativi e le modifiche ai percorsi, quindi...
Come riparare Immich dopo che il volume del database si è riempito
Non eliminare mai il WAL di PostgreSQL per liberare spazio. Interrompi le scritture di Immich, preserva lo stato del database, aggiungi capacità in modo...
