Perché i permessi dei file si rompono dopo aver spostato i file su un NAS?

I file possono funzionare normalmente su un computer, disco esterno o cartella di download e poi diventare di sola lettura, invisibili a un'app o inaccessibili dopo essere stati spostati su un NAS. Questo di solito non significa che i dati del file siano danneggiati. Significa che i file sono entrati in un nuovo filesystem con un modello di proprietà e permessi diverso.

Uno spostamento tra dispositivi è comunemente eseguito come una copia seguita dalla cancellazione della sorgente. Il NAS crea nuovi file usando l'identità SMB o NFS connessa, le ACL della cartella di destinazione, i valori UID e GID, umask, utente container e regole di creazione lato server. Il modo più veloce per risolvere il problema è identificare chi ha creato i file, chi li possiede ora e quale utente o processo viene negato.

Spostare file su un NAS di solito crea nuovi file

Trascinare una cartella su un NAS può sembrare uno spostamento ordinario in Windows Explorer o Finder. Tuttavia, sotto, il disco sorgente e il NAS sono filesystem separati. Il client legge i dati originali, crea nuovi oggetti di destinazione e cancella gli originali dopo che il trasferimento ha successo.

Questo differisce dallo spostamento di un file tra due cartelle nello stesso filesystem, dove il sistema può solo aggiornare la posizione della directory del file. La descrizione di Microsoft sul comportamento di copia e spostamento spiega che gli oggetti copiati in un altro volume ereditano i permessi della nuova cartella, mentre uno spostamento nello stesso volume normalmente mantiene i permessi esistenti.

Questa distinzione spiega perché “Taglia e Incolla” non garantisce che proprietà, voci ACL o attributi estesi rimangano identici dopo un trasferimento su un NAS. Il sistema di destinazione non si limita a spostare l'oggetto originale del filesystem.

Le ACL di destinazione decidono cosa ereditano i nuovi file

Se ogni nuovo file copiato riceve le stesse autorizzazioni inaspettate, di solito la directory padre è più importante del file sorgente. La destinazione può aver ereditato voci ACL, ACL POSIX predefinite, flag ACL NFSv4 o preset di permessi specifici per NAS.

Ad esempio, una cartella condivisa può essere configurata in modo che i nuovi file ereditino l'accesso per un gruppo familiare, un gruppo multimediale o un particolare account SMB. Una mancanza del flag di ereditarietà può creare l'effetto opposto: gli utenti possono accedere alla radice del dataset ma non ai nuovi file al suo interno.

I sistemi di permessi in stile TrueNAS distinguono i modelli POSIX e ACL NFSv4/SMB. Il comportamento importante è che l'ereditarietà ACL NFSv4 e SMB può controllare nuovi file e cartelle, mentre i valori predefiniti POSIX e i confini dei dataset si comportano diversamente. Prima di modificare singoli file, ispeziona l'ACL e i flag di ereditarietà sulla cartella di destinazione.

Il NAS usa l'account SMB connesso

Quando un computer Windows o macOS copia un file tramite SMB, il NAS normalmente non conserva l'identità utente locale del computer client. Crea il file di destinazione come l'account autenticato alla condivisione SMB, o come un account a cui quella sessione è mappata.

Ecco perché un file di proprietà di un utente Windows sul PC sorgente può essere di proprietà di kenneth, nasuser, guest, o un'altra identità lato NAS dopo il trasferimento. Una credenziale SMB salvata può anche far sì che un computer crei file con un proprietario diverso rispetto a un altro computer.

Controlla il nome utente SMB attivo invece di presumere che venga usato l'accesso desktop. Disconnetti la condivisione, cancella le credenziali obsolete se necessario e riconnetti con l'account NAS che dovrebbe possedere o gestire i file.

Accesso alla condivisione e accesso ai file sono livelli di permesso separati

Un utente può aprire la condivisione SMB e navigare nelle cartelle ma non essere comunque in grado di modificare, rinominare o cancellare un file. Questo significa che la condivisione di rete è raggiungibile; non prova che il filesystem abbia concesso l'operazione richiesta.

