La fonte identifica correttamente il livello reale di proprietà: quando un container crea una directory all’interno di una cartella ZimaOS montata, la nuova directory normalmente eredita l’identità e il comportamento umask del processo in esecuzione all’interno del container, non i permessi che si sperava la cartella padre imponesse automaticamente.
Per questo una directory padre scrivibile da tutti può comunque ritrovarsi con nuove sottocartelle root:root a 0755. Se l’applicazione viene eseguita come root e usa un umask predefinito, le sottocartelle di proprietà di root sono previste, a meno che l’immagine non supporti PUID/PGID, un utente specifico del container, l’ereditarietà del gruppo setgid, ACL predefinite o un altro modello di autorizzazioni.
L’esempio della fonte riguardava una cartella di backup montata
L’utente descriveva un percorso come:
/media/Daten/Backupdove le sottocartelle appena create diventavano:
root:root
drwxr-xr-xUn utente non root, ad esempio con UID 999, poteva quindi leggere ma non creare file in quelle nuove sottocartelle.
Una cartella padre 0777 non forza la proprietà delle sottocartelle
Il permesso di scrittura della cartella padre consente al processo del container di creare una sottocartella. Non fa sì automaticamente che la sottocartella erediti il proprietario o il gruppo della cartella padre, a meno che il filesystem o le regole di gruppo non siano configurati per ottenere questo comportamento.
Il risultato normale è determinato da UID/GID del creatore e dall’umask del processo.
Usa PUID/PGID solo quando l’immagine del container li supporta
Molte immagini in stile LinuxServer espongono le variabili d’ambiente PUID e PGID. Altre immagini ignorano completamente queste variabili e richiedono il campo Docker user: o impostazioni specifiche dell’applicazione.
Le indicazioni attuali di IceWhale per Syncthing invitano esplicitamente gli utenti a verificare gli ID reali degli utenti ZimaOS con:
id -u username
id -g usernamee a inserire quindi quei valori nei campi PUID/PGID dell’app.
Consulta l’esempio attuale di PUID/PGID per ZimaOS.
umask controlla quali bit dei permessi vengono rimossi durante la creazione
Un’app che crea directory con una modalità di base 0777 usando un umask tipico di 022 produrrà directory 0755. Un flusso di lavoro collaborativo di gruppo può usare un umask diverso, se l’applicazione lo supporta.
Non impostare globalmente un umask ultra-permissivo solo per risolvere il problema di un’unica app.
setgid può aiutare a mantenere un gruppo condiviso sulle nuove sottocartelle
Nei filesystem nativi Linux, l’impostazione del bit setgid su una directory condivisa può fare in modo che gli elementi creati al suo interno ereditino il gruppo della directory. È utile quando più servizi o utenti collaborano intenzionalmente tramite un unico gruppo.
Non modifica l’ID utente del processo che crea gli elementi e potrebbe non comportarsi allo stesso modo sui montaggi NTFS/exFAT che simulano la proprietà Unix tramite opzioni di montaggio.
Le ACL predefinite offrono un’ereditarietà più esplicita
Nei filesystem che supportano le ACL POSIX, le voci ACL predefinite possono definire quali permessi ricevono i nuovi elementi. Spesso è una soluzione più pulita rispetto all’esecuzione ripetuta di chmod ricorsivi dopo ogni processo di backup.
Prima di affidarsi a una configurazione effettuata esclusivamente dalla shell, è opportuno verificare se l’interfaccia attuale di ZimaOS espone un flusso di lavoro completo per le ACL per il percorso di archiviazione interessato.
La fonte era una richiesta di funzionalità, non un’impostazione ZimaOS esistente
L’autore richiedeva un controllo globale per PUID/PGID, un’opzione per l’ereditarietà, la gestione dell’umask, il supporto setgid e un’interfaccia grafica per la correzione ricorsiva. La discussione non contiene alcuna risposta di IceWhale che confermi l’implementazione di queste funzionalità.
Non presentare l’elenco delle richieste come se fosse composto da opzioni attuali delle Impostazioni.
Correggi l’identità dell’app prima di modificare ricorsivamente l’intero disco
Se un’app di backup ricrea ripetutamente cartelle di proprietà di root, eseguire chown -R dopo ogni processo risolve il sintomo. Configura prima correttamente l’identità, il gruppo e l’umask del container, quindi correggi solo l’albero interessato.
Le impostazioni attuali delle app ZimaOS consentono di esaminare le mappature dei volumi e la configurazione dell’app, mentre le variabili esatte per i permessi dipendono dall’immagine.
Domande frequenti sulla proprietà delle cartelle montate
Perché una cartella figlia può diventare root:root all’interno di una cartella padre scrivibile?
Perché il processo all’interno del container l’ha creata come root e la directory padre non sovrascrive automaticamente l’identità del creatore.
PUID e PGID funzionano con tutte le immagini Docker?
No. Sono convenzioni specifiche delle immagini per le variabili d’ambiente, non variabili Docker universali.
IceWhale ha confermato nella fonte un’opzione globale per l’ereditarietà dei permessi?
No. La discussione è una richiesta di funzionalità senza conferma dell’implementazione.
