ubuntuusers.de

Ich meine ja.

Bin selbst schon mehrfach durcheinander gekommen - weil oft die Sachen in einem Artikel stehen und man dann immer den Abschnitt suchen muss (also zu jedem config-Punkt).

Ich brauche jedenfalls "Platz" , um das für NFSv4 auszuarbeiten. Nach dem Lesen des Artikels kennst du dich ja dann aus 😀 und dann darf das wiki-Team die Struktur entscheiden. Ich liefer den Inhalt. 😉

Hallo,

wenn zwischen zwei Version eine Progs stark unterscheiden, dann sind zwei Artikel schon ok. Haben wir damals beim NetworkManager auch so gemacht.

Wenn der Artikel NFSv4 fertig ist bitte dann eine neue Diskussion zum Artikel starten.

Gruß, noisefloor

alles klar.

_netdev Die _netdev-Option weist das System an, solange mit dem Versuch zu warten, einen "Share" zu mounten, bis das Netzwerk erreichbar ist.

Das steht hier innerhalb der /etc/exports und ist da m.E. am falschen Platz.

Das gehört doch - wenn überhaupt - in die Mount-Optionen. Allerdings wird _netdev (zumindest bei Version4) ignoriert und kommt auch in der aktuellen Manpage zu nfs nicht vor. Zeile entfernen?

Hallo,

veraltetes darf entfernt werden.

Gruß, noisefloor

Ist es denn veraltet?

hm. Ich habe nochmal etwas recherchiert: systemd.mount checkt, um was für ein filesystem-type es sich handelt:

http://codingberg.com/linux/systemd_when_to_use_netdev_mount_option

