NFS Konfiguration (keine Schreibrechte)

[chris71]

Hallo erstmal

früher war alles einfacher, da gab es kein Pseudo-Dateisystem und nix wurde automatisch gemountet. Heute stehe ich vor dem Problem, dass die NFS 4 Anleitungen fehlerhaft oder unvollständig sind. Ich mache schon eine ganze Zeit rum, bekomme aber keine Schreibrechte auf der Freigabe. Ich sehe gerade den Wald vor lauter Bäumen nicht, vielleicht ist es trivialer als ich denke.

Server:

Code: Alles auswählen

ce@obelix:/exports$ ls -al
insgesamt 20
drwxr-xr-x  5 nobody nogroup 4096 19. Mär 21:51 .
drwxr-xr-x 20 root   root    4096 19. Mär 22:41 ..
drwxr-xr-x  2 root   root    4096 19. Mär 21:50 data
drwxr-xr-x  2 root   root    4096 19. Mär 21:50 documents
drwxr-xr-x  3 root   root    4096 23. Jul 2023  home

ce@obelix:/shared$ ls -al
insgesamt 16
drwxr-xr-x  4 root root 4096 19. Mär 21:50 .
drwxr-xr-x 20 root root 4096 19. Mär 22:41 ..
drwxr-xr-x  2 root root 4096 19. Mär 21:50 data
drwxr-xr-x  2 root root 4096 19. Mär 21:50 documents

ce@obelix:/shared$ cat /etc/fstab 
# /etc/fstab: static file system information.
#...
# nfs
/home /exports/home    none bind
/shared/data /exports/data     none bind
/shared/documents /exports/documents    none bind

ce@obelix:/shared$ cat /etc/exports 
#...
# laut Anleitung
#/exports   192.168.150.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check,crossmnt,fsid=0)
#
# neu
/exports            192.168.150.0/255.255.255.0(ro,sync,all_squash,no_subtree_check,fsid=0)
/exports/data       192.168.150.0/255.255.255.0(rw,sync,all_squash,no_subtree_check)
/exports/documents  192.168.150.0/255.255.255.0(rw,sync,all_squash,no_subtree_check)
/exports/home       192.168.150.0/255.255.255.0(rw,sync,root_squash,no_subtree_check)

Client:

Code: Alles auswählen

ce@falbala:/$ ls -al nfs
insgesamt 20
drwxr-xr-x  5 nobody nogroup 4096 19. Mär 21:51 .
drwxr-xr-x 23 root   root    4096 21. Mär 08:56 ..
drwxr-xr-x  2 root   root    4096 19. Mär 21:50 data
drwxr-xr-x  2 root   root    4096 19. Mär 21:50 documents
drwxr-xr-x  3 root   root    4096 23. Jul 2023  home

ce@falbala:/$ ls -al documents/
insgesamt 8
drwxr-xr-x  2 root root 4096 19. Mär 21:50 .
drwxr-xr-x 23 root root 4096 21. Mär 08:56 ..

ce@falbala:/$ ls -al data/
insgesamt 8
drwxr-xr-x  2 root root 4096 19. Mär 21:50 .
drwxr-xr-x 23 root root 4096 21. Mär 08:56 ..

ce@falbala:/$ ls -al users
insgesamt 12
drwxr-xr-x  3 root root 4096 23. Jul 2023  .
drwxr-xr-x 23 root root 4096 21. Mär 08:56 ..
drwx------  4 ce   ce   4096 21. Mär 16:47 ce

ce@falbala:/$ cat /etc/fstab 
# /etc/fstab: static file system information.
#...
# nfs
192.168.150.111:/ /nfs nfs4 soft,intr,rsize=8192,wsize=8192
192.168.150.111:/home /users nfs4 soft,intr,rsize=8192,wsize=8192
192.168.150.111:/data /data nfs4 soft,intr,rsize=8192,wsize=8192
192.168.150.111:/documents /documents nfs4 soft,intr,rsize=8192,wsize=8192

Nachdem es "einfach so" nicht funktioniert hat habe ich mich streng an diese https://www.howtoforge.de/anleitung/so- ... debian-12/ Anleitung gehalten. Was soll ich sagen, funktioniert auch nicht. Habe mittlerweile ein paar Kleinigkeiten erfolglos geändert.

Warum werden die Eigentümer in der Anleitung von exports UND shared auf nobody geändert? Ich halte das bei shared für überflüssig.

