Come posso ottenere l'accesso in lettura / scrittura alla condivisione NFS di Synology NAS?


11

Ho accesso in lettura solo alla condivisione NFS montata.

Con 'no squash mapping' impostato sul NAS, l'utente regolare Ubuntu ottiene Permission deniedquando prova a cdcondividere e può ottenere l'accesso in lettura solo usando sudo.
Utilizzando l'impostazione "mappa tutti gli utenti all'amministratore" di squash, l'utente normale del client può cdaccedere e ha solo l'accesso in lettura alla condivisione. L'uso sudonon consente la scrittura.


Synology NAS:
DS214> id username
uid=1026(username) gid=100(users) groups=100(users),101(administration)

no squash (nessuna mappatura)
DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

all squash (mappa tutti gli utenti all'amministratore)
DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=1024,anongid=100)

Client Ubuntu:
$ cat /etc/fstab
10.1.1.214:/volume1/Files /mnt/nfs/Files nfs rw,user,auto 0 0

$ id username
uid=1000 gid=1000(username) groups=1000(username), <etc>

$ ls -n /mnt/nfs
drwxrwxrwx 9 0 0 4096 Sep 25 01:28 Files

$ ls -n /mnt/nfs/Files
drwxr-xr-x 11 1026 100 4096 Sep 24 22:05 Data


(Inizialmente avevo postato per errore l'utilizzo sudodell'accesso in scrittura abilitato) Posso aprire un file nella condivisione NFS montata sudo vi /mnt/nfs/Files/Data/test.filema non posso scrivere le modifiche al file anche con sudo. Il messaggio di errore vi su :w!comando è:
"test.file" E212: Can't open file for writing


NFS controlla le autorizzazioni di accesso rispetto agli ID utente (UID). L'UID dell'utente sul tuo computer locale deve corrispondere all'UID del proprietario dei file a cui stai tentando di accedere sul server . Vai al server e guarda le autorizzazioni del file. A quale UID (scoprilo con id username) appartengono e quali autorizzazioni sono impostate?
Nephente,

Riesci anche cda montare sul monte come utente normale? Se sì, suggerisco quanto segue. Per confermare o confutare il mio sospetto, procedi come segue: Sul client cdnel mount e fai ls -n. Verranno elencati i proprietari dei file e i gruppi con i rispettivi ID. Dovrai farlo con sudoimmagino. Aggiungi una o due righe dell'output alla tua domanda, insieme all'output di id (no sudo!) Se non riesci nemmeno cda montare come utente normale, dovrai controllare le autorizzazioni della directory su cui stai esportando il server.
Nephente,

Non potevo cdentrare nel mount come utente normale. L'uso di Squash sul server per forzare le autorizzazioni funziona come una correzione temporanea per concedere le autorizzazioni. Indagare sulle autorizzazioni del server e id username.
Marsilea,

Grazie, penso che sarebbe meglio usare nfs nel modo corretto piuttosto che solo la forza bruta con Squash: 'Mappa tutti gli utenti
all'amministratore

Dipende. Ti fidi dei clienti e degli utenti? In caso contrario, NFSv3 non è adatto dopo tutto, poiché chiunque abbia accesso root a un client, può falsificare gli UID. Se hai bisogno di un'autenticazione corretta, è meglio usare SMB. L'autenticazione con NFSv4 richiede l'esecuzione di un Kerberos che è piuttosto complicato. Tuttavia, la tua uscita mi sconcerta ... Suppongo che il punto di montaggio sia /mnt/nfs/Files. Sebbene Filesappartenga a root, l'autorizzazione consente a chiunque di fare qualsiasi cosa. Non ha senso per me perché avresti problemi a inserire quella directory come qualsiasi utente. Forse pubblicare la riga pertinente da /etc/exports?
Nephente,

Risposte:


11

NFSv2 / 3 gestisce le autorizzazioni esclusivamente in base a UID e GID. Le autorizzazioni dei file sul server vengono confrontate con gli ID utente e di gruppo sul client. Questo è il motivo per cui NFSv <4 è insicuro in ambienti in cui gli utenti hanno accesso root ai computer client; Lo spoofing UID in questo caso è banale.

Si noti che NFSv4 offre l'autenticazione client e utente tramite Kerberos5. Se è necessaria l'autenticazione con nome utente e password, è spesso molto più semplice ricorrere a Samba (SMB / CIFS) invece di configurare un Kerberos, anche in ambienti Linux puri.

Per almeno evitare escalation di privilegi di root, condivisioni NFS vengono esportati per default con l'opzione root_squash, che sarà mappare tutte le richieste del cliente proveniente da root (uid=0, gid=0)a anonuided anongid. Questo comportamento può essere ignorato no_root_squash, garantendo l'accesso root all'esportazione.

Qui vediamo un altro inconveniente. Per funzionare correttamente, NFS richiede sostanzialmente di avere lo stesso UID / GID su tutte le macchine. I file a cui si desidera accedere appartengono 1026e dispongono delle autorizzazioni 755. L'utente sul client dispone uid=1000. I GID non corrispondono neanche, quindi ottieni solo autorizzazioni mondiali. Quindi nessun accesso in scrittura.

Per risolvere questo, è possibile effettuare una delle seguenti operazioni:

  • Sul NAS, modificare il proprietario dei file in 1000. Potrebbe essere necessario creare quel particolare account. Come questo influenzerà altri servizi, non posso dirlo.

  • Cambia l'UID dell'utente locale in 1026.

  • Poiché sei l'unico ad accedere ai file sul server, puoi fare in modo che il server faccia finta che tutte le richieste provengano dall'UID corretto. Per questo, NFS ha l'opzione all_squash. Indica al server di mappare tutte le richieste all'utente anonimo, specificato da anonuid,anongid.

    Aggiungi le opzioni all_squash,anonuid=1026,anongid=100all'esportazione in /etc/exports.

Siate cauti però, poiché questo renderà chiunque montare in modo efficace l'esportazione il proprietario di quei file!

Se condividi la tua rete con persone e loro clienti di cui non ti fidi completamente per non creare problemi con i tuoi file, dovresti davvero cercare un metodo di condivisione dei file che offra l'autenticazione. Secondo me, Samba è il modo più semplice per raggiungere questo obiettivo.


Ho scelto NFS perché pensavo che potesse avere vantaggi per Linux su Linux, in quanto mi piacerebbe poter eseguire il backup del NAS tramite sincronizzazione su unità USB esterna sul client Ubuntu (il sistema DSM di Synology non offre la sincronizzazione con unità USB) , mantenendo al contempo la proprietà del file e le informazioni sulle autorizzazioni. Una risposta completa e grazie per la guida.
Marsilea,

0

Fare showmount -e 10.1.1.214per vedere le opzioni di esportazione. Permission deniedl'errore proviene dal server NFS stesso. Prova a cambiare opzione da rw,user,autoa defaults.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.