NFS

topic - Kurzbeschreibung

TMP

Verwendungszweck für unser Netzwerk

1. Zentralisierte Homeverzeichnisse

• Benutzer können sich von jedem Client aus mit ihrem Profil verbinden
  

• Nach Beenden der Sitzung sind die Daten zentral auf dem Server gespeichert
  

2. Ein eigenes APT-Repository

• Zentrales Archiv für eigene Software-Pakete
• Einmal heruntergeladen, stehen diese allen Clients zentral auf dem NFS_Server zur verfügung
  

Was ist NFS

• Ein Netzwerk-Protokoll um Dateien über das lokale Netzwerk auszutauschen.
  

• Es gilt als der Netzwerk-Filesystem-Standard in Unix-Umgebungen.
  

• NFS ist im Prinzip das UNIX-Gegenstück zu SMB aus der Windows-Welt.
  

NFS-Server einrichten

In diesem Beispiel ist die IP Adresse unseres NFS Server ist: 10.10.0.5

1.Paket installieren

#apt install nfs-kernel-server

2.Datei für die Freigabe anlegen und bearbeiten

# vi /etc/exports

/home *(rw,async,no_subtree_check)

/srv/local-apt-reposirtory *(ro,async,all_squash,no_subtree_check)

Danach speichern(Esc, :wq)

3. Erstellen einen Benutzer für jeder Benutzer Ihres Netzwerks auf den NFS Server

#adduser <username>

4.Wechsel das Eigentum und die Zugehörigkeit von die Verzeichnisse der neuen Benutzer in Home Verzeichnis z.B (Benutzer: ammar)

#chown ammar.ammar /home/ammar

4.Nach Bearbeiten der Exports-Datei, muss die Dataei eingelesen werden.

#exportfs -ra

5.Freigaben des Servers anzeigen lassen

#exportfs -v

Freigabe Optionen

Optionen	Beschreibung
rw	Lesen und Schreiben
ro	nur Lesen
async	Leistungsverbesserung durch Nutzung des Schreib-Cache
all_squash	Ordnet alle UserIDs dem Nutzer anonymous zu
no_subtree_check	kein Überprüfung von Unterverzeichnisbäumen

NFSv4-Client einrichten

NFS-Client installieren

# apt install nfs-common

Anpassen der Benutzerdatenbank

Manuelles Mounten des Fileservers

# mount 10.10.0.5:/home/xy /mnt

Mount persistent machen

In fstab datei schreiben:

#vi /etc/fstab 
10.10.0.5:/home /home nfs rw,async,soft 0 0

Alles mounten

# mount -a

Mount testen

# mount | grep home

Neu starten

# systemctl reboot

Paket installieren

nfs-common

Mountpoint für die Freigabe des NFS-Servers

mkdir /srv/local-apt-repository

Freigabe einhängen

mount fileserver:/srv/local-apt-repository/ /srv/local-apt-repository/

Mount der Freigabe in die fstab eintragen

fileserver:/srv/local-apt-repository    /srv/local-apt-repository       nfs     nfsvers=4,rw, 0 0

Clientseitige Optionen

rw	Lese- und Schreibrechte
ro	Nur Leserechte
hard	Ist der Server nicht erreichbar, würde der Dateimanager einfrieren und warten bis er wieder erreichbar ist
soft	Bei Unterbrechungen sofort einen Timeout machen (verhindert ein Einfrieren des Dateimanagers)
intr	Erlaubt einem wartenden Programm, bei Bedarf dennoch zu unterbrechen oder abzubrechen
rsize=8192,wsize=8192	Legt die Blockgröße der zu übertragenen Daten fest
_netdev	weist das System an, solange mit dem mounten zu warten, bis das Netzwerk erreichbar ist

Problembehebung

• Bei Firewall-Freigaben muss NFS-Port 2049 freigegeben werden
  
• Ein beliebter Fehler entsteht durch falsch vergebene Rechte im eingebundenen Dateisystem.
  
• Fehlermeldungen zeigt die Datei /var/log/daemon.log
  

Einführung