Ein rw in der fstab vom Client bewirkt nichts.

soft und intr stehen sich in meinen Augen entgegen - richtig?

rsize und wsize wichtig?

Aktueller Stand: ich kann IN dem exportierten home Verzeichnis "ce" schreiben - sonst nirgends. Was übersehe ich?

Danke für die Hilfe und Grüße
Chris

[mludwig]

Du hast all_squash in deiner exports drinstehen, damit werden alle UserIDs auf nobody gemappt, und deswegen ist das Ändern des Eigentümers in der Anleitung dann auch nicht überflüssig ... wenn du die Anleitung nicht vollständig befolgst und es dann nicht klappt, solltest du das vielleicht hinterfragen?

[jph]

Die Anleitung ist ohnehin etwas fragwürdig.

• Gemountet wird ohne systemd-Automount. Das sorgt für Vergnügen, wenn der NFS-Server beim Rechnerstart nicht verfügbar ist.
• Die wirkungslose Mount-Option intr wird angegeben.
• Mit welcher Begründung werden rsize/wsize vorgegeben?

Da ist unser eigenes Howto (NFSv4-Mini-Howto) ausgereifter.

[chris71]

Du hast all_squash in deiner exports drinstehen, damit werden alle UserIDs auf nobody gemappt,

Ok, da hast Du Recht, damit unterdrücke ich alle Schreibvorgänge. Es stand auch schon root_squash und no_root_squash drin, ohne Erfolg. Ich kann auch nur in "ce" schreiben und NICHT in home. Warum? Das sollte nach dieser Theorie doch eigentlich funktionieren!

und deswegen ist das Ändern des Eigentümers in der Anleitung dann auch nicht überflüssig ...

Bei /exports habe ich es noch so.
Für /shared habe ich es testweise geändert, weil beim exportierten home auch root der Eigentümer ist.

wenn du die Anleitung nicht vollständig befolgst und es dann nicht klappt, solltest du das vielleicht hinterfragen?

Hatte ich zu 100% und habe dann eben angefangen den Fehler zu suchen.

Edit:
Ich bin jetzt wieder zu 100% zurück zur Konfiguration der Anleitung. Ohne Erfolg. Wo ist in der Anleitung der Fehler? Oder habe ich einen Verständnisfehler und man kann nicht direkt in die Verzeichnisse des exportierten Dateisystems schreiben ohne vorher darin einen Ordner mit den richtigen Berechtigungen anzulegen? Wäre doch eigentlich sinnfrei ...

[mludwig]

Laut Anleitung gibt es auf dem NFS-Server genau 1 exportiertes Verzeichnis, mit no_root_squash, sollte also alle UserIDs beibehalten (auch root). Im Idealfall sind die UserIDs (also die Numerischen IDs) auf Client und Server identisch.

In deinem Post hast du in der Exports /export sowie Unterverzeichnisse mit unterschiedlichen Optionen stehen.

Wenn man ein Verzeichnis sowie die Unterverzeichnisse freigibt, kommt es gern zu dem Effekt, dass die Einstellung des übergeordneten Verzeichnisses die Einstellungen für Unterordner überschreibt. Darüber bin ich mal vor einigen Jahren gestolpert. Weiß aber nicht ob das noch aktuell, oder vielleicht sogar gewollt ist.

[chris71]

Die Anleitung ist ohnehin etwas fragwürdig.

• Gemountet wird ohne systemd-Automount. Das sorgt für Vergnügen, wenn der NFS-Server beim Rechnerstart nicht verfügbar ist.
• Die wirkungslose Mount-Option intr wird angegeben.
• Mit welcher Begründung werden rsize/wsize vorgegeben?

Da ist unser eigenes Howto (NFSv4-Mini-Howto) ausgereifter.

1. Der systemd-fstab-generator sollte den Automount erstellen. Hatte gehofft, dass ich die Option noauto später einfügen kann, wenn das nicht geht erstelle ich den Automount. Erstmal muss es so gehen.

2. intr kann klar weg.

3. Das habe ich auch gefragt.

4. Im eigenen Wiki fehlt der Teil mit dem Pseudodateisystem. Ist das überflüssig? Dachte das ist in Bookworm dazu gekommen. Das Wiki ist bis Bullseye. Im Wiki steht auch nichts davon, dass man den Eigentümer auf nobody umstellen muss. Auch überflüssig?