Le regole a livello di condivisione determinano se un client SMB o NFS può accedere alla condivisione e se la connessione è presentata come sola lettura o lettura/scrittura. Il filesystem sottostante valuta quindi proprietario, gruppo, bit di modalità, voci ACL e regole di ereditarietà per ogni file e directory.

Risolvi i problemi su entrambi i livelli. Una condivisione marcata come lettura/scrittura non può sovrascrivere un ACL del filesystem che nega la scrittura, e modalità permissive del filesystem non aiutano quando l'account SMB è limitato dalla configurazione della condivisione.

Gli ACL in stile Windows e i bit di modalità POSIX non si mappano perfettamente

i permessi di Windows possono contenere più utenti e gruppi, voci esplicite di consentito e negato, flag di ereditarietà e diritti separati per lettura, scrittura, cancellazione e modifica. I tradizionali bit di modalità POSIX riducono l'accesso a proprietario, gruppo e altri.

Samba e i sistemi operativi NAS devono tradurre tra questi modelli. Un pannello di sicurezza di Windows può mostrare un ACL dettagliato anche se ls -l mostra solo una rappresentazione semplificata. Al contrario, eseguire chmod possa modificare i bit di modalità senza ricostruire correttamente l'ACL in stile Windows che i client SMB si aspettano.

Se il dataset NAS utilizza ACL NFSv4 o SMB, ispeziona l'ACL completa tramite l'interfaccia NAS o un comando che supporta le ACL. Non presumere che un file che mostra rwxrwx--- racconta tutta la storia dei permessi.

Disallineamenti tra UID e GID influenzano Linux, NFS e le app

I sistemi Linux di solito determinano la proprietà tramite ID utente e gruppo numerici. Il nome utente è solo un'etichetta associata a quei numeri.

Due sistemi possono entrambi mostrare un utente chiamato media mentre uno usa UID 1000 e l'altro UID 1001. Per Linux e NFS, sono identità diverse. Un file di proprietà di UID 1000 può essere inaccessibile a un'applicazione in esecuzione come UID 1001 anche se i loro nomi utente visibili sembrano identici.

Controlla i valori numerici su NAS, host, client e applicazione:

id media
ls -ln /path/to/files
stat /path/to/files/example.mkv

Confronta i numeri invece dei soli nomi visualizzati. Se più sistemi devono scrivere lo stesso storage, allinea i valori UID/GID richiesti o crea un gruppo condiviso con i permessi corretti.

SMB e NFS possono scrivere lo stesso dataset come utenti diversi

I problemi di permessi spesso si manifestano gradualmente quando i client SMB e NFS hanno entrambi accesso in scrittura alla stessa directory. I file caricati tramite SMB possono appartenere a un utente NAS, mentre i file creati tramite NFS possono avere un UID numerico di un altro sistema.

I due protocolli possono anche applicare regole diverse di ACL e mappatura delle identità. Di conseguenza, una cartella può contenere file che appaiono identici a un utente ma hanno proprietari, gruppi, maschere o voci ereditate differenti.

Scegli un protocollo di scrittura principale quando possibile. Quando SMB e NFS devono condividere un dataset, allinea gli ID numerici, i gruppi condivisi, le ACL predefinite, i valori umask e il comportamento di creazione prima di inserire dati di produzione.

I contenitori Docker aggiungono un'altra identità utente

Un file può essere leggibile tramite SMB ma non disponibile per Plex, Jellyfin, Nextcloud, un downloader o un contenitore di backup. Docker può montare il percorso corretto mentre il processo all'interno del contenitore manca ancora del permesso di leggerlo o scriverlo.

Un processo del contenitore viene eseguito con un UID e un GID propri. Se quell'identità non corrisponde al proprietario o a un gruppo autorizzato sul percorso NAS montato, l'applicazione riceve Permesso negato. Un mount di volume rende la directory visibile; non bypassa l'autorizzazione del filesystem.

