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:
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
alle Benutzer im Netzwerk eindeutige UIDs haben und
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 nicht192.168.1.13 (ro,async)
insecuresollte 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 Optioninsecuregesetzt ist.
bei
nohidesollte 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.
Links¶
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