© Peer Frings, Fotolia.com

Der Wunsch liegt nahe, Dateien auf einem Fileserver so einfach zu speichern und zu lesen wie im lokalen Dateisystem. Die Antwort von Unix auf diese Anforderung ist das Network File System (NFS).

Als Festplatten noch teuer waren, realisierten viele IT-Abteilungen Arbeitsplatzrechner ihrer Anwender als Diskless Clients. Die starteten über das Netzwerk und bezogen ihr Dateisystem ebenfalls von dort. Zu diesem Zweck entstand unter Unix das Network File System (NFS). Noch heute ist NFS das Standardprotokoll, um Dateisysteme auf mehreren Unix-Maschinen gemeinsam zu nutzen. In anderen Szenarien stellen Server persönliche Nutzerverzeichnisse den Workstations über das Netzwerk bereit. Windows hingegen verwendet für den gleichen Zweck meist das Protokoll Server Message Block (SMB).

Protokoll-Standard

Mit NFS greifen Benutzer transparent auf Dateien zu, die auf einem entfernten Server liegen. Transparenter Zugriff meint, dass es für den Nutzer und seine Applikationen keinen Unterschied zu lokalen Dateien gibt, daher ist kein expliziter Up- oder Download nötig, wie es bei FTP oder HTTP der Fall wäre. Das entfernte Dateisystem ist lediglich einzubinden – ähnlich einer lokalen Festplatte oder eines DVD-Laufwerks. Danach greift der Benutzer auf das im NFS-Kontext Volume genannte Dateisystem zu, solange der Fileserver im Netz erreichbar ist.

Bereits 1989 spezifizierte Sun Microsystems das Protokoll der nicht mehr gebräuchlichen Version 2 in einem RFC, gab aber in den 1990ern die Entwicklung ab. Fast alle Unix-Derivate unterstützen NFS, selbst Portierungen für Windows und Mac OS gibt es. Dennoch ist NFS primär auf Unix zu Hause. Alle gängigen Implementierungen unterstützen die NFS-Version 3 (NFSv3), die die größte Verbreitung hat [1]. Die Version 4 ist eine Neuentwicklung und unterscheidet sich von ihr deutlich [2]. Die Aussagen dieses Artikels gelten daher für NFSv3, wenn nicht explizit NFSv4 erwähnt ist.

Das System, das lokalen Zugriff auf die Festplatten hat, nennen Systemverwalter den NFS-Server. Er stellt die Speicherkapazität über das Netzwerk einem oder mehreren NFS-Clients zur Verfügung. Linux implementiert NFS-Server auf zwei alternative Arten: als Kernel-NFS-Server und als Userspace-NFS-Server. Der Kernel-NFS-Server gilt als performanter und zuverlässiger und bietet darüber hinaus einige zusätzliche Eigenschaften. Der Userspace-NFS-Server erleichtert das Debugging, ist aber für den produktiven Einsatz nicht zu empfehlen.

Ein Strauß von Servern

Das NFS-Protokoll beruht auf dem Mechanismus der Remote Procedure Calls (RPC) und benötigt eine Reihe von Daemons. Alle Distributionen stellen ein NFS-Serverpaket bereit, das die benötigen Dienste installiert. Auf Seiten des Servers sind dies »portmap« und »rpc.mountd«. NFVv4 benötigt zusätzlich »rpc.idmapd«, der Userspace-Server »nfsd« erfordert den »rpc.lockd«.

Nach dem Installieren der Pakete ist der NFS-Server mit den üblichen Startskripten der Distribution zu starten. Das Kommando

/etc/init.d/nfs-kernel-server start

startet auf einem Debian-System die notwendigen Dienste in der richtigen Reihenfolge.

Wie der Systemadministrator feststellt, ob alles korrekt läuft, zeigt Abbildung 1: Zunächst prüft er mit »rpcinfo -p localhost«, ob der zugrunde liegende RPC-Dienst verfügbar ist. In der Ausgabe sollte für jeden notwendigen Dienst ein Eintrag vorhanden sein.

Der Client muss nur das NFS-Protokoll im Kernel unterstützen. Die meisten Distributionen realisieren dies als Kernelmodul »nfs.ko« in »/lib/modules/Version/kernel/fs/nfs/«. Die Version verrät ein Aufruf von »uname -r«. Abbildung 2 vermittelt eine Übersicht der Architektur.