Una soluzione comune è abbinare l'UID e il GID del contenitore con l'identità autorizzata a usare il volume montato. Verifica l'identità effettiva del processo invece di affidarti solo a un campo PUID o PGID mostrato in un file Compose:

docker exec container-name id
docker exec container-name ls -ln /data
docker exec container-name test -w /data && echo "Scrivibile"

Un contenitore può creare file che un altro non può leggere

Questo accade frequentemente negli stack di automazione dei media. Un contenitore di download scrive con successo un file completato, ma il server multimediale non riesce a scansionarlo, oppure un organizzatore non può rinominarlo.

Le applicazioni possono usare valori UID/GID diversi o umask diverse. Se il downloader crea file come 600, solo il proprietario può leggerli e scriverli. Una modalità come 640 consente la lettura al gruppo, ma solo quando entrambe le applicazioni condividono il gruppo corretto.

Per directory applicative condivise, usa un gruppo proprietario pianificato, aggiungi le identità applicative necessarie a quel gruppo e seleziona una umask che dia al gruppo l'accesso richiesto. Sistemare solo i file vecchi non aiuterà se il downloader continua a creare nuovi file con modalità restrittive.

Umask e regole di creazione server controllano i nuovi permessi

Se i file vecchi funzionano ma ogni nuovo file è inaccessibile, il processo di creazione è la causa probabile. Ogni programma inizia con una modalità file richiesta, e la sua umask rimuove permessi selezionati prima che il file venga creato.

Samba può anche usare impostazioni come maschera creazione, maschera directory, forza utente, o forza gruppo. Le interfacce NAS possono nascondere questi dietro modelli di permessi, preset di cartelle condivise o opzioni di eredità.

Crea un file di test attraverso ogni percorso: Windows SMB, macOS SMB, gestore file NAS, NFS e ogni contenitore rilevante. Confronta proprietario, gruppo, modalità e ACL risultanti. Questo rivela rapidamente quale percorso di creazione produce permessi errati.

Diversi strumenti di trasferimento preservano metadati diversi

Finder, Esplora risorse di Windows, un'interfaccia web NAS, cp, e rsync non garantiscono risultati identici. Alcuni preservano i timestamp, altri possono mantenere le modalità POSIX, e altri semplicemente creano nuovi file secondo le regole della destinazione.

Prima di scegliere un metodo di migrazione, decidere quali proprietà devono sopravvivere:

• Contenuti dei file e struttura delle directory
• Tempi di modifica
• Permessi POSIX
• Proprietario e gruppo
• Voci ACL
• Attributi estesi
• Collegamenti simbolici

Per documenti familiari ordinari o file multimediali, l'eredità della destinazione può essere preferibile alla conservazione degli account del computer sorgente che non esistono sul NAS. Per dati applicativi, directory home Linux o migrazioni server, preservare proprietà e metadati ACL può essere essenziale.

Rsync non preserva ogni attributo con un comando base

Rsync è utile per migrazioni NAS controllate, ma il risultato dipende dalle sue opzioni, dai privilegi dell'utente che esegue e dalle capacità dei filesystem di origine e destinazione.

La modalità archivio conserva i metadati comuni inclusi modalità, timestamp, gruppi e proprietà dove consentito. Sono necessarie opzioni aggiuntive quando la migrazione deve preservare permessi, ACL e attributi estesi con rsync. Un test tipico da Linux a Linux può usare:

rsync -aAX --numeric-ids --dry-run /source/ user@nas:/destination/

Il -A l’opzione preserva le ACL e -X preserva gli attributi estesi quando entrambi i lati li supportano. --numeric-ids dovrebbe essere usato deliberatamente perché preservare un proprietario numerico che non ha un account valido sul NAS può riprodurre proprio la discrepanza che si cerca di evitare.

Una destinazione rsync montata via SMB potrebbe non comportarsi come il filesystem NAS