Das Network File System - abgekürzt NFS (auch: Network File Service) - ist ein von Sun Microsystems entwickeltes Protokoll, das den Zugriff auf Dateien über ein Netzwerk ermöglicht. Dabei werden die Dateien nicht wie beispielsweise bei FTP übertragen, sondern die Benutzer können auf Dateien, die sich auf einem entfernten Rechner befinden, so zugreifen, als ob sie auf ihrer lokalen Festplatte abgespeichert wären.

Bei diesem UNIX-Netzwerkprotokoll handelt es sich um einen Internet-Standard (RFC 1094, RFC 1813, RFC 3530), der auch als verteiltes Dateisystem (engl. Distributed File System) bezeichnet wird.

Die Entsprechung zu NFS heißt unter Windows- und OS/2-Umgebungen Server Message Block (SMB). Während sich bei SMB der Benutzer authentifiziert, authentifiziert das populärere NFS V3 den Client-Rechner, erst NFS V4 ermöglicht Benutzerauthentifikation. NFS-Dienste sind auch auf Microsoft-Windows-Servern verfügbar, wodurch UNIX-Workstations Zugang zu deren Dateien erhalten können, allerdings wird in gemischten Umgebungen meist SMB mit Samba auf Unixseite verwendet.

NFS arbeitet auf dem Netzwerk-Transportprotokoll TCP/IP. NFS ist ursprünglich ein zustandsloses UDP-Protokoll. Mittlerweile gibt es aber auch NFS über TCP. Die aktuelle Version 4 ist nicht mehr zustandslos, was die Programmierung und die Netzwerksicherung extrem erleichtert. Sie wurde maßgeblich durch die IETF entwickelt, nachdem SUN die Entwicklung abgegeben hatte.

NFS im OSI-Schichtenmodell

Anwendung	NFS
Darstellung	XDR
Sitzung	(Sun-) RPC
Transport	UDP		TCP
Netzwerk	IP
Netzzugang	Ethernet	TokenRing	FDDI	…

Ablauf der Datenübertragung

Im Folgenden ist der prinzipielle Ablauf einer NFS-Kommunikation des zustandslosen NFS beschrieben. Szenario: Ein Nutzer des Client-Rechners möchte ein entferntes Verzeichnis ("/directory") öffnen und eine darin befindliche Datei ("test") anzeigen lassen.

Damit ein Datenaustausch zwischen NFS-Server und Client stattfinden kann, muss der NFS-Server gestartet und beim Portmapper registriert sein.* Client kontaktiert Portmapper und fragt nach dem Port des Mount-Daemons (mountd)

• Portmapper gibt Portnummer für mountd heraus
• Client kontaktiert mountd und fragt nach einem Filehandle für "/directory"
• mountd gibt ein Filehandle 0 zurück
• Client kontaktiert Portmapper und fragt nach dem Port für NFS (nfsd)
• Portmapper gibt Portnummer für nfsd heraus
• Client führt LOOKUP-Prozedur aus mit den Parametern Filehandle 0 und dem Dateinamen ("test")
• nfsd gibt Filehandle 1 für Datei ("test") heraus
• Client führt READ-Prozedur aus mit dem Parameter Filehandle 1
• nfsd gibt Inhalt der Datei ("test") zurück (Daten)

Design der frühen Versionen des Systems

Ein Programm greift auf das Dateisystem über Systemaufrufe zu. Unter UNIX sind die wichtigsten Systemaufrufe:* open, close - Öffnen und Schließen einer Datei

• read, write - Lesen und Schreiben
• create, unlink - Erzeugen und Löschen
• mkdir, rmdir - Erzeugen und Löschen eines Verzeichnisses
• readdir - Lesen von Verzeichniseinträgen

Ein Netzwerkdateisystem muss diese Aufrufe in Netzwerkpakete verpacken und an einen Server senden. Dieser antwortet dann mit der entsprechenden Information oder einem Fehler.

Die Entwickler von Sun Microsystems entschieden sich zunächst für ein Remote Procedure Call-Modell. Das XDR setzt die Parameter in ein maschinenunabhängiges Format um, die Zugriffe werden dann über RPC wie ein normaler Unterprogrammaufruf behandelt.

