ubuntuusers.de

NFS

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Dieser Artikel ist mit keiner aktuell unterstützten Ubuntu-Version getestet! Bitte teste diesen Artikel für eine Ubuntu-Version, welche aktuell unterstützt wird. Dazu sind die Hinweise zum Testen von Artikeln zu beachten.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

Wiki/Icons/service.png NFS (Network File System) ist ein stabiles und gut funktionierendes Netzwerk-Protokoll von Sun, um Dateien über das lokale Netzwerk auszutauschen. Prinzipiell würde es auch über das Internet funktionieren, was aber aus Sicherheitsgründen nicht zu empfehlen ist. NFS ist im Prinzip das *NIX-Pendant zu SMB aus der Windows-Welt.

Dieser Artikel beschäftigt sich hauptsächlich mit den veralteten NFS-Versionen 2 und 3. Einen separaten Artikel zur aktuellen Version 4 gibt es hier: NFSv4

Einsatzszenario

NFS setzt für einen reibungslosen und sicheren Betrieb voraus, dass

  1. alle Benutzer im Netzwerk eindeutige UIDs haben und

  2. alle Rechner im Netzwerk zentral administriert werden

Die Rechner müssen also so konfiguriert werden, dass jeder Benutzer netzweit seine eigene feste, numerische UID erhält, die auf allen Rechnern dann gleich ist. Bei größeren Netzwerken stellt man das mit einem LDAP- oder NIS-Server sicher. Die Zugriffskontrolle auf die einzelnen Dateien geschieht dann auf dem Server über das reguläre Dateiberechtigungssystem.

Wenn die Benutzer Root-Rechte auf ihren eigenen Rechnern haben bzw. ihre eigenen Notebooks ins Netz einbinden dürfen, können sie das aber umgehen und sich auf ihren Rechnern beliebige UIDs besorgen, die vom NFS-Server auch nicht weiter getestet werden. In diesem Fall muss dann entweder ein zusätzliches Sicherheitsprotokoll wie Kerberos (erst ab NFSv4 möglich) zum Einsatz kommen (nicht-trivial), oder Samba benutzt werden (langsamer).

Installation

Sollte NFS noch nicht vorhanden sein, lässt es sich sehr schnell installieren. Folgende Pakete und deren Abhängigkeiten müssen über die Paketverwaltung [1] installiert werden:

Wenn der Rechner als Server dienen soll, der Dateien bereitstellt:

  • nfs-kernel-server

Befehl zum Installieren der Pakete:

sudo apt-get install nfs-kernel-server 

Oder mit apturl installieren, Link: apt://nfs-kernel-server

Wenn der Rechner nur als Client agieren soll, der auf andere Freigaben zugreift:

  • nfs-common

Befehl zum Installieren der Pakete:

sudo apt-get install nfs-common 

Oder mit apturl installieren, Link: apt://nfs-common

Freigaben

Die Freigaben von Verzeichnissen und Dateien auf dem Server lassen sich durch direkte Bearbeitung der Datei /etc/exports verwalten. Dazu muss diese Datei angelegt und/oder bearbeitet werden [3]. Die Freigabe eines Verzeichnisses lässt sich mit einer Zeile nach folgendem Muster anlegen:

PFAD  RECHNERADRESSE(OPTIONEN)

