# nfsv4 und no_root_squash – Bug oder Feature?!

## l3u

Ich bin gerade dabei ein NAS einzurichten, und dabei ist mir folgendes aufgefallen: Trotz der Option "no_root_squash" hat man mit root nur dann Schreibzugriff auf eine Freigabe, wenn sie ein bind-mount ist. Beispiel:

Ich habe folgende Exports:

```
# cat /etc/exports 

/srv/nfs        192.168.178.0/24(rw,fsid=0,no_subtree_check)

/srv/nfs/1      192.168.178.0/24(rw,no_root_squash,no_subtree_check)

/srv/nfs/2      192.168.178.0/24(rw,no_root_squash,no_subtree_check)
```

Wenn ich diese einbinde …

```
# mkdir /mnt/1 /mnt/2

# mount.nfs4 skoni:/1 /mnt/1 -o rw,vers=4,_netdev

# mount.nfs4 skoni:/2 /mnt/2 -o rw,vers=4,_netdev
```

… dann sehen sie identisch aus:

```
# mount | grep mnt

skoni:/1 on /mnt/1 type nfs4 (rw,vers=4,addr=192.168.178.80,clientaddr=192.168.178.80,_netdev)

skoni:/2 on /mnt/2 type nfs4 (rw,vers=4,addr=192.168.178.80,clientaddr=192.168.178.80,_netdev)
```

Aber ich kann nur in /mnt/1 als root schreiben:

```
# touch /mnt/1/foo

# touch /mnt/2/foo

touch: cannot touch '/mnt/2/foo': Permission denied
```

Der Unterschied ist, dass die Freigabe 1 ein bind-mount ist, und die Freigabe 2 einfach nur ein Verzeichnis:

```
# mount | grep /srv

/var/tmp/1 on /srv/nfs/1 type none (rw,bind)
```

Sollte das nicht egal sein? Oder müssen alle Exports aus dem virtuellen nfsv4-root-Verzeichnis bind-mounts sein?

----------

## musv

Ob alle Verzeichnisse im virtuellen Root per bind gemountet werden müssen, weiß ich nicht. Aber no_root_squash bedeutet:

http://wiki.ubuntuusers.de/NFS

 *Quote:*   

> Bindet man per NFS Verzeichnisse ein, die auf dem Server dem User root gehören, werden diese auf den User nobody gemappt und man kann diese nicht modifizieren. Um dieses Sicherheitsfeature zu umgehen, dient der Parameter 'no_root_squash' (weitere Info mit man 5 exports). 

 

----------

## l3u

Mir ist schon klar, was no_root-squash bedeutet. Mir ist nur nicht klar, ob ich einen Bugreport schreiben soll, weil es nur funktioniert, wenn die Freigabe ein bind-mount ist ;-)

----------

## py-ro

AFAIK Working as intended, vergleiche auch https://wiki.gentoo.org/wiki/NFSv4#NFS_shares

----------

## l3u

Jaja, ich hab auch gelesen, dass man die zu exportierenden Verzeichnisse per bind-mount in das virtuelle root-Export-Verzeichnis einbaut. Da steht aber nichts davon, dass man das muss, weil es sonst zu unerwartetem Verhalten kommen kann … deswegen sieht das eben für mich doch wie ein Bug aus, weil eigentlich sollte doch der nfsd gar nicht wissen, ob ich einen bind-mount oder ein „blankes“ Verzeichnis habe, oder?

[edit]

Okay, dann hätten wir das auch geklärt: https://bugzilla.kernel.org/show_bug.cgi?id=76431

Ist tatsächlich ein Feature, kein Bug ;-)

Liegt daran, dass der Export ein Unterverzeichnis des "root"-Exports ist, der restriktivere Einstellungen hat und "no_subtree_check" aktiviert ist. So richtig kann ich das zwar aus der Manpage nicht rauslesen, aber scheinbar gehört das so.

Wäre natürlich zu überlegen, ob man das im Wiki nicht explizit nennt, weil vielleicht hat jemand anderes das selbe "Problem" und löst es damit, einfach nfsv3 statt nfsv4 zu nehmen … man liest ja verschiedentlich, dass nfsv4 Probleme machen würde. Vielleicht ist das ja eines davon …

----------

## musv

Ich glaub, Dein Problem ist einfach der wunde Punkte bei NFS. Es ist zwar ausführlich dokumentiert. Aber leider versteht man nur die wenigsten Sachen, bzw. liest es sich äußerst komplex.

Als ich damals meine Netzwerkstruktur zusammengebastelt hab (Portage auf NFS, Root-Laufwerk vom Notebook freigeben zwecks chroot-Cross-Compiling, Home-Verzeichnisse freigeben), hab ich auch ziemlich geschwitzt. 

Auch die NFS-Startscripte für Systemd waren ein Grauen. Hat mich auch einige Tage gekostet. 

An dem Punkt ist bei NFS noch seeeeeeeeeeeeeeeeeeeeeeehr viel Potential vorhanden.

----------