Die Systemaufrufe werden aber nicht direkt in RPC-Aufrufe umgesetzt, da dann eine über open geöffnete Datei auch auf dem Server geöffnet werden müsste. Bei vielen Clients wären die Server dann schnell überlastet, da die Maschinen Mitte der 1980er Jahre noch relativ wenig Speicher hatten. Die Aufgaben des Servers wurden daher so einfach wie möglich gehalten, der Server merkt sich keine Dateiinformationen zwischen zwei RPC-Aufrufen. Er ist also zustandslos.

Statt open wird ein lookup-Aufruf implementiert. Dieser liefert ein Datei-"Handle", das die Inodenummer und die Gerätenummer des Massenspeichers auf dem Server enthält. Über dieses Handle kann eine Datei auf dem Server eindeutig identifiziert werden. Unter Unix steht über diese beiden Nummern die Dateiinformation effizient ohne Suche eindeutig zur Verfügung.

Die weiteren Aufrufe wie read oder write müssen stets ein Offset übergeben, so dass der Server auch hier ohne Kenntnis früherer Operation die gewünschte Information eindeutig liefern kann.

Weitere Eigenschaften des Protokolls sind* nur kurze Cachezeiten (wenige Sekunden) für Verzeichnisinformationen und Dateiattribute

• kein Datencache
• Verwendung des verbindungslosen User Datagram Protocols UDP
• Lock- und Mount-Operationen über zusätzliche Hilfsprotokolle
• Verwendung von Unix-Dateiattributen (zum Beispiel Benutzer-uid)

Wegen des einfachen Designs läuft NFS in normalen Umgebungen gut:* lokales Netzwerk mit kurzen Antwortzeiten

• Ausführen von Programmen über das lokale Netzwerk
• Normale Benutzeraktivitäten (Editieren, Programme übersetzen)
• Server mit relativ wenig Arbeitsspeicher

Weniger gut ist das Verhalten bei* gemeinsamer Nutzung von Dateien

• Verwendung über das Internet (lange Antwortzeiten, geringe Sicherheit)
• Verwendung von Firewalls (UDP, kein fester Port wegen Portmapper)

Das Protokoll wurde Ende der 1980er Jahre entwickelt. Auch teure Workstations hatten zu dieser Zeit nur wenige Megabytes Arbeitsspeicher, typisch etwa 4 bis 8 MB. Ein NFS-Server kann auf solchen Maschinen aufgrund des Designs trotzdem effizient betrieben werden.

Wegen des zustandslosen Servers kann dieser ohne Datenverlust heruntergefahren und neu gestartet werden. Programme stürzen nicht ab und Benutzer müssen dann einfach warten, bis der Server wieder verfügbar ist.

Plattenlose Workstations

Workstations können über NFS ganz ohne Plattenlaufwerk betrieben werden. Das Betriebssystem und die Betriebsparameter können über Protokolle wie BOOTP und TFTP geladen werden. Ein spezieller Kernel kann dann über NFS bereits auf das Wurzel-Laufwerk unter Unix zugreifen. Spezielle plattenlose Workstations (diskless workstations) wurden von der Firma Sun in den 1990er Jahren angeboten.

Vorteil ist ein verringerter Wartungsaufwand, gemeinsame Nutzung von Plattenplatz sowie einfachere und preiswerte Client-Workstations (Thin-Clients). Bei vielen Clients wird der Server jedoch stark belastet, außerdem sind die Zugriffszeiten über Netzwerk in den meisten Fällen langsamer.

PC-NFS

Sun und andere Firmen boten in den 1990er Jahren auch NFS-Clientsoftware für PCs unter Windows an, das PC-NFS. Der Server musste weiterhin eine Unix-Workstation sein. Bis Windows für Workgroups war der Netzwerkzugriff unter Windows nicht Teil des Betriebssystems. In Unix-Umgebungen wurde der Einsatz von PCs dadurch wesentlich erleichtert.

PC-NFS musste mit den unterschiedlichen Konzepten des DOS/Windows-Systems kämpfen. Die damaligen Windows-Versionen erlaubten nur Dateinamen mit bis zu acht Zeichen sowie eine drei Zeichen lange Erweiterung, die durch einen Punkt getrennt wurde (beispielsweise AUTOEXEC.BAT), während Unix 255 Zeichen lange Pfadnamen erlaubte. Die Dateinamen unterschieden im Gegensatz zu DOS zwischen Groß- und Kleinschreibung. PC-NFS musste also zwischen den Dateinamenkonzepten übersetzen.