Die Edit sagt zu Punkt 4:
"Auf die darin liegenden Verzeichnissen sind btrfs-Subvolumes gemountet." - Super, das hatte ich überlesen - aber habe ich es auch richtig gemacht? Gerade hinsichtlich der Eigentümer?

[chris71]

Wenn man ein Verzeichnis sowie die Unterverzeichnisse freigibt, kommt es gern zu dem Effekt, dass die Einstellung des übergeordneten Verzeichnisses die Einstellungen für Unterordner überschreibt.

Darum erfolglos nochmal laut Anleitung:

Code: Alles auswählen

root@obelix:~# cat /etc/fstab 
# /etc/fstab: static file system information.
#...
# nfs
/home /exports/home    none bind
/shared/data /exports/data     none bind
/shared/documents /exports/documents    none bind

root@obelix:~# cat /etc/exports 
#...
# laut Anleitung
/exports   192.168.150.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check,crossmnt,fsid=0)
#
# neu
#/exports            192.168.150.0/255.255.255.0(ro,sync,no_root_squash,no_subtree_check,fsid=0)
#/exports/data       192.168.150.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check)
#/exports/documents  192.168.150.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check)
#/exports/home       192.168.150.0/255.255.255.0(rw,sync,no_root_squash,no_subtree_check)

root@falbala:~# cat /etc/fstab 
#...
# nfs
#192.168.150.111:/ /nfs nfs4 soft,intr,rsize=8192,wsize=8192
192.168.150.111:/home /users nfs4 soft,intr,rsize=8192,wsize=8192
192.168.150.111:/data /data nfs4 soft,intr,rsize=8192,wsize=8192
192.168.150.111:/documents /documents nfs4 soft,intr,rsize=8192,wsize=8192

Und ein weiterer Versuch nur mit verändertem Client:

Code: Alles auswählen

root@falbala:~# cat /etc/fstab 
#...
# nfs
192.168.150.111:/ /nfs nfs4 soft
#192.168.150.111:/home /users nfs4 soft,intr,rsize=8192,wsize=8192
#192.168.150.111:/data /data nfs4 soft,intr,rsize=8192,wsize=8192
#192.168.150.111:/documents /documents nfs4 soft,intr,rsize=8192,wsize=8192

Ergebnis:

Code: Alles auswählen

ce@falbala:~$ cd /nfs/
ce@falbala:/nfs$ touch test
touch: 'test' kann nicht berührt werden: Keine Berechtigung
ce@falbala:/nfs$ cd data/
ce@falbala:/nfs/data$ touch test
touch: 'test' kann nicht berührt werden: Keine Berechtigung
ce@falbala:/nfs/data$ cd ../home/
ce@falbala:/nfs/home$ touch test
touch: 'test' kann nicht berührt werden: Keine Berechtigung
ce@falbala:/nfs/home$ cd ce
ce@falbala:/nfs/home/ce$ touch test8
ce@falbala:/nfs/home/ce$ 

Was läuft falsch?

[mludwig]

Dein Nutzer ce hat in /nfs und in /nfs/home keine Schreibrechte, das was du beschreibst ist also das erwartete Ergebnis. Nur root darf dort schreiben.

Code: Alles auswählen

drwxr-xr-x  2 root   root

Bin mir unsicher was du dort stattdessen erwartest?

[chris71]

Dein Nutzer ce hat in /nfs und in /nfs/home keine Schreibrechte, das was du beschreibst ist also das erwartete Ergebnis. Nur root darf dort schreiben.

Code: Alles auswählen

drwxr-xr-x  2 root   root

Bin mir unsicher was du dort stattdessen erwartest?

Da hast Du Recht, das ist eigentlich so gewünscht.

Aber wie stelle ich es jetzt an, dass z.B. innerhalb /nfs/daten jeder Rechner und jeder Benutzer im Netzwerk schreiben darf? Für jeden einen Ordner darin erstellen mit den nötigen Rechten?

Edit:

Aus: https://wiki.debianforum.de/NFSv4-Mini-Howto

/srv/public 192.168.178.0/24(rw,sync,all_squash,no_subtree_check)
Dieses Dateisystem wird im lokalen Netzwerk schreibbar exportiert. Sämtliche Zugriffe werden gesquasht.

Zum Verständnis: In diesem Beispiel könnten alle Benutzer und Rechner lesen und schreiben, die Dateien hätten dann aber Benutzer nobody und Gruppe nogroup?

