Mappatura ID utente con NFS su Synology NAS

Ho un box Synology NAS (con DSM 5.1) e ho esportato una directory tramite NFS. Sto tentando di montarlo sulla mia scatola Ubuntu.

Funziona principalmente bene, ma sto riscontrando problemi con i mapping di utenti e gruppi. Nella casella Ubuntu, sono Uid 1000 (Roger), Gid 1000 (Roger). In Synology, ho uid 1026 (roger), gruppo 100 (utenti).

Se uso NFSv3, utilizza valori numerici uid / gid, il che significa che la proprietà è incasinata su Synology.

Se dovessi accedere al mount NFS solo dalla stessa casella Ubuntu, usando lo stesso utente, andrebbe bene, ma accederei anche alla directory da una finestra di Windows, usando CIFS (SMB), il che significa che le autorizzazioni sono sbagliato.

Se uso NFSv4 ( mount -o nfsvers=4), con le impostazioni predefinite su Synology, i file di proprietà roger.userssu Synology appaiono di proprietà roger.usersquando visualizzati dalla casella Ubuntu. Questo è buono.

Tuttavia, quando ho touchun file:

roger@ubuntu$ touch /mounts/diskstation/music/foo

Finisce di proprietà di 1000.1000Synology e mostrato come di proprietà nobody.4294967294quando viene visualizzato dalla casella Ubuntu.

Tutto ciò che posso trovare sull'argomento nei forum Synology è datato dal 2011, quando NFSv4 non era supportato, o è costituito da persone che fanno la stessa domanda e poi rinunciano.

Per completezza, /etc/exportsha:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

... e lo sto montando sulla scatola di Ubuntu con:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

Ho trovato alcuni suggerimenti che sec=syspotrebbero rappresentare un problema: perché la mappatura uid / gid di NFSv4 non funziona con AUTH_UNIX (AUTH_SYS) , ma non ha una soluzione.

C'è un modo semplice per aggirare questo problema? Esiste un modo più complesso ( tosse Kerberos tosse ) per risolvere questo?

Scherzi a parte, se Kerberos è la risposta, prenderò quel colpo, ma mi piacerebbe sapere prima di perdere un sacco di tempo su di esso.

Aggiornamento : mentre la documentazione di Synology parla di varie opzioni di Kerberos, non riesco a trovarle nell'interfaccia utente. Le note di rilascio dichiarano "Se è implementato il sapore di sicurezza Kerberos ...". Ho trovato (ma non riesco a trovare di nuovo) una pagina che implica che potrebbe non essere presente su alcuni modelli. Ho un DS211, secondo la pagina Informazioni sul sistema. Forse sono sfortunato?

Affinché il mapping degli ID NFSv4 funzioni correttamente, sia il client che il server devono eseguire il idmapddemone ID Mapper e avere lo stesso Domainconfigurato /etc/idmapd.conf.

In questo modo il tuo client NFS invia le sue credenziali ID come roger@example.comnei comandi NFS sulla rete e l'idmapper del tuo server NFS lo associa a un utente chiamato rogersul server NFS. L'UID e il GID non contano, sono mappati su ciascun sistema da idmapper.

Tuttavia, non mi preoccupo di questo sulla mia Synology. La mia cartella condivisa ha le seguenti autorizzazioni:

• permessi
  • Utenti locali
    • Ammin = lettura / scrittura
• Autorizzazioni NFS
  • Schiacciare
    • Mappa tutti gli utenti all'amministratore

Ciò comporta anonuid=1024,anongid=100l' aggiunta ( admindell'utente e del usersgruppo) all'esportazione /etc/exportssul NAS.

Il mio client NFS (che non ha ID Mapper in esecuzione) invia i miei comandi NFS come mio utente ( 1000:1000) e poiché UID e GID non esistono sul NAS, traduce il mio UID e GID in 1024:100modo che io sia trattato come Utente amministratore che dispone dell'autorizzazione completa.

Questo è un uso terribilmente poco professionale e insicuro di NFS per un ambiente aziendale, ma solo per me accedere ai miei file a casa è un abuso del comportamento di NFS che è accettabile per me.

Un'altra opzione è rendere rogerUID e GID uguali sul client e sul NAS NFS, quindi è possibile utilizzare NFSv4 senza ID Mapping oppure è possibile utilizzare NFSv3 che si basa solo su UID e GID.

Ho davvero avuto problemi con lo stesso identico problema. Ho affrontato l'enorme difficoltà di configurare un server Kerberos con Docker su Synology, impostare la mappatura ID e ancora non mi piaceva il comportamento. Kerberos è troppo ingegnerizzato e difficile da continuare a lavorare su riavvii e automount. Inoltre, la umask predefinita dei file appena creati era 0000 e ogni nuovo file veniva creato in modalità 777, indipendentemente dalla mia umask locale.

La mia soluzione era simile a quella del suprjami, ma l'ho portata un po 'oltre:

• Creare un nuovo utente con l'interfaccia utente Web di Synology, denominarla in modo simile roger.remote. Fare lo stesso per un gruppo di utenti e denominarlo come il nome utente.
• In Synology come root, modifica / etc / passwd e modifica roger.remotel'UID su 1000 e GID su 1000
• modifica / etc / group e cambia anche il gruppo roger.remotesu 1000
• Nell'interfaccia utente Web di Synology, impostare squash su "all users to admin" e salvare
• Di nuovo come root, modifica / etc / exports e cambia l'UID / GID in anonuid=1000,anongid=1000
• Riavvia NFS con /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• Anche questo è un po 'confuso, ma chmod 777 /volume1. Ho avuto molti strani problemi con la mia directory home montata. KDE non si avviava perché la access()funzione glibc restituiva l'accesso negato sulla directory NFS montata. (Ma qualsiasi sottodirectory funzionerebbe) Anche Firefox aveva un problema simile, dove si rifiutava di salvare i file nella directory montata a causa del controllo di accesso. Anche se i permessi erano corretti e potevo toccare / creare / scrivere file nella directory montata. La modifica della directory padre / volume1 in scrivibile a livello mondiale ha risolto quel problema stupido e ha ingannato le app client per scrivergli.
• Rimuovere tutti gli ACL del filesystem dalla condivisione. Attraverso molte sperimentazioni casuali, ho scoperto che questi ACL causano problemi con la maschera di modalità dei file creati. Non sono un maestro ACL, quindi forse c'è una soluzione più elegante. Come root su Synology, fallo synoacltool -del /volume1/myshare. Dovresti vedere il +simbolo rimosso dall'output ls -l.
• Modifica la proprietà della condivisione per il tuo nuovo utente: chown roger.remote:roger.remote /volume1/myshare
• Cambia la modalità in 755: chmod 755 /volume1/myshare
• Montare il volume sul client, testare le autorizzazioni, dovrebbe funzionare! Assicurati di toccare anche un file e verifica che il tuo umh bash sia applicato correttamente.

$ umask 
0002
$ cd / mnt / myshare
$ touch test
$ ls -l test
-rw-rw-r-- 1 roger roger 0 ott 21 18:15 test

In Synology dovresti vedere:

# ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 ott 21 18:15 test

Godere!