Perché i proprietari dei file dei container cambiano dopo aver copiato i dati delle app?
I proprietari dei file dei container cambiano dopo una copia quando i valori numerici UID/GID non vengono preservati oppure il runtime di destinazione li rimappa o li riscrive.
Su un NAS domestico, lo stesso file può mostrare un nome utente sull’host e un altro all’interno di un container, perché la proprietà viene memorizzata come numeri mentre ogni ambiente risolve tali numeri tramite un database di account diverso. Anche le copie effettuate tramite un’interfaccia grafica, una condivisione SMB, un archivio, una shell root, uno strumento di migrazione o un entrypoint del container possono sostituire la proprietà. Diagnostica prima l’identità numerica, quindi separa il comportamento della copia, le impostazioni dell’utente del runtime, gli script di avvio, gli spazi dei nomi utente e la mappatura dei file system di rete prima di modificare i permessi dell’intero albero dei dati dell’applicazione.
Confronta UID e GID numerici prima dei nomi utente
Controlla origine e destinazione usando la proprietà numerica, non solo i nomi. Registra UID, GID, modalità, ACL, attributi estesi e file system per un file rappresentativo e per la relativa directory principale, sia sull’host sia all’interno del container.
I bind mount Docker espongono i file dell’host a processi che possono usare un database utenti diverso. Una discussione della community Docker spiega perché un accesso affidabile dipenda dall’allineamento degli UID/GID numerici, anziché dalla sola corrispondenza dei nomi utente.
Se i numeri sono identici ma i nomi visualizzati differiscono, la proprietà potrebbe non essere cambiata affatto. Correggi la documentazione o la mappatura degli account invece di riscrivere ricorsivamente i dati. Se i numeri differiscono, conserva le prove e prosegui con le fasi di copia e runtime.
Determina se la copia ha preservato o ricreato la proprietà
Annota il percorso di copia esatto: file manager dell’host, cp, rsync, archivio tar, client SMB/NFS, ripristino da backup, comando di copia Docker o container di migrazione temporaneo. Ogni metodo ha impostazioni predefinite diverse per proprietario, gruppo, ACL e attributi estesi.
Una copia eseguita come root può preservare la proprietà numerica quando vengono usate opzioni di archiviazione esplicite, mentre un altro strumento può creare tutti i file di destinazione con l’account che esegue la copia. Un recente problema di migrazione di un container mostra come i dati copiati dell’applicazione possano diventare illeggibili quando l’UID di destinazione differisce dall’identità di runtime dell’applicazione.
Ripeti l’operazione con una piccola directory di test e controlla immediatamente la proprietà prima dell’avvio dell’applicazione. Se i numeri sono già errati, correggi il metodo di copia o i flag di ripristino. Se cambiano solo dopo l’avvio, lascia invariata la copia e analizza l’entrypoint del container.
Allinea l’utente del runtime del container al proprietario dello storage sull’host
Controlla l’utente effettivo all’interno del container in esecuzione e il proprietario numerico della directory dei dati dell’applicazione montata tramite bind. Verifica anche user: in Compose, i gruppi supplementari, le variabili PUID/PGID della piattaforma e le impostazioni dell’account specifiche dell’immagine.
L’esecuzione come utente non root all’interno di un container non concede automaticamente l’accesso a una directory dell’host appartenente a un’altra identità numerica. Un caso discusso nel forum Docker risolve il problema facendo corrispondere l’utente del container e i permessi dell’host, invece di rendere la directory scrivibile universalmente.
Scegli un unico modello di proprietà stabile per l’applicazione e documentalo in Compose. Aggiungi solo i gruppi necessari per l’accesso condiviso. Evita chmod 777, perché nasconde la mancata corrispondenza delle identità, indebolisce la separazione e non preserva il proprietario previsto per i file futuri.
Verifica se l’entrypoint modifica la proprietà all’avvio
Molte immagini si avviano brevemente come root, creano le directory mancanti, applicano un UID/GID configurato e modificano ricorsivamente la proprietà prima di abbandonare i privilegi. Questo comportamento può far sembrare che una copia corretta cambi autonomamente dopo il primo avvio del container.
I runtime e le immagini dei container possono inoltre offrire comportamenti di modifica della proprietà durante il montaggio. Un problema di Podman segnala che l’opzione :U può riscrivere la proprietà dell’origine, mentre gli script dell’entrypoint possono eseguire una modifica ricorsiva simile durante l’avvio dell’applicazione.
Avvia il container una volta con i log visibili e monitora un piccolo sottoalbero di test. Cerca nell’entrypoint e nelle note di rilascio dell’immagine riferimenti a chown, migrazione degli utenti, PUID/PGID e procedure di correzione dei permessi. Disattiva o limita questo comportamento solo quando l’immagine supporta un’alternativa stabile.
Considera Docker rootless, gli spazi dei nomi utente e i file system di rete
Docker rootless e la rimappatura degli spazi dei nomi utente traducono gli ID del container in un altro intervallo sull’host. NFS, CIFS e alcune opzioni di montaggio dei NAS possono inoltre applicare autonomamente lo squash dell’utente root o forzare tutti i file a un UID e GID configurati.
Una segnalazione sui permessi di Docker rootless mostra file con una proprietà imprevista perché l’identità del container viene mappata attraverso un intervallo subordinato dell’host. L’indizio diagnostico è la mappatura della proprietà nello spazio dei nomi utente, non un normale errore di copia.
Controlla se il percorso dei dati è locale, NFS, CIFS, FUSE o un altro file system montato, quindi registra il relativo comportamento per UID/GID, root-squash e ACL. Verifica separatamente la creazione della proprietà dall’host e dal container. Non eseguire un chown ricorsivo su una condivisione di rete prima di aver compreso la policy delle identità lato server.
Ripristina la proprietà a partire da un’identità applicativa nota
Arresta l’applicazione, esegui il backup dei metadati attuali e definisci l’UID, il GID, le modalità delle directory, le modalità dei file, le ACL e le etichette di sicurezza esatti previsti dall’immagine. Correggi solo i percorsi appartenenti all’applicazione, escludendo i contenuti multimediali condivisi o i dataset non correlati.
La guida ZimaSpace su distinguere i problemi di permessi dai montaggi in sola lettura è il controllo successivo quando la proprietà corretta non consente comunque di scrivere.
Riavvia il container e crea, modifica ed elimina un file di test come il vero utente del servizio. Ricrea quindi il container e ripeti il test. La riparazione è completa solo quando la proprietà rimane stabile dopo la copia, l’avvio, il riavvio e la ricreazione del container, e l’applicazione può leggere e scrivere senza eccezioni di permessi generalizzate.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