Wemn ich all_squash durch no_root_squash ersetze, würden die Benutzer (inkl. root) unter ihrer eigenen ID schreiben? Das können sie dann aber nicht, weil die Rechte auf dem Dateisystem fehlen? Lösung? Mit chmod die Rechte von /srv/public auf 777 setzen?

[mludwig]

Ein Verzeichnis für eine Gruppe von Nutzern würde man wohl über die Gruppenrechte steuern.

Also Verzeichnis daten, mit chgrp einer Gruppe zuweisen, und der Gruppe Schreibrecht auf das Verzeichnis geben.

[chris71]

Ein Verzeichnis für eine Gruppe von Nutzern würde man wohl über die Gruppenrechte steuern.

Also Verzeichnis daten, mit chgrp einer Gruppe zuweisen, und der Gruppe Schreibrecht auf das Verzeichnis geben.

Ich habe gerade oben noch etwas editiert und Fragen gestellt.

Der von Dir beschriebene ist denke ich der elegantere Weg. Eine weitere Gruppe einrichten, das freigegebene Verzeichnis der Gruppe zuordnen und alle Benutzer in diese Gruppe stecken.

Wenn sich UID und GID überschneiden, also auf einem Rechner unterschiedliche Nutzer die selbe UID/GID haben - löst das der NFS4 Server auf?

[mludwig]

Auf einem Rechner sollten bzw. müssen sogar die UIDs und die GIDs eindeutig sein (siehe die Dateien /etc/passwd und /etc/group ). Jeder Nutzer seine eigene UID, jede Gruppe seine eigen GID. Ein Nutzer kann in mehreren Gruppen sein.

Im Netz (also bei mehr als einem Rechner) wirds dann komplizierter:
Für NFS4 gibt es ID-Mapping, das heißt der Server wertet statt der UID den String des Nutzernamens aus und mappt den auf die UID in seiner passwd. Der Nutzernamen muss dann überall gleich sein, damit das Mapping klappt. Für dieses Mapping gibt es eigene Parameter um das zu steuern. NFS2/3 wollten gern überall die gleiche UID/GID haben, das kann man bei NFS4 auch haben indem man ID-Mapping halt nicht benutzt.

Bei größeren Netzen kann man sich eine Zentrale Nutzerverwaltung für das Netz aufbauen, wie man es vielleicht von Active Directory für Windows kennt. Das ist dann wieder eine eigene Baustelle ...

[chris71]

Auf einem
Für NFS4 gibt es ID-Mapping, das heißt der Server wertet statt der UID den String des Nutzernamens aus und mappt den auf die UID in seiner passwd. Der Nutzernamen muss dann überall gleich sein, damit das Mapping klappt. Für dieses Mapping gibt es eigene Parameter um das zu steuern.

Wo finde ich diese Parameter fürs Mapping?

Ansonsten vielen herzlichen Dank! Du hast meinen Focus auf das nahe liegende gelenkt - die Benutzerrechte. Ich war irgendwie in dem Gedanken verfangen, daß NFS das mit Mr. Nobody irgendwie regeln kann. Aber jetzt macht das alles, was es soll.

Jetzt muss ich nur noch heraus finden, wie ich das Mount-Unit ohne Terminal aus KDE starten kann. In Dolphin habe ich nichts gefunden und was ich gefunden habe funktioniert nicht.

OT:
DAVFS ist in Dolphin auch unschön. Das habe ich letztlich auch über fstab und secrets mit einem Miniscript auf dem Desktop gelöst. Auch nicht wirklich schön, aber wenigstens auf Knopfdruck.

Zum Thema:

Die Anleitung könnte man eigentlich für den Hausgebrauch sehr kurz machen.

1. Auf dem Server freizugebende Verzeichnisse mit den passenden Rechten erstellen.

• Auf dem Server das zu exportierende Pseudo-Dateisystem mit den entsprechenden Ordnern erstellen und nobody:nogroup zuordnen.

• Auf dem Server alle freizugebenden Verzeichnisse in der fstab (bind) in das Pseudo-Dateisystem mounten.

• Auf dem Server in /etc/exports eine Zeile für / die Freigabe des Pseudo-Dateisystems eintragen.

• Auf dem Client den Einhängepunkt (Ordner) erstellen.

• Auf dem Client die Mont-Unit erstellen. (oder eine Zeile mit dem / des NFS Servers in die fstab schreiben - kann man so machen, aber ist dann halt Kacke)