Leerzeichen sind nur zur Trennung der Felder erlaubt. Wenn man einen Ordner, dessen Name Leerzeichen oder andere problematische Sonderzeichen enthält, freigeben möchte, dann sollte man diese mit doppelten Anführungszeichen (") quotieren. Man kann solche Zeichen auch mit dem umgekehrten Schrägstrich und der Ordnungszahl in dreistelliger oktaler Schreibweise angeben, z.B. Leerzeichen als \040.

Das Feld RECHNERADRESSE(OPTIONEN) zur Beschreibung des Klienten kann mehrfach erscheinen.

Hier sind einige Beispiele:

# freigabe1 wird für zwei Rechner freigegeben
# notebook darf nur lesen (ro)
# desktop darf lesen und schreiben (rw)
/PFAD/ZUR/FREIGABE1      notebook(ro,async) desktop(rw,async)

Alternativ kann die IP-Adresse angegeben werden:

# Freigabe gilt nur für 192.168.1.13, jedoch nur mit Leserechten:
/PFAD/ZUR/FREIGABE2      192.168.1.13(ro,async)
# Freigabe gilt für alle IPs von 192.168.1.1 bis 192.168.1.255, mit Lese-/Schreibrechten:
/PFAD/ZUR/FREIGABE3       192.168.1.0/255.255.255.0(rw,async)
# Freigabe gilt nur für den Rechner mit dem Namen notebook
"/PFAD/ZUR/FREIGABE 4"    notebook(ro,async)

Achtung!

Als Rechneradresse kann neben einer IP-Adresse oder eines IP-Bereiches auch ein Rechnername oder ein DNS-Domainname angegeben werden. Allerdings müssen im Gegensatz zu IP-Adressangaben diese Namen bereits beim Systemboot richtig aufgelöst werden können, was nicht immer der Fall sein muss. Kann der Name beim Booten nicht aufgelöst werden, wird die Freigabe nicht erstellt. Dies kann zu erheblichen Problemen führen.

Die Parameter in den Klammern lauten:

Optionen in der /etc/exports
Option Beschreibung default
rw Lesen und Schreiben -
ro nur Lesen X
sync Synchroner Datentransfer X*
async Asynchroner Datentransfer. In der Regel führt diese Option zu einer Leistungsverbesserung auf Kosten möglicher Datenverluste durch Server-Abstürze bzw. Neustarts. Bis nfs-utils 1.0.0 war die Option 'async' standardmäßig aktiviert. -*
wdelay Diese Option hat nur im Zusammenhang mit 'sync' einen Effekt, siehe 'no_wdelay'. X
no_wdelay Diese Option hat nur im Zusammenhang mit 'sync' einen Effekt. Ein NFS-Server würde normalerweise einen Schreibzugriff auf die Platte etwas verschieben, wenn er davon ausgeht, dass ein anderer, verwandter Schreibzugriff gerade oder bald ankommt. Das ermöglicht es, mehrere Schreibzugriffe in einem Abwasch zu erledigen, was den Durchsatz erhöhen kann. Wenn ein NFS-Server hauptsächlich kleine und nicht zusammengehörige Schreibaufträge erhält, kann dieses Verfahren aber stören und die Leistung verringern. Für diesen Fall ist die Option gedacht, um es auszuschalten. Standardmäßig ist 'wdelay' aktiviert. -
secure Ports oberhalb 1024 nicht verwenden. X
insecure Ports oberhalb 1024 auch verwenden. -
hide "Platzhalter" X
nohide Wenn unterhalb eines exportierten Verzeichnisses (z.B. /home/user auf /dev/hda1) ein weiteres Dateisystem eingebunden wurde (z.B. /dev/hdb1 in /home/user/Musik), so wird dieses Verzeichnis durch einen eigenen exports-Eintrag exportiert. Im Normalfall (Option hide) sieht der Client dieses Unterverzeichnis nicht, wenn er nur das Oberverzeichnis einbindet, weswegen er beide einbinden muss. Durch die Option nohide (im Export des übergeordneten Verzeichnisses) werden die eingebundenen Unterverzeichnisse dem Client nicht mehr als eigene Partitionen präsentiert, sondern als normale, zum Oberverzeichnis gehörende Verzeichnisse. Daher muss man zwar am Server noch alles explizit exportieren, am Client aber nur noch das übergeordnete Verzeichnis einbinden. Die Option nohide funktioniert nur, wenn die Client-Angabe ein festgelegter Rechner ist. Bei Wildcards oder ganzen IP-Bereichen klappt das nicht, dort könnte die Option crossmnt zum gewünschten Erfolg führen. -
crossmnt Diese Option ist so ähnlich wie nohide. Die Option crossmnt ermöglicht es, dass Clients auf exportierte Dateisysteme innerhalb der Freigabe zugreifen können. Wenn ein Kind-Dateisystem "B" auf einem übergeordneten "A" aktiviert ("mount") wird, hat die Einstellung crossmnt auf "A" den gleichen Effekt wie die Einstellung nohide auf B. Wie bei nohide muss auch hier jedes Kind-Dateisystem "B" explizit exportiert werden. -
subtree_check Wenn nur einzelne Verzeichnisse eines Dateisystems freigegeben wurden, wird hiermit überprüft, ob eine vom Client angeforderte Datei in diesen Verzeichnissen des Dateisystems ist. Wurde das gesamte Dateisystem freigegeben, werden die Übertragungsgeschwindigkeiten beim Deaktivieren mittels no_subtree_check erhöht. Darüber hinaus stellt diese Option sicher, dass beim Einbinden eines NFS-Verzeichnisses mittels 'root_squash' alle Dateien, die dem user 'root' gehören, nicht abrufbar sind (selbst wenn die Datei-Rechte dies vorsehen).
Diese Option kann jedoch Probleme verursachen, insbesondere wenn Dateien umbenannt werden, die auf dem Client gerade geöffnet sind.
-*
no_subtree_check Diese Option schaltet die Überprüfung von Unterverzeichnisbäumen ab. Das hat zwar eine leichte Verringerung der Sicherheit zur Folge, kann aber die Verlässlichkeit unter Umständen erhöhen. Wenn ein Unterverzeichnis eines Dateisystems freigegeben (exportiert) wird, aber das ganze Dateisystem nicht, muss der NFS Server jedesmal, wenn er eine Anfrage bekommt, nicht nur überprüfen, ob die gewünschte Datei in dem Dateisystem liegt (einfach), sondern auch, ob sie tatsächlich in dem Unterverzeichnis liegt (schwieriger). Diese Überprüfung wird "subtree_check" genannt. Um diese Überprüfung durchzuführen, muss der Server einige Informationen über die Position der Datei im Dateisystem im Datei-Objekt ("file handle") integrieren, die an den Client weitergegeben wird. Das kann zu Problemen beim Zugriff auf Dateien führen, die umbenannt werden, während sie noch von einem Client geöffnet sind (obwohl es in vielen einfachen Fällen weiter funktioniert). Subtree_checking wird auch benutzt, um sicherzustellen, dass Dateien in Verzeichnissen auf die nur root Zugriff hat, nur zugreifbar sind, wenn das Dateisystem mit der no_root_squash-Option (siehe unten) exportiert wurde, auch wenn die Datei selbst weniger restriktive Zugriffsmodi hat. Als genereller Hinweis mag gelten, dass ein Home-Verzeichnis-Dateibaum, der normalerweise von seiner Wurzel aus exportiert wird und auf dem häufig Dateien umbenannt werden, ohne "subtree_checking" exportiert werden sollte. Ein Dateisystem, das größtenteils nur lesbar ("read only") ist und auf dem zumindest selten Dateien umbenannt werden (z.B. /usr oder /var) und aus dem Unterverzeichnisse exportiert werden, sollte mit "subtree_checking" versehen werden. X*
insecure_locks no_auth_nlm Diese Option (die beiden sind Synonyme) weist den NFS-Server an, bei Dateisperranfragen ("locking", z.B. Nachfragen, die das NLM-Protokoll benutzen) keine Authentifizierung zu verlangen. Normalerweise würde der NFS-Server einen Sperrmechanismus verlangen, um einen Berechtigungsnachweis für Nutzer zu verwalten, die Lesezugriff auf die Datei haben. Mit dieser Option werden keine Zugriffsüberprüfungen gemacht.
Alte NFS-Client-Implementationen haben keine Berechtigungsnachweise zusammen mit Sperrnachfragen verschickt, und es gibt viele NFS-Clients, die auf diesen alten Architekturen basieren. Diese Option sollte also benutzt werden, wenn auffällt, dass nur Dateien gesperrt werden können, die von allen Nutzern lesbar sind. Die voreingestellte Option, Authentifizierung für NLM-Nachfragen zu verlangen, kann explizit mit einem der Synonymen auth_nlm oder secure_locks angegeben werden.
-
Optionen zum UID/GID-Mapping in der /etc/exports
root_squash Weist alle Anfragen der UID/GID 0 auf die UID/GID anonymous zu. Zu beachten ist, dass damit andere sensible bzw. mächtige UserIDs wie etwa "bin" oder "staff" nicht geändert werden. X
no_root_squash 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'. -
all_squash Ordnet alle UserIDs dem Nutzer anonymous zu. Nützlich für NFS-exportierte öffentliche FTP-Verzeichnisse oder News-Spool-Verzeichnisse. -
anonuid anongid Diese Option setzt die anonyme User- und Gruppen-ID explizit auf die angegebenen Werte. Diese Option ist primär für PC/NFS Clients gedacht, wo davon ausgegangen wird, dass alle Nachfragen von einem bestimmten Rechner immer von einer Person kommen. Beispiel: /home/joe pc001(rw,all_squash,anonuid=150,anongid=100)

*: default Einstellung seit nfs-utils 1.0.1

Achtung!

  • Zwischen Freigabe und der Parameterklammer darf kein Leerzeichen stehen: z.B.

    • 192.168.1.13(ro,async) und nicht

    • 192.168.1.13 (ro,async)

  • insecure sollte nur verwendet werden, wenn es unbedingt notwendig ist, da dann auch die unsicheren Ports verwendet werden. Leider verwendet Mac OS X von Apple diese Ports für NFS-Verbindungen. Ein aktueller Apple-Computer kann sich nur dann mit dem NFS-Server verbinden, wenn die Option insecure gesetzt ist.

  • bei nohide sollte man beachten, dass es dadurch passieren kann, dass verschiedene Dateien, welche auf unterschiedlichen Partitionen bzw. Dateisystemen die gleiche Inode-Nummer haben, im aktivierten ("mounted") übergeordneten Verzeichnis die gleiche Inode-Nummer auf demselben (NFS-)Dateisystem haben; manche Treiber verkraften das nicht. Ggf. führt es beim Client zu einer Kernel Panic, wenn gleichzeitig lesend und schreibend auf den Server zugegriffen wird.

Beispiel:

NFS-Freigabe für Verzeichnis /media für eine VirtualBox (auf Servern sollte man das Verzeichnis /media nicht mounten, da sich dort ja auch Wechseldatenträger automatisch einhängen und von anderen auch darauf zugegriffen werden könnte):

/media 192.168.56.0/24(rw,async,insecure,no_subtree_check,crossmnt)

Die Option crossmnt sorgt dafür, dass der Client auch auf die eingehängten Dateisysteme unterhalb des Verzeichnisses /media zugreifen kann, z.B.: /media/Win7, /media/SD-Karte, /media/CD usw.

Damit sich der Rechner notebook als Client auch zu der Freigabe /PFAD/ZUR/FREIGABE3 verbinden kann, muss er mit der IP-Adresse in der Datei /etc/hosts [3] des Servers stehen. Die Zeilen in dieser Datei sind wie folgt aufgebaut, dabei ist die Angabe des FQDN COMPUTERNAME.DOMAIN.tld optional:

IP  COMPUTERNAME COMPUTERNAME.DOMAIN.tld

z.B.:

  192.168.1.12 notebook notebook.meinedomain.local
  192.168.1.13 desktop desktop.meinedomain.local

Die FQDN (beispielsweise notebook.meinedomain.local) müssen nur dann angegeben werden, wenn man diese auch so in der Datei /etc/exports benutzt.

Wenn man in der Datei /etc/exports auf die Verwendung symbolischer Rechnernamen verzichtet und direkt mit IP-Adressen arbeitet, muss man in der Datei /etc/hosts nichts ändern.

Nun muss dem NFS-Server im Terminal [2] nur angewiesen werden, /etc/exports neu einzulesen.

sudo exportfs -ra 

Alternativ kann der gesamte NFS-Server neu gestartet werden:

sudo service nfs-kernel-server restart 

Die eventuell auftauchende Warnung "exportfs: No options for..." kann ignoriert werden.

Die exportierten Freigaben können nun per showmount von einem Client abgefragt werden:

showmount -e NFS_SERVER 

NFS_SERVER steht hierbei natürlich für den Namen oder Adresse des NFS-Servers

⚓︎

Zugriffskontrolle

Der NFS-Server beachtet die Zugriffsbeschränkungen, die durch die Dateien /etc/hosts.allow und /etc/hosts.deny beschrieben werden (siehe auch man hosts_access).

Falls man diese Art der Zugriffskontrolle (zusätzlich zu der aus /etc/exports) verwenden will, sind folgende Einträge vorzunehmen (für den Fall, dass diese Dateien noch nicht existieren, kann man sie einfach selber anlegen):

In der /etc/hosts.deny:

portmap: ALL

Und in der /etc/hosts.allow:

# falls nur die IP 192.168.1.13 Zugriff erhalten soll:
portmap: 192.168.1.13

# falls das gesamte LAN Zugriff erhalten soll:
portmap: 192.168.1.
# oder
portmap: 192.168.1.0/24

Auf dieselbe Art sollte man dann auch den Zugriff auf den mountd und den statd beschränken. Zu beachten ist, dass für diese Dienste nur IP-Adressen in den hosts_access-Dateien funktionieren, keine Domain-Namen.

Hinweis:

Die Einschränkung des statd bietet sich auch auf Client-Rechnern an, insbesondere auf Notebooks, die auch mal in unsicheren Netzen unterwegs sind. Hier muss der Zugriff nur dem/den Server(n) erlaubt werden.

Auf Freigaben zugreifen

Hinweis:

Weil NFS vom GVFS nur eingeschränkt unterstützt wird, können die Dateimanager Nautilus, Thunar und andere nicht direkt auf NFS-Freigaben zugreifen und Netzwerke auch nicht nach NFS-Freigaben durchsuchen. Zum Durchsuchen des Netzwerks eignet sich der Befehl showmount; als Alternative bietet sich auch Autofs an.

Damit der Client auf die Freigaben zugreifen kann, muss er sie einfach einbinden können. Hierzu ein Terminal öffnen [2] und

cd /media
sudo mkdir MEINEFREIGABE
sudo mount ipadresse:/PFAD/ZUR/FREIGABE /media/MEINEFREIGABE 

eingeben. Im Falle einer Notebookfreigabe sieht das etwa so aus:

cd /media
sudo mkdir server
sudo mount 192.168.1.13:/home /media/server 

Man könnte nun ein Shell-Script schreiben, das bei Aufruf eine Verbindung zum Server herstellt. (Achtung: Wenn das Verzeichnis schon erstellt wurde, braucht dieses natürlich nicht mehr erstellt zu werden.) Die zweite Möglichkeit ist, das Ganze mit Root-Rechten in die /etc/fstab-Datei[4] zu schreiben [3].

Beispiel für den Eintrag in die /etc/fstab:

192.168.6.13:/home /media/server nfs rw 0 0

Weitere Optionen in der /etc/fstab
Option Beschreibung
rw Lese- und Schreibrechte
ro Nur Leserechte
hard Bei Unterbrechungen ohne Timeout warten, bis der Server wieder normal erreichbar ist
soft Bei Unterbrechungen sofort einen Timeout machen (verhindert ein Einfrieren des Dateimanagers)
timeo=<SEKUNDEN> In Verbindung mit soft kann festgelegt werden, wann der Timeout erfolgen soll.
bg Bei einem Timeout wird im Hintergrund weiter versucht, das Dateisystem zu aktivieren ("mount"). Ist z.B. bei einem Laptop, das sich im Heimnetz automatisch mit einem NFS-Server verbinden soll, nützlich.
intr Erlaubt einem wartenden Programm, bei Bedarf dennoch zu unterbrechen oder abzubrechen
nolock Deaktiviert das Sperren von Dateien. Wird gelegentlich für die Verbindung zu alten NFS-Servern benötigt
rsize=8192,wsize=8192 Mit diesen beiden Optionen kann man die Blockgröße der übertragenen Daten festlegen. In den meisten Fällen ist es nicht empfehlenswert, diese Optionen zu setzen. Server und Client handeln diese Werte selbst aus und erreichen so ein Maximum an Durchsatz.

Achtung!

Falsche Werte können die Geschwindigkeit von NFS um bis zu 50% reduzieren.

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

Weitere Optionen stehen in der Manpage zu nfs und fstab.

Hinweis:

Portmap öffnet seinen Port standardmäßig an allen Netzwerkschnittstellen, was auf einem Client-Rechner nicht unbedingt erwünscht ist (vor allem bei Laptops, die auch in anderen Netzen unterwegs sind). Man kann das ändern, indem man einfach folgenden Befehl ausführt und die Frage, ob "Portmap" nur an "localhost" gebunden werden soll, mit einem JA beantwortet. Damit ist der Port von anderen Rechnern nicht mehr erreichbar.

sudo dpkg-reconfigure portmap  

Problembehebung

Sollten beim Zugriff auf NFS-Freigaben Probleme auftreten (z.B. Fehlermeldungen der Art "Permission denied", kein Schreibzugriff, scheinbar leere Ordner oder Ähnliches), so hängt dies sehr häufig mit mangelnden bzw. fehlerhaft vergebenen Rechten im eingebundenen (entfernten) Dateisystem zusammen.

Wird als Einhängepunkt versehentlich ein auf dem Client nicht existierendes Verzeichnis angegeben, etwa aufgrund eines Schreibfehlers in /etc/fstab, so erhält man die irreführende Fehlermeldung, es bestünde ein Rechteproblem, etwa

1
2
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting 192.168.178.171:/home/user/schreibfehlre/

Weitere Hinweise hierzu finden sich vor allem unter mount → Rechte sowie Externe Laufwerke einhängen.

Hinweis:

Bei der Freigabe von Dateien auf VFAT-Partitionen (FAT32) über NFS muss mit Problemen gerechnet werden. Als Ausweg empfiehlt sich Samba.

Verzögerung beim Shutdown

Bedingt durch systemd können beim Shutdown erhebliche Verzögerungen auftreten, falls noch NFS- oder cifs-Freigaben gemountet sind. Im Artikel mount.cifs (Abschnitt „Shutdown-und-Reboot“) ist ein Workaround beschrieben, der leicht für NFS-Freigaben angepasst werden kann.

Intern

  • NFSv4 - Der Wikiartikel zu NFSv4

  • Serverdienste – Übersichtsartikel

  • Heimnetzwerk – Einführender Artikel; betrifft vor allem einfache Anwendungen

  • Autofs – Erlaubt auch die Auswahl ("browse") und das Einbinden von NFS-Freigaben

Extern

  • NFS 🇩🇪 – Ausführliche Erklärung (für fortgeschrittene Benutzer) von Selflinux.de

  • NFS 🇬🇧 – Eintrag im Archlinux-Wiki

Diese Revision wurde am 23. Januar 2024 08:38 von kB erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Netzwerk, Server, Freigaben, ungetestet