Eseguire rsync da un computer su una condivisione SMB montata localmente non è sempre equivalente a eseguire rsync via SSH direttamente sul filesystem NAS. Il livello SMB può mappare i proprietari, trasformare le ACL o rifiutare tentativi di impostare attributi.

L’utente che esegue la copia SMB potrebbe non avere il permesso di assegnare proprietà arbitraria, anche quando rsync lo richiede. Il filesystem di destinazione potrebbe inoltre supportare un modello ACL diverso da quello di origine.

Testa prima una piccola directory rappresentativa. Esamina i file direttamente sul NAS dopo il trasferimento, non solo tramite la condivisione montata dal client. Conferma proprietà, modalità, ACL, attributi estesi e accesso alle applicazioni prima di migrare l’intero dataset.

Le impostazioni predefinite dei permessi NAS possono sovrascrivere i semplici bit di modalità

Alcuni sistemi NAS gestiscono l’accesso tramite modelli ACL del dataset e metadati estesi piuttosto che solo con le modalità tradizionali proprietario/gruppo/altro. Questo può rendere manuale chmod possono sembrare riuscite mentre SMB o un’applicazione continuano a negare l’accesso.

Un dataset può anche essere configurato per riapplicare regole ereditate quando vengono creati nuovi file o quando i permessi vengono modificati tramite l’interfaccia di gestione. Mescolare ACL gestite tramite GUI con modifiche ripetute da linea di comando può produrre uno stato incoerente.

Scegli un modello di permessi e gestiscilo in modo coerente. Se il dataset è configurato per un ACL SMB/NFSv4, usa l’editor ACL del NAS o strumenti compatibili con ACL invece di sostituire ripetutamente la struttura con comandi in modalità POSIX.

Reinstallare il NAS non resetta necessariamente i permessi dei dati

I permessi di solito appartengono ai file e al dataset del filesystem, non solo alla configurazione del sistema operativo NAS. Reinstallare il sistema di avvio può quindi lasciare gli stessi proprietari e voci ACL inaccessibili su un pool di archiviazione importato.

Un caso della community TrueNAS illustra come i permessi del filesystem rimangono associati al pool di archiviazione e devono essere abbinati agli utenti corretti e alla configurazione di accesso appropriata. Mostra anche il rischio di effettuare grandi modifiche ricorsive senza prima comprendere il modello di identità previsto.

Prima di reinstallare o ricostruire servizi, ispeziona il proprietario del dataset, il gruppo, l’ACL e gli utenti dell’applicazione. I dati potrebbero essere intatti e richiedere solo il corretto ripristino delle regole di accesso.

Perché chmod 777 ricorsivo non è una vera soluzione

Quando migliaia di file diventano inaccessibili, chmod -R 777 sembra un modo veloce per ripristinare l’accesso. Concede permessi di lettura, scrittura ed esecuzione al proprietario, al gruppo e a ogni altra identità locale.

Questo può esporre dati privati, permettere a servizi non correlati di modificare file, impostare permessi di esecuzione su documenti ordinari e danneggiare una struttura ACL ereditata con cura. Inoltre non corregge il proprietario errato, l’UID del container non corrispondente, la mancanza di appartenenza al gruppo o la mappatura identità SMB rotta.

Usa invece il modello di accesso previsto: stabilisci il proprietario corretto e il gruppo condiviso, ricostruisci l’ACL appropriata, imposta separatamente le modalità di directory e file, e correggi l’eredità futura e le impostazioni umask. Testa su una piccola cartella prima di applicare modifiche ricorsive.

Ripara i permessi partendo dall’identità

Inizia dall’utente o processo negato piuttosto che dal comando che speri risolva. Un utente SMB umano, un media server e un container di backup possono richiedere livelli di accesso diversi.

Per ogni flusso di lavoro interessato, registra:

• L’utente o processo che tenta l’accesso
• Il suo UID e GID numerici, se applicabili
• Il protocollo o il mount usato
• Il proprietario e il gruppo attuali del file
• L’ACL completa e le voci ereditate
• L’accesso effettivamente richiesto: lettura, creazione, modifica o eliminazione