Ein Unix-Dateiname file.txt erschien als FILE.TXT unter Windows/DOS, während ein Dateiname Dokumentation.txt etwa in DOKU~123.TXT umgesetzt wurde.

NFS Version 4

Die NFS Version 4 stellt eine Neuimplementierung dar, die neuere Erfordernisse berücksichtigt. Sie ist in RFC 3530 standardisiert.

Die Unix-Lastigkeit der frühen Versionen wird soweit wie möglich verringert. Die UNIX-Benutzer- und Gruppennummern werden durch Zeichenketten, etwa Benutzername@Rechnername, ersetzt. Da manche Dateisysteme keine effiziente Implementierung von eindeutigen Dateihandles ermöglichen, werden flüchtige Handles eingeführt, die nur eine bestimmte Zeit zur Verfügung stehen. Unter Unix kann man Handles sehr einfach aus der Geräte- und Inodenummer konstruieren. Auch Dateisysteme, die nicht zwischen Groß- und Kleinschreibung unterscheiden sowie benutzerdefinierte Dateiattribute werden jetzt unterstützt.

Das Mount- und Lockprotokoll sind jetzt Bestandteil des Protokolls selbst, Hilfsprotokolle werden nicht mehr benötigt. Das Protokoll selbst läuft auf dem festen TCP-Port 2049, UDP wird nicht mehr unterstützt. Zwar liefen auch schon frühere Versionen auf diesem Port, die Hilfsprotokolle wurden vom RPC-Portmapper aber dynamisch zugeteilt. Die Verwendung von Firewalls bei NFS-Verbindungen wird durch diese Maßnahmen stark vereinfacht.

Mehrere Anfragen können gebündelt werden (combined request), sie werden dann vom Server ausgeführt und nur eine Antwort muss zurückgesendet werden. Das Protokoll kann damit effizient auch im Wide-Area-Bereich (WAN) eingesetzt werden, zum Beispiel zwischen verschiedenen Standorten einer Organisation.

Kryptografie ist jetzt Teil der Spezifikation. Zwar war früher schon über Secure-RPC eine Kryptografie möglich. Dies wurde nur selten genutzt, unter anderem, weil Secure-RPC nicht grundsätzlich zur Verfügung stand.

Der lookup-Aufruf wird durch open ersetzt, die Speicherung von Dateiinformationen wird dadurch möglich. Beispielsweise könnte die Schreib-/Leseposition auf dem Server verwaltet werden. Auch die gemeinsame Nutzung von Dateien wird besser unterstützt. Falls viele Clients eine Datei nur lesen, kann diese an alle Clients verliehen (leases) werden. Wenn ein Client eine Datei schreiben möchte, kann diese exklusiv verliehen werden.

Konfiguration in Unix-Systemen

Die NFS-Freigaben werden unter Unix serverseitig meist in der Datei /etc/exports festgelegt. Der Client kann eine Freigabe manuell mounten oder ggf. mit einem Eintrag in der Datei fstab automatisieren.

Vielen aktuellen Linux-Distributionen liegen grafische Hilfswerkzeuge bei, um die Einbindung von NFS-Freigaben ins System zu vereinfachen.

Sicherheit

NFS wurde geschaffen um in Unix-System-Netzen Dateisysteme über Rechnergrenzen hinweg zugänglich zu machen. Zur Zeit der Entwicklung von NFS waren solche Netze fast ausschließlich zentral verwaltet und die Rechner wurden zentral administriert, entsprechend wurde das Sicherheitskonzept gestaltet.

Die Entwickler von NFS bei Sun Microsystems hatten ursprünglich vorgesehen, die Sicherheit als Aufgabe der RPC-Schicht zu implementieren. Hierzu wird RPC durch Secure-RPC ersetzt. Die NFS-Protokolle selbst bleiben davon unberührt. Leider hat Secure-RPC keine weite Verbreitung gefunden, die Verwendung von Secure-RPC ist auch nicht bei allen Implementierungen möglich.