• Mount-Unit starten und glücklich sein.

Wenn Interesse besteht würde ich das fürs Wiki noch schön ausarbeiten.

Was mir noch unklar ist, welche Verzeichnisse nobody:nogroup definitiv gehören MÜSSEN?

Vielen Dank und Grüße
Chris

[chris71]

Doppelpost

[mludwig]

Wo finde ich diese Parameter fürs Mapping?

Ansonsten vielen herzlichen Dank! Du hast meinen Focus auf das nahe liegende gelenkt - die Benutzerrechte. Ich war irgendwie in dem Gedanken verfangen, daß NFS das mit Mr. Nobody irgendwie regeln kann. Aber jetzt macht das alles, was es soll.

.....
Was mir noch unklar ist, welche Verzeichnisse nobody:nogroup definitiv gehören MÜSSEN?

all_squash mappt alle Zugriffe aller Remote-Nutzer auf nobody/anonymous, so dass dieser Mr. Nobody dann halt die entsprechenden Rechte auf die Verzeichnisse braucht. Dafür muss man sich nicht mit UID/GID Zuordnungen/mappings zwischen Clients und Server rumschlagen. Wenn du all_squash nicht nutzt, wirst du auch diese Zuweisung nicht benötigen, bei no_root_squash können die weiterhin root gehören.

Die Parameter die ich kenne: nfs4_disable_idmapping und nfs4_unique_id für das kernel-modul:

Code: Alles auswählen

in order to disable ID mapping on NFSv4 on both server and client the following command should be executed:

`# echo 'Y' > /sys/module/nfsd/parameters/nfs4_disable_idmapping

Im Zweifelsfall nach diesen Parametern in $Suchmschine suchen.

[chris71]

all_squash mappt alle Zugriffe aller Remote-Nutzer auf nobody/anonymous, so dass dieser Mr. Nobody dann halt die entsprechenden Rechte auf die Verzeichnisse braucht.

Bedeutet für mich:

Code: Alles auswählen

/exports            192.168.150.0/255.255.255.0(ro,sync,all_squash,no_subtree_check,fsid=0)
/exports/data       192.168.150.0/255.255.255.0(rw,sync,all_squash,no_subtree_check)

und /exports/data plus das dahinter liegende /shared/data aus meinem Beispiel gehören nobody:nogroup

müsste zur Konsequenz haben, daß jeder in die Freigabe schreiben kann.

Das hat es aber nicht, daher meine Verwirrung - oder habe ich noch etwas übersehen?

[mludwig]

all_squash mappt alle Zugriffe aller Remote-Nutzer auf nobody/anonymous, so dass dieser Mr. Nobody dann halt die entsprechenden Rechte auf die Verzeichnisse braucht.

Bedeutet für mich:

Code: Alles auswählen

/exports            192.168.150.0/255.255.255.0(ro,sync,all_squash,no_subtree_check,fsid=0)
/exports/data       192.168.150.0/255.255.255.0(rw,sync,all_squash,no_subtree_check)

und /exports/data plus das dahinter liegende /shared/data aus meinem Beispiel gehören nobody:nogroup

müsste zur Konsequenz haben, daß jeder in die Freigabe schreiben kann.

Das hat es aber nicht, daher meine Verwirrung - oder habe ich noch etwas übersehen?

/exports ist ro, also kann man offensichtlich nicht drin schreiben, und /exports/data gehört laut deinen Listings root, also kann Mr. Nobody auch nicht drin schreiben. Dazu kommt die Besonderheit mit verschachtelten Freigaben, die ich weiter oben bereits erwähnt habe ... ro-Freigabe von /exports macht die darunterliegende Freigabe von /exports/data auch ro.

[chris71]

/exports ist ro, also kann man offensichtlich nicht drin schreiben, und /exports/data gehört laut deinen Listings root, also kann Mr. Nobody auch nicht drin schreiben.

Das hatte ich noch mehrfach erfolglos geändert. Zwischen nobody und root, alles probiert.

Dazu kommt die Besonderheit mit verschachtelten Freigaben, die ich weiter oben bereits erwähnt habe ... ro-Freigabe von /exports macht die darunterliegende Freigabe von /exports/data auch ro.

Dann könnte dieser Umstand das Problem gewesen sein. Wobei ich meine überall mal rw reingeschrieben zu haben. Ich habe eigentlich alle Kombinationen mit root/nobody mal systematisch durch probiert.

Im Wiki liest sich das so, als sei das kein Problem.

[mludwig]

Was ich zu dem Thema gefunden hatte ist schon älter, aber es gibt keine Hinweise das dies nicht mehr aktuell ist:

https://nfs.sourceforge.net/nfs-howto/ar01s07.html

It is not possible to export both a directory and its child

folgendes ist von IBM, wobei nicht ersichtlich ist ob sich dies nur auf diese spezifische Implementierung bezieht:
https://www.ibm.com/docs/en/storage-sca ... -nfs-mount

You must not create nested exports ...

Das ist dann aber schon sehr deutlich ... es zeigt auch an wie man es trotzdem tun könnte und was dabei dann zu beachten wäre. Das würde ich mir aber nie antun.

[jph]

4. Im eigenen Wiki fehlt der Teil mit dem Pseudodateisystem. Ist das überflüssig? Dachte das ist in Bookworm dazu gekommen. Das Wiki ist bis Bullseye. Im Wiki steht auch nichts davon, dass man den Eigentümer auf nobody umstellen muss. Auch überflüssig?

Die Edit sagt zu Punkt 4:
"Auf die darin liegenden Verzeichnissen sind btrfs-Subvolumes gemountet." - Super, das hatte ich überlesen - aber habe ich es auch richtig gemacht? Gerade hinsichtlich der Eigentümer?

Der Wiki-Artikel passt auch zu Bookworm. Full Disclosure: Der Artikel ist von mir.

Ich nehme an, dass es sich bei dir um einen Heimserver wie bei mir handelt. Du brauchst dir also gar nicht so viele Gedanken um User und Squashing machen. Ich habe selbst mir schon zu viele Gedanken gemacht und tatsächlich Kerberos aufgesetzt. Also, versuch’s erst einmal einfach zum Laufen zu bringen, du kannst es hinterher immer noch verkomplizieren. (Das ist das schöne an NFS, dass die einfache Variante wirklich saueinfach ist.)

Ob das Subvolumes sind oder Bind-Mounts, ist eher nebensächlich. Ich nutze sowohl als auch.

Auszug aus der fstab:

Code: Alles auswählen

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
UUID=68196998-cfe3-43f2-af6c-26560fc988bb       /srv/music      btrfs   subvol=/@music  0       0
UUID=68196998-cfe3-43f2-af6c-26560fc988bb       /srv/photo      btrfs   subvol=/@photo  0       0
UUID=68196998-cfe3-43f2-af6c-26560fc988bb       /srv/public     btrfs   subvol=/@public 0       0
UUID=68196998-cfe3-43f2-af6c-26560fc988bb       /srv/video      btrfs   subvol=/@video  0       0

/home                                           /srv/home       none    bind    0       0

Zugehöriger Auszug aus der /etc/exports:

Code: Alles auswählen

/srv            192.168.10.0/24(sec=krb5:sys,ro,all_squash,async,no_subtree_check,fsid=0)
/srv/home       192.168.10.0/24(sec=krb5,rw,root_squash,async,no_subtree_check)
/srv/music      192.168.10.0/24(sec=krb5,rw,root_squash,sec=sys,ro,all_squash,async,no_subtree_check)
/srv/photo      192.168.10.0/24(sec=krb5,rw,root_squash,sec=sys,ro,all_squash,async,no_subtree_check)
/srv/public     192.168.10.0/24(sec=krb5:sys,rw,all_squash,async,no_subtree_check)
/srv/video      192.168.10.0/24(sec=krb5,rw,root_squash,sec=sys,ro,all_squash,async,no_subtree_check)

Du siehst hier drei Use Pattern:

• Der Zugriff auf die exportierten Homes ist nur über Kerberos möglich, damit da auch wirklich ein User hintersteckt. Dabei wird nur root gesquasht. Meine Datei soll ja mir gehören.
• Der Zugriff auf die Medien ist auch ohne Kerberos möglich, dann aber nur ro und es wird alles gesquasht. Das brauche ich für den Zugriff seitens Kodi.
• Und dann gibt es noch so eine vorübergehende Datenablage namens „public“, bei der alles gesquasht wird.

Bei NFSv4 müssen übrigens die numerischen ID der User nicht übereinstimmen. Das wird automatisch gemappt, sofern Server und Client in der gleichen Domain hängt.