30NFS und AFP
Das im vorigen Kapitel vorgestellte Server-Message-Block-Protokoll bzw. das darauf basierende Programm Samba hat sich zum großen gemeinsamen Nenner beim Dateiaustausch zwischen allen Betriebssystemen entwickelt. Daneben gibt es aber noch andere Verfahren. Im Mittelpunkt dieses Kapitels stehen das »klassische« Unix-Protokoll NFS (Network File System) sowie das unter OS X bevorzugte AFP (Apple Filing Protocol).
30.1NFS 4
Das Network File System (NFS) ermöglicht es, lokale Verzeichnisse anderen Rechnern im lokalen Netzwerk zur Verfügung zu stellen. Anders als bei SMB (Samba) wird das Netzwerkverzeichnis auf dem Client-Rechner durch mount bzw. durch eine entsprechende Zeile in /etc/fstab direkt in das Dateisystem eingebunden. Sie können ein NFS-Verzeichnis also nicht komfortabel im Dateimanager auswählen und mit ein paar Mausklicks darauf zugreifen. NFS ist vielmehr für eine selten wechselnde Netzwerkkonfiguration gedacht, wo die Client-Rechner ständigen Zugriff auf den NFS-Server benötigen.
Die Basisfunktionen für NFS werden direkt vom Kernel zur Verfügung gestellt, um auf diese Weise eine optimale Geschwindigkeit zu erzielen. Alternativ gibt es auch einen User-Space-NFS-Server, der aber kaum im Einsatz ist und auf den ich in diesem Kapitel nicht eingehe.
Die in den Kernel integrierten NFS-Funktionen unterstützen die NFS-Versionen 3 und 4. NFS 4 gilt mittlerweile als vollständig ausgereift und ist im Regelfall vorzuziehen. Nur in Sonderfällen, etwa wenn Sie es mit sehr alten Client-Rechnern zu tun haben, die NFS 4 nicht unterstützen, sollten Sie den Einsatz von NFS 3 in Betracht ziehen.
Server-Konfiguration
Der Linux-Kernel unterstützt NFS 4 standardmäßig. Gegebenenfalls müssen Sie zur Nutzung von NFS aber noch die Pakete nfs-common und nfs-kernel-server (Debian, Ubuntu) bzw. das Paket nfs-utils (CentOS, Fedora, RHEL, SUSE) installieren: Die darin enthaltenen Programme und Scripts kümmern sich um den automatischen Start der erforderlichen Netzwerkdienste.
Eine entscheidende Voraussetzung für den Betrieb eines NFS-4-Servers besteht darin, dass auch der Dienst rpc.idmapd läuft. Dieses Programm stellt die Zuordnung zwischen NFS-Benutzernamen und UIDs/GIDs her.
Alle Verzeichnisse, die per NFS freigegeben bzw. »exportiert« werden, müssen einem Wurzelverzeichnis untergeordnet werden, das als Pseudo-Dateisystem dient. Am einfachsten ist das anhand eines Beispiels zu verstehen. Nehmen wir an, Sie wollen die bereits vorhandenen Verzeichnisse /data/audio, /data/fotos und /iso-images exportieren. Dazu erzeugen Sie vier neue Verzeichnisse, wobei /nfsexport als Wurzelverzeichnis dient. Der Name dieses Verzeichnisses ist willkürlich. Die Verzeichnisse /nfsexport/audio, /data/fotos und /iso sind leer. Sie dienen nur als Einhängepunkt (mount point).
Nun binden Sie /data/ und /data/fotos als neue nfsexports-Unterverzeichnisse ein. Damit ist der Inhalt von /data/audio nun auch unter /nfsexport/audio sichtbar; analog sehen Sie /data/fotos unter /nfsexport/fotos:
Damit das Einbinden des NFS-Verzeichnisses in Zukunft automatisch erfolgt, fügen Sie in /etc/fstab auf dem Server die folgenden drei Zeilen hinzu:
/etc/exports ist die zentrale Konfigurationsdatei für den NFS-Server. Diese Datei steuert, welcher Rechner auf welche Verzeichnisse wie zugreifen darf. Die Rechner können wahlweise durch IP-Nummern oder durch Namen angegeben werden. Subnetze können in der Präfix-Notation angegeben werden, z.B. 10.0.0.0/24. Auch IPv6-Adressen sind zulässig. Rechnernamen dürfen außerdem das Jokerzeichen * enthalten (z.B. *.sol), IP-Adressen aber nicht!
Achten Sie darauf, dass Sie zwischen den IP-Adressen bzw. Hostnamen und den Optionen kein Leerzeichen eingeben! Wenn Sie ein Verzeichnis ohne Einschränkungen für alle Rechner freigeben möchten, die eine Verbindung zum NFS-Server herstellen können, geben Sie einfach das Zeichen * an.
Die folgende Beispieldatei gibt an, dass alle Clients mit IP-Nummern im Netz 10.0.0.* oder mit dem Namen *.lan auf die Verzeichnisse /nfsexport/audio und /nfsexport/fotos zugreifen dürfen. Außerdem dürfen alle Rechner im Netzwerk ohne Einschränkungen bezüglich IP-Adresse oder Hostname auf /nfsexport/iso zugreifen. In den Verzeichnissen audio und iso sind nur Lesezugriffe erlaubt. Die langen Exportdefinitionen wurden hier durch \ über zwei Zeilen verteilt.
Wenn Sie den NFS-Server in einem IPv6-Netz verwenden möchten, geben Sie in /etc/exports einfach das entsprechende IPv6-Netz an, z.B. 2001:7b8:2ff:8471::/64. Die IPv6-Adressen dürfen nicht in eckige Klammern gesetzt werden.
Die Syntax von /etc/exports geht aus dem obigen Listing hervor. Dem Verzeichnis und den Hostnamen bzw. IP-Adressen folgen in Klammern diverse NFS-Optionen, von denen die wichtigsten im Folgenden kurz erläutert werden.
Einige weitere Optionen beschreibt man exports.
-
ro (read-only) bzw. rw (read-write) geben an, ob nur ein Lese- oder auch ein Schreibzugriff erlaubt ist.
-
sync bzw. async bestimmen den Zeitpunkt, zu dem der NFS-Server die Änderungen von Dateien bestätigt. Standardmäßig gilt sync. Das bewirkt, dass eine Bestätigung erst erfolgt, wenn die Datei tatsächlich gespeichert wurde. Viel effizienter, aber weniger sicher ist async. Der Geschwindigkeitsunterschied zwischen sync und async ist bei Schreibzugriffen dramatisch (bis zu Faktor 10), weswegen async in der Praxis häufig zum Einsatz kommt.
-
no_subtree_check bzw. subtree_check geben an, ob der NFS-Server den Subtree-Test durchführen soll. Dazu kurz einige Hintergrundinformationen: Wenn ein Verzeichnis eines Dateisystems (nicht aber ein gesamtes Dateisystem) per NFS exportiert wird, stellt der NFS-Server durch den Subtree-Test fest, ob sich die Datei innerhalb des exportierten Verzeichnisses befindet. Der NFS-Server gibt dann Informationen über den tatsächlichen Ort der Datei an den Client weiter. Wird die Datei später auf dem Server umbenannt, führt das oft zu Problemen auf dem Client.
Aus diesem Grund ist der Subtree-Test in aktuellen NFS-Server-Versionen standardmäßig deaktiviert. Die Option no_subtree_check sollte aber dennoch angegeben werden, um eine diesbezügliche Warnung des Servers beim Start zu verhindern.
Wenn Sie möchten, können Sie den Subtree-Test durch subtree_check explizit aktivieren. man exports empfiehlt dies vor allem für Verzeichnisse, in denen selten Dateien umbenannt werden und die im Read-Only-Modus exportiert werden.
-
root darf zwar wie jeder andere Benutzer NFS nutzen, hat aber aus Sicherheitsgründen in den importierten Verzeichnissen nur die Rechte des Benutzers nobody (UID=65534 und GID=65534). Wenn Sie root die üblichen Rechte geben möchten, müssen Sie in /etc/exports die Option no_root_squash angeben.
-
Das NFS-4-Wurzelverzeichnis muss durch die Option fsid=0 gekennzeichnet werden. Es darf nur ein Wurzelverzeichnis geben! Es ist mit NFS 4 nicht möglich, Verzeichnisse zu exportieren, die sich außerhalb des Wurzelverzeichnisses befinden.
-
Die crossmnt-Option wird ebenfalls nur beim Wurzelverzeichnis angegeben. Sie bewirkt, dass beim Einbinden von Unterverzeichnissen deren Inhalt bei den Clients auch dann sichtbar ist, wenn das Wurzelverzeichnis auf dem Client nicht eingebunden ist. Statt der crossmnt-Option beim Wurzelverzeichnis können Sie auch die nohide-Option bei allen Unterverzeichnissen angeben – Sie erzielen damit denselben Effekt.
Wenn der NFS-Server bereits läuft, müssen Sie nach jeder Änderung in /etc/exports das Kommando exportfs -a ausführen. Es stellt sicher, dass der NFS-Server die geänderten neuen Einträge berücksichtigt.
Neben den standardisierten Konfigurationsdateien können Sie je nach Distribution zusätzlich individuelle Einstellungen vornehmen:
Debian, Ubuntu: |
/etc/defaults/nfs-common, /etc/defaults/nfs-kernel-server |
SUSE: |
/etc/sysconfig/nfs |
Debian und Ubuntu starten den NFS-Server nach der Installation standardmäßig. Bei Fedora, Red Hat und SUSE müssen Sie wie bei anderen Systemdiensten durch die folgenden Kommandos nachhelfen (siehe auch Abschnitt 14.5, »Systemprozesse (Dämonen)«:
NFS 4 verwendet standardmäßig Benutzer- und Gruppennamen zum ID-Mapping. Eine Datei, die auf dem NFS-Server dem Benutzer hofer gehört, darf auf dem NFS-Client-Rechner ebenfalls vom Benutzer hofer gelesen und verändert werden. Server-Benutzer und -Gruppen, die auf dem Client nicht existieren, werden dort dem Benutzer und der Gruppe nobody zugeordnet.
Grundsätzlich ist das ID-Mapping von NFS 4 zwar wesentlich intelligenter als jenes von NFS 3, wo einzig die UID- und GID-Nummern als Grundlage verwendet werden. Dennoch ist das Mapping auch unter NFS 4 nicht frei von Tücken: Sie müssen unbedingt sicherstellen, dass Benutzer im gesamten Netzwerk auf allen Rechnern exakt dieselben Account-Namen haben!
Für das UID- und GID-Mapping ist der bereits erwähnte Dämon rpc.idmapd verantwortlich. Dessen Konfiguration erfolgt durch /etc/idmapd.conf. Für die in diesem Kapitel beschriebene Minimalkonfiguration von NFS 4 können Sie die Datei so lassen, wie sie von Ihrer Distribution vorgegeben ist.
Bei NFS 4 erfolgt die gesamte Kommunikation über den TCP-Port 2049. Wenn Ihr Server durch eine Firewall abgesichert ist, müssen Sie diesen Port im lokalen Netzwerk freigeben. Unter SUSE erledigen Sie das am besten in YaST. Auf CentOS-, Fedora- und RHEL-Systemen stellen Sie zuerst fest, welche Firewall-Zone der Netzwerkschnittstelle für das LAN zugeordnet ist, und öffnen für diese Zone dann den NFS-Dienst:
Hintergrundwissen und andere Strategien zur Firewall-Konfiguration sind in Kapitel 38, »Firewalls«, zusammengefasst.
In diesem Abschnitt habe ich die Server-Konfiguration ohne ein Authentifikationssystem beschrieben – also den einfachsten Weg, um NFS 4 in Betrieb zu nehmen. In großen Netzwerken mit vielen Benutzern werden Sie NFS 4 zumeist mit LDAP und Kerberos verbinden wollen. Auf diese ziemlich komplexe Konfiguration kann ich hier aus Platzgründen nicht eingehen. Sie finden entsprechende Anleitungen im Internet, beispielsweise hier:
http://wiki.debian.org/nfs4-kerberos-ldap
http://www.danbishop.org/2015/01/30/ubuntu-14-04-ultimate-server-guide
Client-Konfiguration
Damit NFS 4 auf einem Client-Rechner genutzt werden kann, muss je nach Distribution das Paket nfs-common (Debian, Ubuntu), nfs-utils (CentOS, Fedora, RHEL) oder nfs-client (SUSE) installiert sein. Außerdem muss der Dämon rcp.idmapd laufen.
Damit Sie das Netzwerkverzeichnis nutzen können, müssen Sie es mit mount in den Verzeichnisbaum integrieren. Die folgenden Kommandos integrieren den gesamten nfsexport-Verzeichnisbaum an der Stelle /media/nfsdata in das lokale Dateisystem. Dabei müssen Sie jupiter durch den Hostnamen des NFS-Servers ersetzen. Beachten Sie, dass Sie das NFS-Wurzelverzeichnis einfach mit / adressieren müssen, nicht mit /nfsexport!
Alternativ können Sie auch nur ein Teilverzeichnis importieren:
Mit umount wird das NFS-Verzeichnis wieder aus dem lokalen Dateisystem entfernt. Wenn die Netzwerkverbindung gerade unterbrochen ist, sollten Sie umount mit der Option -f ausführen. Sonst müssen Sie sehr lange warten, bis umount ausgeführt wird!
Tipp
Unter openSUSE verwenden Sie zum Einrichten von NFS-Verzeichnissen am besten das YaST-Modul hape Netzwerkdienste • NFS-Client.
Um NFS-Verzeichnisse beim Rechnerstart automatisch in das Dateisystem zu integrieren, ergänzen Sie /etc/fstab um eine Zeile nach dem folgenden Muster. In der vierten Spalte können Sie die NFS-spezifische Option bg verwenden. Sie erreichen damit, dass mount im Hintergrund versucht, das Netzwerkverzeichnis einzubinden, wenn dieses nicht sofort zur Verfügung steht. Das ist vor allem beim Einbinden von Netzwerkverzeichnissen während des Rechnerstarts praktisch.
Wenn es in einem großen Netzwerk viele NFS-Verzeichnisse gibt, ist es selten zweckmäßig, einfach alle per /etc/fstab zu aktivieren. Das kostet Zeit und Ressourcen, auch wenn die meisten Verzeichnisse dann gar nicht verwendet werden. Viel besser ist es, die Verzeichnisse erst bei der ersten Benutzung automatisch in den Verzeichnisbaum einzubinden. Diese Aufgabe übernimmt bei vielen Distributionen das Paket autofs bzw. autofs4.
Fehlersuche
Wenn das mount-Kommando auf dem Client scheitert, sollten Sie zur Fehlersuche die folgenden Punkte abarbeiten:
-
Die Verbindung zwischen Server und Client darf nicht durch eine Firewall blockiert werden. Relevant für NFS 4 ist der TCP-Port 2049.
-
Der Dämon rpc.idmapd muss sowohl auf dem Server als auch auf dem Client laufen. Überzeugen Sie sich davon mit ps ax | grep idmapd.
-
Auf dem Server muss der NFS-Server laufen. Das stellen Sie mit rpcinfo -p fest. Die folgenden Zeilen beweisen, dass der NFS-Server für die NFS-Versionen 2, 3 und 4 läuft:
root# rpcinfo -p | grep nfs program vers proto port service 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100227 3 tcp 2049 nfs_acl 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100227 3 udp 2049 nfs_acl ... -
Überprüfen Sie mit showmount -e, welche Verzeichnisse für NFS freigegeben sind:
user@nfsserver$ showmount -e /nfsexport/iso * /nfsexport/fotos *.lan,10.0.0.0/24 /nfsexport/audio *.lan,10.0.0.0/24 /nfsexport *.lan,10.0.0.0/24Sie können showmount auch auf dem Client-Rechner ausführen, müssen dann aber den Hostnamen des NFS-Servers angeben:
user$client# showmount -e <nfsserver> -
Stellen Sie sicher, dass sich Client und Server im selben Netzwerksegment befinden.