Come configurare gli ID utente dei container su più condivisioni NAS

Configura gli ID utente dei container tra più condivisioni NAS associando l’identità numerica effettiva di ogni processo del container al proprietario, al gruppo, all’ACL e alla modalità di montaggio di ogni condivisione di cui ha bisogno.

Non forzare un unico UID a essere proprietario di ogni dataset e non usare chmod 777 come strategia di integrazione. Un server multimediale potrebbe avere bisogno dell’accesso in sola lettura alle foto, un downloader potrebbe richiedere l’accesso in lettura e scrittura a una condivisione di importazione e un container di backup potrebbe aver bisogno di una destinazione protetta diversa. Usa la proprietà per la responsabilità principale e i gruppi o le ACL per l’accesso condiviso.

Registra le tre identità prima di modificare i permessi

Per ogni servizio, registra l’UID/GID del proprietario sul NAS, l’utente numerico e i gruppi del processo all’interno del container e qualsiasi convenzione di identità specifica dell’immagine, come PUID/PGID. Questi tre valori vengono spesso confusi perché i nomi utente possono sembrare identici mentre gli ID numerici differiscono.

Un’attuale spiegazione di PUID e PGID chiarisce la distinzione: PUID e PGID sono variabili interpretate da determinate immagini container, non impostazioni Docker universali.

Verifica il processo in esecuzione con id all’interno del container e controlla i file sull’host visualizzando la proprietà numerica. Non dare per scontato che i valori scritti in Compose controllino effettivamente il processo, a meno che l’immagine supporti quel metodo.

Usa un proprietario principale e gruppi condivisi per i dati tra servizi

Una condivisione usata da una sola applicazione può avere un proprietario dedicato. Una condivisione su cui scrivono diversi servizi è generalmente più facile da gestire con un gruppo condiviso definito intenzionalmente o con un’ACL che conceda solo le operazioni richieste da quei servizi.

Una spiegazione pratica della proprietà basata su UID e GID numerici mostra perché i file montati tramite bind seguono la proprietà numerica dell’host e perché associare correttamente o mappare intenzionalmente questi ID previene file generati dal proprietario root e errori di autorizzazione.

In un flusso multimediale, ad esempio, il downloader può essere proprietario dei file temporanei, mentre downloader e organizzatore possono appartenere entrambi a un gruppo media. Configura l’ereditarietà delle directory, le ACL predefinite o un comportamento umask appropriato, così i nuovi file mantengono automaticamente l’accesso condiviso.

Concedi a ogni condivisione solo i diritti di montaggio necessari al container

L’identità è solo un livello. Anche un UID mappato correttamente non può scrivere tramite un bind mount di sola lettura e un container con ampi permessi sul file system può comunque essere limitato in modo sicuro montando una libreria in sola lettura.

Un articolo del 2026 sugli override dell’utente a runtime spiega come i bind mount usino la proprietà dell’host e come le impostazioni runtime user: possano allineare gli ID dei processi, avvertendo inoltre che forzare un utente può compromettere le immagini la cui logica di avvio richiede privilegi diversi.

Documenta ogni percorso dell’host, percorso del container, modalità di montaggio, operazioni richieste e servizio responsabile. Usa i montaggi in sola lettura per le librerie che un servizio deve solo utilizzare e riserva l’accesso in scrittura al percorso più piccolo che ne ha effettivamente bisogno.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gestisci intenzionalmente i diversi modelli di ACL del NAS

Le ACL SMB/NFSv4, le ACL POSIX, la mappatura delle identità NFS e i semplici bit di modalità Unix possono presentare visualizzazioni diverse dell’accesso. Una condivisione che funziona tramite SMB con un determinato utente NAS può comunque rifiutare un processo del container che utilizza un’identità numerica diversa sull’host.

L’articolo correlato di ZimaSpace sulle modifiche ai permessi NAS mostra perché l’ereditarietà delle ACL sulla destinazione, l’identità SMB, l’UID/GID del container e umask devono essere diagnosticati come livelli separati.

Quando diversi protocolli accedono allo stesso dataset, scegli un modello di autorizzazione e documentalo. Mescolare ripetutamente le modifiche alle ACL dall’interfaccia grafica del NAS con i comandi shell chmod e chown può fare in modo che il file successivo si comporti diversamente da quello precedente.

Verifica la creazione dei file da ogni servizio di scrittura prima di applicare modifiche ricorsive

Crea una directory di test eliminabile con la proprietà e l’ACL previste. Da ogni container, verifica l’elenco, la lettura, la creazione, la ridenominazione e l’eliminazione, limitandoti alle operazioni richieste dal servizio. Poi controlla dal NAS il proprietario numerico, il gruppo, la modalità e l’ACL ereditata del nuovo file.

Se i file esistenti funzionano ma quelli appena creati non funzionano per un altro servizio, correggi il percorso di creazione: appartenenza al gruppo, ACL predefinita, umask o modalità dei file specifica dell’applicazione. Una correzione ricorsiva dei dati esistenti non impedisce che lo stesso disallineamento si ripresenti domani.

Distribuisci in produzione solo dopo che ogni servizio di scrittura ha creato file utilizzabili dal servizio successivo richiesto senza privilegi elevati. Una progettazione UID/GID ordinata è ripristinabile perché la mappatura è documentata e ripetibile, non perché ogni container viene eseguito per caso con lo stesso utente.