Ein NFS-Server ohne Secure-RPC exportiert Dateisysteme an bestimmte andere Rechner (von root durch IP-Adressen festgelegt), d. h. der root eines Clientrechners kann auf alle Dateien zugreifen, die der Server an den Client exportiert, unabhängig von deren Zugriffsrechten. Die Zugriffsrechte (der Benutzer) werden von NFS an den Client mitübertragen und vom Betriebssystem des jeweiligen Rechners ausgewertet und gegenüber den Benutzern durchgesetzt. Die Konsistenz der Benutzerdatenbank auf den beteiligten Rechnern wird dabei beispielsweise durch NIS erreicht.

Heutzutage sind Rechnernetze oftmals offen und nur bedingt zentral administriert, d. h. ein Angreifer kann relativ einfach entweder einen Rechner, dem der NFS-Server vertraut, übernehmen, indem er ihn beispielsweise mit einem Live-System neu bootet oder einen zusätzlichen Laptop in das Netz hängen und die IP eines gerade nicht laufenden NFS-Clients annehmen. In beiden Fällen kann der Angreifer, da er auf seinem System Rootrechte hat, auf alle an den Client exportierte Dateien, unabhängig von den Zugriffsrechten der Dateien, zugreifen. Somit ist NFS v3 immer nur so sicher, wie das Netz und die beteiligten Rechner.

NFS v4 löst dieses Problem indem beispielsweise mittels Kerberos eine Benutzeridentifizierung erfolgen kann.

Spezifikationen

• RFC 1094 (NFS Version 2 Protocol Specification)
• RFC 1813 (NFS Version 3 Protocol Specification)
• RFC 3530 (NFS Version 4 Protocol Specification)

Server

NFS/Server

Client

Das Network Filesystem ist die gebräuchlichste Methode unter Unix, um Verzeichnisse über Rechnergrenzen hinweg verfügbar zu machen. Einen kurzen Abriss zur Historie und Intention des NFS erhalten Sie im Abschnitt zum NFS-Server .

Voraussetzungen

Kernelunterstützung

Die Unterstützung des NFS-Dateisystems ist Aufgabe des Kernels. Vermutlich integriert der aktuelle Kernel bereits die erforderliche Eigenschaft; ein Blick in die Datei /proc/filesystems schafft Gewissheit:

user@sonne> cat /proc/filesystems
nodev   sockfs
nodev   tmpfs
nodev   pipefs
nodev   proc
        ext2
nodev   devpts
        reiserfs

nodev supermount

Im Beispiel fehlt offensichtlich ein entsprechender Eintrag für das NFS-Dateisystem. Bei aktuellen Kerneln, die heutigen Distributionen beiliegen, muss das noch nichts bedeuten... Eventuell ist die Unterstützung im Kernel nur als Modul kompiliert, und solange das Modul noch nicht geladen wurde, wird der Kernel das Dateisystem auch nicht kennen. Das Modul sollte nun von Hand geladen werden:

# modprobe nfs

Eine Ausschrift der Art modprobe: Can't locate module nfs resultiert entweder aus einer falschen Konfiguration der Modulabhängigkeiten (unwahrscheinlich) oder aber aus einer fehlenden Unterstützung durch den Kernel. Die Generierung eines neuen Kernels wird notwendig sein...

Bei erfolgreichem modprobe-Aufruf erscheint folgende Zeile am Ende der Datei /proc/filesystems:

user@sonne> tail -2 /proc/filesystems
nodev   supermount

nodev nfs

Portmapper

Für die Grundfunktionalität eines NFS-Clients ist die Aktivierung des Portmappers nicht notwendig. Erst wenn Programme mit Dateisperren auf importierten NFS-Verzeichnissen arbeiten, werden auf Clientseite zwei RPC-Dienste (rpc.lockd und rpc.statd) und damit der Portmapper erforderlich.

Das Vorgehen zum Start des Portmappers und der beiden Dienste erfolgt analog zur Beschreibung im NFS-Server-Abschnitt . Beachten Sie auch die dortigen Hinweise zu ggf. erforderlichen Sicherheitseinstellungen in den Dateien /etc/host.allow und /etc/hosts.deny. Ebenfalls in der Abhandlung zum Server finden Sie eine Diskussion zur Arbeitsweise von Network-Lock-Manager (rpc.lockd) und Network-Status-Monitor (rpc.statd).