Abbildung 1: Ob ein NFS-Server betriebsbereit ist, testen Systemverwalter in mehreren Schritten. Mittels »rpcinfo« checken sie, ob RPC aktiv ist, und prüfen dann die einzelnen Dienste, die der Portmapper verwaltet. Wer den Kernel-NFS-Daemon verwendet, benötigt außerdem die passenden Module. Das Kommando »lsmod« gibt darüber Auskunft.

Abbildung 2: Das NFS-Protokoll beruht auf dem Mechanismus der Remote Procedure Calls (RPC) und benötigt eine Reihe von Daemons. NFS blendet die Dateien des Servers transparent im Filesystem des Clients ein. Um auf den meist im Kernel implementierten NFS-Server zuzugreifen, bedient sich NFS des RCP-Mechanismus.

Freigeben und einbinden

Der Systemverwalter gibt Daten frei, bevor Clients sie einbinden. Dazu benennt er ein Verzeichnis und schließt damit den gesamten Subtree mit ein. Er darf Verzeichnisse für einzelne Hosts oder Netzwerke freigeben. Mit dem Befehl

showmount -e NFS-Server

lassen sich sowohl alle Verzeichnisse anzeigen, die ein NFS-Server exportiert, als auch welche Clients dazu berechtigt sind. Um als Client ein per NFS freigegebenes Verzeichnis einzubinden, sind ebenfalls Root-Rechte erforderlich. Hat der Systemverwalter diesen Mounten genannten Vorgang erfolgreich abgeschlossen, dürfen auch normale Benutzer auf die entfernten Daten zugreifen, solange Root dies nicht explizit einschränkt.

Serverkonfiguration

Die freizugebenen Verzeichnisse trägt der Admin auf dem NFS-Server in die Datei »/etc/exports« ein. In der ersten Spalte steht der freizugebende Pfad. Anschließend dürfen Default-Optionen folgen, die ein Minuszeichen einleitet. Der Rest der Zeile besteht aus einem oder mehreren Clients, für die diese Freigabe gilt. Die Clientnamen trennt NFS durch Leerzeichen, nach jedem Namen darf der Admin in runden Klammern eine Liste von Optionen angeben. Außer für einzelne Clients sind auch Freigaben für Subdomains, NIS-Gruppen, ganze Netzwerke oder sogar für alle erlaubt. Dazu trägt der Admin beispielsweise Folgendes in »/etc/exports« ein:

/export/projekte  alpha(rw) centauri(rw)
/pub              (ro)
/export/mp3       192.168.0.0/24(ro)

Damit gibt er das Verzeichnis »/export/projekte« für die Rechner »alpha« und »centauri« zum Lesen und Schreiben »(rw)« frei. Alle Systeme dürfen auf»/pub« zugreifen, allerdings nur lesend. Das Verzeichnis »/export/mp3« exportiert NFS an alle Rechner im Netzwerk 192.168.0.0/24 zum Lesen. Eine Reihe weiterer Optionen zum Exportieren listet Tabelle 1 auf.

Nachdem der Admin die Datei »/etc/exports« angelegt oder verändert hat, aktiviert er mittels »exportfs -a« die Einträge. Der Befehl »showmount -e NFS-Server« überprüft die Wirksamkeit der Einstellungen, hier des NFS-Servers »sol«:

Export list for sol:
/pub             *
/export/mp3      192.168.0.0/24
/export/projekte centauri,alpha

Das Format der Datei »/etc/exports« und ihre Optionen dokumentiert die Manpage »exports(5)«. Das Kommando »exportfs« dient auch dazu, um temporär Verzeichnisse freizugeben. Das Handbuch bietet auch zu diesem Kommando eine Seite mit Einzelheiten.

NFS-Workstations einbinden

Per NFS freigegebene Verzeichnisse bindet der Admin ebenso wie lokale Geräte entweder auf der Kommandozeile mittels »mount« oder dauerhaft durch einen Eintrag in der Datei »/etc/fstab« ein, die der Bootvorgang auswertet.

Das Kommando »mount sol:/pub /mnt/sol« bindet das Verzeichnis »/pub«, des NFS-Servers »sol« auf der lokalen Maschine unter dem Pfad »/mnt/sol« ein. Der lokale Mountpoint muss bereits existieren. Der Befehl »umount /mnt/sol« löst die Verbindung wieder. Mit »showmount -a NFS-Client« findet der Anwender heraus, welche NFS-Volumes aktuell gemountet sind. Auch beim Mounten darf der Systemverwalter eine Reihe von Optionen nach dem Schalter »-o« dem Kommando »mount« mitgeben. Tabelle 2 listet die wichtigsten Angaben auf.