Poi modifica solo il livello errato. Aggiungi l’utente a un gruppo consentito, correggi la proprietà, ripara l’ACL, allinea un UID del container o aggiorna la regola di creazione. Evita di concedere accessi più ampi di quelli necessari al flusso di lavoro.

Segui un ordine di risoluzione a strati

Modificare contemporaneamente ACL della condivisione, identità del container, esportazione NFS e modalità file distrugge prove utili. Testa un livello di permessi alla volta.

Inizia con un file interessato e un utente o applicazione interessati. Una volta che quel caso funziona, crea un nuovo file tramite il flusso di lavoro normale e conferma che la correzione impedisce anche il ritorno del problema.

Prevenire problemi di permessi prima di una grande migrazione NAS

Riparare i permessi su centinaia di migliaia di file è molto più difficile che testare il modello di accesso prima della migrazione. Crea una piccola cartella di destinazione con la stessa ACL e configurazione applicativa prevista per il dataset finale.

Copia diversi tipi di file, directory annidate, file di sola lettura, script eseguibili e file con attributi estesi. Testali da ogni percorso richiesto: SMB, NFS, l'interfaccia NAS, software di backup e contenitori rilevanti.

Inizia la migrazione completa solo dopo che i nuovi file ricevono costantemente il proprietario, il gruppo, l'ACL e l'accesso applicativo corretti. Conserva uno snapshot o un backup prima di applicare modifiche ricorsive a proprietà o permessi sui dati esistenti.

Conclusione finale

I permessi dei file si rompono dopo aver spostato i dati su un NAS perché il trasferimento di solito crea nuovi oggetti filesystem. Questi oggetti sono governati dall'account NAS usato per il trasferimento, dall'ACL di destinazione, dai valori UID/GID, dall'umask, dalla mappatura del protocollo e dall'identità dell'applicazione o del contenitore.

Non iniziare con chmod 777. Prima rispondi a tre domande: chi ha creato il file, chi ne è il proprietario ora e quale identità viene negata. Poi ispeziona l'accesso alla condivisione, le ACL del filesystem, l'eredità, gli ID del contenitore e le regole di creazione future.

Una riparazione riuscita dovrebbe fare due cose: ripristinare l'accesso appropriato ai file esistenti e garantire che il prossimo file copiato, scaricato o creato sul NAS riceva automaticamente i permessi corretti.

FAQ

Perché i file copiati ereditano i permessi della cartella NAS?

Un trasferimento a un NAS di solito crea nuovi file su un altro filesystem. I nuovi oggetti ricevono comunemente i permessi dall'ACL della cartella di destinazione, dai flag di eredità e dalle regole di creazione lato server.

Perché posso aprire i file NAS tramite SMB ma il mio contenitore Docker no?

La sessione SMB e il contenitore usano identità diverse. Controlla l'UID e il GID effettivi del contenitore, la proprietà numerica del percorso montato, l'appartenenza al gruppo e se il mount è in sola lettura.

Devo usare chmod 777 per riparare una condivisione NAS?

No. Concede a ogni identità locale un accesso ampio, può danneggiare l'eredità delle ACL e non risolve la proprietà errata o la mappatura UID/GID. Definisci gli utenti e i gruppi previsti, quindi ripara proprietà e ACL di conseguenza.

Rsync può preservare i permessi dei file NAS?

Può preservare i permessi POSIX e altri metadati quando le opzioni selezionate, i privilegi di esecuzione e entrambi i filesystem li supportano. ACL e attributi estesi richiedono opzioni aggiuntive come -A e -X.

Perché i nuovi file continuano a rompersi dopo aver riparato i file vecchi?

Il percorso di creazione è ancora errato. Controlla l'ACL ereditata della cartella di destinazione, l'identità SMB o NFS, l'umask dell'applicazione, le regole di creazione Samba e l'UID/GID del contenitore.