Bei aktuelleren RedHat- und SuSE-Distributionen finden Sie oft ein Skript /etc/init.d/nfs, über das Sie komfortabel den Client starten und beenden können (genau genommen startet das Skript auch nur die beiden RPC-Dienste und mountet alle in der Datei /etc/fstab erwähnten NFS-Dateisysteme).

Mounten eines NFS-Dateisystems

Welcher Server bietet was?

Für gewöhnlich wird der Administrator eines NFS-Servers die Verzeichnisse nur für konkrete Rechner exportieren und den Verantwortlichen dieser Clients alle notwendigen Informationen zum Zugriff zukommen lassen. Dennoch kann von einem Client leicht verifziert werden, ob ein Rechner als NFS-Server fungiert und welche Verzeichnisse er welchen Rechnern zur Verfügung stellt.

Das Kommando showmount dient zur Abfrage eines Servers. Werden, abgesehen vom Servernamen, keine weiteren Optionen angegeben, so werden die aktuell zum Server verbundenen Clients aufgelistet:

user@venus> showmount sonne.galaxis.de
All mount points on sonne.galaxis.de:
erde.galaxis.de

venus.galaxis.de

Aus Sicht eines NFS-Clients ist die Option -e nützlich, die dem Server Auskunft über die exportierten Verzeichnisse entlockt:

user@venus> showmount -e sonne.galaxis.de
Export list for sonne.galaxis.de:
/home      *.galaxis.de

/usr/share *.galaxis.de

Eine umfassende Beschreibung von showmount finden Sie im Abschnitt zum NFS-Server.

Das Mount-Kommando

Auch zum Mounten von NFS-Verzeichnissen dient das Kommando mount . Es gelten dieselben Voraussetzungen wie zum Einhängen lokaler Dateisysteme: Die notwendigen Rechte müssen gegeben sein (auch auf Serverseite) und der Mountpunkt - also das Zielverzeichnis - muss existieren .

Der Aufruf von mount folgt nun diesem Schema:

mount -t nfs [ -o <Optionen> ] <Servername>:<Verzeichnis auf Server> <lokaler Mountpunkt>

Anstatt des Servernamens ist auch die Angabe einer IP-Adresse zulässig. Neben den allgemein gültigen Optionen für das Mountkommando steuern NFS-spezifische Optionen vor allem das Verhalten des Kommandos im Fehlerfall. Wir widmen uns ihnen im folgenden Abschnitt.

Als konkretes Beispiel soll vom NFS-Server sonne.galaxis.de das dort freigegebene Verzeichnis /home importiert werden. Als Mountpunkt wurde lokal ein Verzeichnis /mnt/home erzeugt. Der Aufruf sieht wie folgt aus:

root@erde> mount -t nfs sonne.galaxis.de:/home/ /home

Etwas Komfort

Da Administratoren - allen voran Unix-ler - bekanntlich recht bequeme Menschen sind und nach Automatisierung streben, gibt es auch hier einen Weg, um den Mount-Aufruf zu vereinfachen. Die kürzere und elegantere Schreibweise wäre ein Eintrag in die Datei /etc/fstab , die statische Informationen über Dateisysteme, ihre Mountpunkte und Optionen enthält.

Eine typische fstab-Datei könnte wie folgt aussehen:

user@erde> cat /etc/fstab
/dev/hda3        /              ext3      defaults 1 2
/dev/hda1        /boot          ext3      defaults 1 2
/dev/cdrom       /media/cdrom   auto      ro,noauto,user,exec 0 0
/dev/fd0         /media/floppy  auto      noauto,user,sync 0 0
devpts           /dev/pts       devpts    defaults 0 0
proc             /proc          proc      defaults 0 0
usbdevfs         /proc/bus/usb  usbdevfs  noauto 0 0
/dev/hda2        swap           swap      pri=42 0 0
# NFS-Einträge
sonne:/home      /home          nfs       bg,soft,intr,retry=5 0 0

sonne:/usr/share /usr/share nfs defaults 0 0

