staging.inyokaproject.org

Hallo zusammen,

ich habe hier ein Testnetzwerk aufgebaut und habe Probleme dass ich als User root am Client keine Rechte auf das gemountete NFSv4-Share habe. Das sollte ja eigentlich die Option 'no_root_squash' in der exportfs lösen. Tut sie aber nicht.

Etwas zur Umgebung. Der Server basiert auf Debian 10. Dort läuft ein ADS (Samba4) und Kerberos. Der Client (Ubuntu 20.04) ist mittels ADS_JOIN in der Domäne.

Die exportfs am Server:

1

"/home" -rw,no_root_squash,sync,no_subtree_check,sec=krb5i * # LDAP:cn=home,cn=shares,dc=intern,dc=lan

Das /home auf dem Server:

1

drwxr-xr-x   5 root Domain Users    55 Feb  6 17:03 home

Auf dem Client mounte ich das Share als root mit:

1

mount -t nfs4 -o sec=krb5i srv01.intern.lan:/home /home

Dort kommt es auch mit den korrekten Rechten an:

1

drwxr-xr-x   5 root domain users         55 Feb  6 17:03 home

Als Benutzer auf dem Client angemeldet:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

ich@pc001:~$ id
uid=1686801128(ich) gid=1686800513(domain users) Gruppen=1686800513(domain users),1686801116(default)
...
ich@pc001:~$ pwd
/home/ich
...
ich@pc001:~$ cd /home/ich/
ich@pc001:~$ ls -l
insgesamt 0
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Bilder
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Dokumente
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Downloads
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Musik
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Öffentlich
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Schreibtisch
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Videos
drwxr-xr-x 2 ich domain users  6 Feb  6 17:04 Vorlagen
drwx--x--x 7 ich domain users 96 Feb  6 17:03 windows-profiles

Wenn ich nun mit su (ich habe einen echten root Account und kein sudo) zu root wechsle und versuche im Userhome den Inhalt anzuzeigen habe ich keine Rechte:

1
2
3
4
5

ich@pc001:~$ su
Passwort: 
root@pc001:/home/ich# ls
ls: Öffnen von Verzeichnis '.' nicht möglich: Keine Berechtigung
root@pc001:/home/ich#

Sollte die Option 'no_root_squash' nicht genau das ermöglichen? Oder wo habe ich einen Denkfehler?

Beste Grüße pixel24

Klingt nach einem ähnlichen Problem wie in https://serverfault.com/questions/526762/root-access-to-kerberized-nfsv4-host-on-ubuntu/526820#526820

Prima. Ja, das klingt passend. Schaue ich mir an. Danke

In meinem ADS gibt es folgende Einträge in Kerberos bezüglich NFS:

1
2
3

dn: CN=nfs-srv01,CN=Users,DC=intern,DC=lan
userPrincipalName: nfs-srv01@INTERN.LAN
servicePrincipalName: nfs/srv01.intern.lan

Bezugnehmen auf den Link habe ich die idmapd.con nun wie folgt angepasst:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
Domain = intern.lan

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

[Translation]
GSS-Methods = static,nsswitch

[Static]
nfs/srv01.intern.lan@INTERN.LAN = root

Muss die Datei auf dem Client nun auch so erweitert werden?

Alle Dienste neu gestartet. Wenn ich nun am besagten Client als root im User-Home ein 'ls' ausführe erhalte ich im Server-Log ein:

1

Feb 06 19:07:31 srv01 rpc.idmapd[340]: nss_getpwnam: name '1686801128' does not map into domain 'intern.lan'

Als würde er ID#s anstatt Namen senden.

Nutzt du auf dem Server gssproxy oder svcgssd?

seahawk1986 schrieb:

Nutzt du auf dem Server gssproxy oder svcgssd?

svcgssd

Das Problem scheint daran zu liegen dass auf dem Server der Parameter:

1

/sys/module/nfsd/parameters/nfs4_disable_idmapping = Y

ansatt 'N' ist was ich temporär über:

1

echo "N" > /sys/module/nfsd/parameters/nfs4_disable_idmapping

erreichen kann. Anschließend den svcgssd Service neu starten.

Ab Ubuntu-Client existiert dieser Parameter überhaupt nicht bzw ich weiß nicht wie ich ihn prüfen kann.

Die Namensgabe des Parameter ist höchst irreführen den anscheinend 'N' bedeutet wohl 'aktivieren'.

Auf jeden Fall, in /etc/default/nfs-common gibt es eine Option NEED_IDMAPD=.