Je nachdem wird es entsprechend behandelt. _netdev ist also nicht mehr nötig bei nfs. Wird vermutlich auch in den Mount-Optionen deshalb nicht mehr angezeigt. (Allerdings scheint es dennoch Probleme zu geben, wie sich hier https://forum.ubuntuusers.de/topic/nfs-verbindung-zum-server-steht-nicht-automati/ im Forum zeigt)

Weitere Details auch hier:

https://www.freedesktop.org/software/systemd/man/systemd.mount.html

und

Under NFSv3 (type nfs) the _netdev option will tell the system to wait to mount until the network is available. With a type of nfs4 this option is ignored, but can be used with mount -O _netdev in scripts later. Currently Ubuntu Server does not come with the scripts needed to auto-mount nfs4 entries in /etc/fstab after the network is up.

→ aus https://help.ubuntu.com/community/NFSv4Howto

Ist aber dennoch eine Option aus der fstab. Ich stelle das mal an die etwas richtigere Stelle.

+++
<rowclass="kopf"-3>Optionen zur Kompabilität
+++
`nfsvers=3` `vers=3`
NFS3 erzwingen. The NFS protocol version number used to contact the server's NFS service.  If the server does not support  the  requested  version,  the  mount request fails.  If this option is not specified, the client negotiates a suitable version with the server, trying version 4 first, version 3 second, and version 2 last.
?

Das habe ich mal entfernt. Kann ich so nicht bestätigen. Ein mount mit -t nfs nimmt m.E. immer Version 3 - wenn man Version 4 will muss man dies explizit angeben.

weitere alte und falsche Hinweise entfernt.

weitere alte und falsche Hinweise entfernt.

+1 👍

Mir ist ggf. etwas aufgefallen. Und zwar zu dem Bereich der "no_root_squash" beschreiben soll.

Wenn man sich erstmal "root_squash" und dessen Erklärung anschaut steht da:

"Weist alle Anfragen der UID/GID 0 auf die UID/GID anonymous zu."

Heißt für mich (und das habe ich auch weitesgehend getestet), dass wenn ich als user root auf den Share zugreife und dort eine Datei anlege, diese Datei UID/GID anonymous zugeordnet wird. Und ich somit nicht mit root-Rechten auf den Share schreiben kann.

Vergleicht man nun "no_root_squash" steht dort:

"Bindet man per NFS-Verzeichnisse ein, die auf dem Server dem Nutzer root gehören, werden diese standardmäßig dem Nutzer nobody zugeordnet"

Geht es dort nicht vielmehr darum, dass wenn ich als "root" auf den Share zugreife und dort auch Dateien anlege, diese dann immer noch im Besitz von "root" sind und somit auch nach dem Anlegen immer noch UID/GIO "0" zugewiesen sind? Dabei ist es doch irrelevant wem die Dateien auf dem Server gehören, oder? Die Berechtigungen der Vorliegenden Dateien werden doch nicht geändert. Es wird der Zugriff des Users vom Client auf dem Server geändert. Je nachdem, welcher UID/GID er zugewiesen wird oder ob "root_squash" oder "no_root_squash" gesetzt ist.

Auch hier nachzulesen: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports

root_squash — Prevents root users connected remotely from having root privileges and assigns them the user ID for the user nfsnobody. This effectively "squashes" the power of the remote root user to the lowest local user, preventing unauthorized alteration of files on the remote server. Alternatively, the no_root_squash option turns off root squashing.

So wie ich den englischen Text übersetze heißt es, dass "root_squash" verhindert, dass der root auch root-Rechte auf dem Share/Server hat. Um das zu umgehen (also dass er auch die root-Rechte hat) wird dann "no_root_squash" verwendet. Die Vorliegenden Dateien sind von den Berechtigungen her immer noch unverändert.

Nachtrag:

Sollte meine Vermutung richtig sein, ändere ich das sehr gern ab. Würde dann aber den genauen Wortlaut gern nochmal mit euch vorher besprechen 😉

Hallo David1977,

no_root_squash

bedeutet, dass man mit root-Rechten am Client in die NFS-Freigabe schreiben kann - und die Dateien am Server auch root gehören. Also das, was auf dem lokalen Dateisystem "normal" ist.

Viele Grüße BillMaier

Hallo BillMaier,

bedeutet, dass man mit root-Rechten am Client in die NFS-Freigabe schreiben kann - und die Dateien am Server auch root gehören. Also das, was auf dem lokalen Dateisystem "normal" ist.

Genau das sage ich ja auch.

Nur steht das im Wiki für no_root_squash anders:

Bindet man per NFS-Verzeichnisse ein, die auf dem Server dem Nutzer root gehören, werden diese standardmäßig dem Nutzer nobody zugeordnet

Das suggeriert, dass, wenn auf dem Server Dateien/Verzeichnisse liegen, die dem Nutzer root gehören, deren Zugehörigkeit auf den Nutzer "nobody" geändert wird. Und das ist so einfach nicht richtig, meiner Meinung nach.

Dateien, die schon auf dem Server liegen (ggf. wird der Share ja erst später erstellt), gehören dem User/ der Gruppe an, die sie angelegt haben.

Dateien, die von anderen remote erstellt werden, gehören dann entweder der UID/GID an, dessen anonuid oder anonguid hinterlegt ist, nobody (root_squash) oder, wenn der zugreifende User root ist, root (no_root_squash).

Der Rest:

Das bedeutet, 'no_root_squash' verhindert eine Zuordnung ("mapping") der vom Nutzer root geschriebenen Dateien und Verzeichnisse auf einen anderen Nutzer. UID und GID 0 werden erhalten.

Ist korrekt formuliert. Nur der Anfang ist irgendwie sehr verwirrend formuliert.

Ein Vorschlag meinerseits (man soll ja nicht nur meckern, sondern vielleicht auch mal eine Möglichkeit zur Verbesserung vorschlagen 😉 ), wäre:

Legt man als Nutzer root per NFS Dateien oder Verzeichnisse an, werden diese standardmäßig dem Nutzer nobody zogeordnet (root_squash). Um dieses Sicherheitsmerkmal von root_squash zu umgehen und die, vom User root geschriebenen Daten, auf dem Server nicht auf einen anderen User als ihn selbst zu mappen (UID/GID 0 bleiben erhalten), verwendet man den Parameter no_root_squash.

Nur mal so als Vorschlag 😉

Ein anderer Vorschlag um den Ursprünglichen Text so wenig wie möglich zu ändern:

Bindet man per NFS Verzeichnisse oder Dateien ein, die auf dem Client dem Nutzer root gehören, werden diese standardmäßig auf dem Server dem Nutzer nobody zugeordnet (das wäre das Verhalten von 'root_squash'), und man kann diese nicht modifizieren. Um dieses Sicherheitsmerkmal zu umgehen, dient der Parameter 'no_root_squash' (weitere Informationen erhält man mittels man 5 exports). Das bedeutet, 'no_root_squash' verhindert eine Zuordnung ("mapping") der vom Nutzer root geschriebenen Dateien und Verzeichnisse auf einen anderen Nutzer. UID und GID 0 werden erhalten.

Hallo, deinen ersten Vorschlag finde ich sehr gut.

Den zweiten finde ich zu verschachtelt.

Danke für die Mithilfe!

Gruß BillMaier