Zur Bedeutung der einzelnen Felder finden Sie Erläuterungen im Abschnitt Dateisysteme, /etc/fstab des Kapitels Systemadministration. Wichtig für unser Beispiel sind die beiden letzten Einträge. Anstelle der Gerätedatei bei lokalen Dateinamen tritt nun das zu importierende Verzeichnis in der Form Server:/Pfad. Als Typ des Dateisystems muss nfs in die dritte Spalte eingetragen werden. Die beiden letzten Spalten sollten bei importierten Verzeichnissen stets 0 sein, da sowohl ein Backup als auch eine Überprüfung des Dateisystems Aufgabe des Servers (der Rechner, auf dem diese Dateisysteme lokal liegen) ist.

Und der Zweck solcher Einträge?

Zum einen genügt nun ein einziger Aufruf, um alle in der Datei benannten NFS-Verzeichnisse gleichzeitig zu importieren:

root@erde> mount -a -t nfs

Zum anderen sinkt selbst bei Import einzelner Einträge der Tippaufwand, da als Argument für das Kommando mount entweder die Angabe der Server-Pfad-Kombination oder auch nur die Angabe des lokalen Mountpunkts genügt. Mit jedem der beiden folgenden Aufrufe könnte das Verzeichnis /home vom Server sonne gemountet werden:

# Angabe des Servers+Pfads
root@erde> mount sonne:/home
# Angabe des lokalen Mountpunkts

root@erde> mount /home

Mount-Optionen

Durch gezielten Einsatz einiger Optionen des mount -Kommandos lassen sich die Zugriffe auf Daten eines NFS-Verzeichnisses mitunter erheblich beschleunigen. Auch kann das Verhalten im Fehlerfall über Argumente gesteuert werden. Selbstverständlich lassen sich solche Angaben auch in der /etc/fstab dauerhaft nieder schreiben.

Die das NFS betreffenden Optionen sind:

rw, ro	Schreib- und Lesezugriff bzw. Nur-Lese-Zugriff. Beachten Sie, dass die Rechte höchstens weiter eingeschränkt werden können, d.h. ein vom Server nur-lesend-exportiertes Verzeichnis kann lokal nicht zum Schreiben freigegeben werden, umgekehrt kann die Schreibberechtigung lokal verboten werden, selbst wenn der Server diese zuließe
fg	Jeder gescheiterte Mountvorgang wird eine Fehlermeldung erzeugen; der Vorgang läuft im Vordergrund (foreground).
bg	Scheitert der Mountvorgang im ersten Versuch, wird er im Hintergrund (background) solange wiederholt, bis er erfolgreich war oder retry erreicht wurde.
retrans=zahl	Anzahl der Wiederholungsversuche, um einen Mount durchzuführen. Der Default-Wert liegt bei 5
hard	Ein Programm wird während des Zugriffs auf ein NFS-Verzeichnis hängen bleiben, falls der Server zusammenbricht. Nach Wiederanlaufen des Servers fährt das Programm mit seiner Arbeit fort. ein hängendes Programm, kann nur unterbrochen werden, wenn die Option intr angegeben wurde.
soft	Der Kernel wird, falls der Server eine bestimmte Zeit lang (retrans*timeo) nicht antwortet, einen Fehler generieren und die auf den Server wartenden Prozesse informieren. Die Zeitdauer zwischen den Versuchen kann mit timeo=Sekunden eingestellt werden.
intr, nointr	Möglichkeit des Abbruchs durch eine Tastenkombination (interrupt) bzw, das Verhindern derselben
remount	Aushängen eines Verzeichnisses, um es sofort wieder (beispielsweise mit neuen Optionen) einzuhängen
suid, nosuid	Möglichkeit zur Benutzung des SUID-Bit auf dem eingehängten Dateisystem
retry=zahl	Anzahl der erfolglosen Mount-Versuche (Voreinstellung ist 10000), bis endgültig abgebrochen wird
wsize=zahl	Setzt die Blockgröße beim Schreiben über NFS auf Bytes byte. Voreinstellung ist 1024, sollte aber auf 8192 gesetzt werden.
rsize=zahl	Setzt die Blockgröße beim Lesen über NFS auf Bytes byte. Voreinstellung ist 1024, sollte aber auf 8192 gesetzt werden.
timeo=zahl	Zeitspanne für Wiederholversuche, angegeben in Zehntelsekunden
proto=protokoll	ab Version 3: Angabe des Protokolls (UDP oder TCP)