Für immer verbunden

Soll eine Verbindung dauerhaft über den nächsten Reboot gültig sein, erreicht der Eintrag einer Zeile in die Datei »/etc/fstab« den gleichen Effekt:

sol:/pub  /mnt/sol  nfs  defaults,ro  0 0

Beim Systemstart oder manuell mittels »mount -t nfs -a « bindet Linux dann das Verzeichnis automatisch mit ein. Dabei ist gerade beim Reboot Vorsicht geboten, da das Einbinden dieses Verzeichnisses nur funktioniert, wenn der Rechner »sol« auch zum Zeitpunkt des Bootens dieses Clients erreichbar ist. Andernfalls verzögert sich der Bootvorgang auf dem Client erheblich, bis ein Timeout von einigen Minuten erreicht ist.

Noch problematischer ist natürlich, wenn auf dem nicht erreichbaren NFS-Volume Daten oder Programme liegen, die für den weiteren Bootvorgang wichtig sind. Aus diesem Grunde kann eine wohldurchdachte NFS-Struktur durchaus eine (lösbare) Herausforderung darstellen.

Als Netzwerkfilesystem ist NFS zwangsläufig auf eine stabile Netzanbindung angewiesen. Zwar kann es Timeouts durchaus eine gewisse Zeit lang überbrücken, doch stehen bei einem Netzstau schnell auch einige Anwendungen still, die auf Daten warten.

Unix speichert die Eigentümer von Dateien anhand der numerischen User-ID und überträgt diese auch per NFS. Aus diesem Grund müssen Nutzer auf dem NFS-Server und dem Client die gleiche numerische User-ID haben. Umgekehrt ist es die Aufgabe des Admin, darauf zu achten, dass nicht unterschiedliche Anwender die gleiche User-ID auf verschiedenen Systemen erhalten. Sonst könnten sie auf fremde Dateien zugreifen.

Sicherheitsaspekte

Dies macht deutlich, dass NFS wenig Schutz gegenüber Angreifern bietet, die etwa einen Client unter kompletter Kontrolle haben. Besitzt ein Angreifer Root-Rechte auf einem Client, der berechtigt ist, sich zum NFS-Server zu verbinden, hat ein böswilliger Benutzer die Möglichkeit, Unheil zu stiften. Er kann sich nämlich User mit einer beliebigen ID einrichten und damit effektiv auf jede Datei des Servers zugreifen.

Davon gibt es eine, allerdings nur eingeschränkt wirksame Ausnahme: Während alle Nutzer mit den Rechten ihrer numerischen User-ID auf das NFS-Dateisystem zugreifen, werden die Rechte des Nutzers »root« aus Sicherheisgründen eingeschränkt. Seine Zugriffe vom Client aus auf ein NFS-Dateisystem bildet das Protokoll auf den Nutzer »nobody« ab. Diese Sicherheitsmaßnahme führt bei NFS-Neulingen häufig zu Verwirrung. Ist es explizit erwünscht, dass Zugriffe von »root« über NFS nicht auf »nobody« abgebildet werden, dann setzt der exportierende Systemverwalter die Option »no_root_squash« ein.

Nur für Mitglieder

Alle diese Sicherheitsmechanismen basieren damit auf der Annahme, dass nur vertrauenswürdige Rechner im Netzwerk anzutreffen sind und auf ihnen zumindest die Personen mit Root-Rechten verantwortungsvoll damit umgehen. Darüber hinaus ist NFSv3 unverschlüsselt und verwendet lediglich IP-Adressen zur Authentifizierung. Daher sollten Systemverwalter es nur im lokalen Netzwerk einsetzen und darauf achten, dass keine anderen Systeme Zugang zum gleichen Netz (etwa in einem öffentlichen Besprechungsraum) erhalten.

Das neuere NFSv4 erlaubt es, den Datenverkehr zu verschlüsseln, und besitzt eine Authentifizierung per Nutzer [3]. Da es zudem TCP als Transportprotokoll benutzen kann, gilt es oft als die zuverlässigere Variante von NFS. (mg)