Inhalt

TableOfContents()

Übersicht

NFS (Network File System) ist die im UNIX-Bereich übliche Art, Verzeichnisse zu ex- bzw. zu importieren und dadurch auf mehreren Rechnern zu benutzen.

Es wird dabei transparent auf die freigegebenen Verzeichnisse zugegriffen. So kann also am Server das komplette /home oder /usr-Verzeichnis exportiert werden, welches dann vom Client übernommen wird - die Benutzer merken davon nichts (außer bei langsamen Netzen ).

Das Angenehme ist, dass man bestimmte Verzeichnisse nach Wahl nur für bestimmte Rechner oder Domänen freigeben kann.

Wer einen festplattenlosen ThinClient aufziehen will, kann auch das gesamte DateiSystem des Servers per NFS importieren.

Siehe auch das [http://www.tldp.org/HOWTO/NFS-HOWTO/ Linux NFS-HowTo] und die deutsche Übersetzung [http://mysite.verizon.net/res0yizl/jrgenpohl DE-Linux-NFS-HOWTO].

Um Datenverzeichnisse von anderen Rechnern einzubinden, kann auch der AutoMounter verwendet werden - dadurch reduziert sich bei sehr vielen Clients die Zahl der Mounts auf die wirklich gebrauchten.

NFS ist ein relativ unsicheres Protokoll und kann deshalb nur in geschützten Umgebungen (lokales Netz ohne feindliche Rechner) eingesetzt werden. NFS vertraut auf TCP/IP bzw. DNS und darauf, dass die Clientrechner zuverlässige Authentifizierung ihrer Benutzer machen und lässt sich dementsprechend über diese Mechanismen angreifen - zudem ist NFS unverschlüsselt. Die Benutzerkennungen auf Server und Client müssen für die korrekte Funktion übereinstimmen.

HowTo

Vorbereitung Server

Sofern das nich automatisch bei der Installation des NFS Servers geschieht. (apt-get install nfs-kernel-server)

Man installiere portmap - dies ist für NFS unbedingt notwendig, sonst gibt es merkwürdige Fehlermeldungen.

Außerdem braucht man natürlich entweder den Userspace-nfsd oder den Kernel-nfsd (und für letzteren natürlich auch den entsprechenden Support im Kernel).

Dann sorgt man dafür, dass portmap und nfsd automatisch beim Booten gestartet werden (Initskript entsprechend verlinken) und startet diese Dienste auch einmalig manuell per Initskript (erspart nen Reboot).

Bei RedHat müssen z.B. folgende Dienste laufen:

• network (versteht sich eigentlich von selbst)
• portmap
• nfslock
• nfs

Konfiguration Server

Dies ist relativ einfach, man braucht nur eine Datei anzupassen.

Auf dem Server schreibt man folgendes in die /etc/exports:

/home           *.home.lan(rw,sync)

Mit der Option async anstatt sync werden Schreibzugriffe vom Server gepuffert und damit schneller.

Zu beachten ist, dass die Freigaben automatisch vor "Rootzugriffen" geschützt sind. Der Admin root vom Client hat auf den freigegebenen Verzeichnissen also minimale Rechte (wie "nobody"). Um das Ummappen von root zu verhindern, kann die Option no_root_squash hinzu gefügt werden.

Näheres siehe man 5 exports.

Den * als Wildcard kann man nur bei Domainnamen verwenden, nicht bei IP-Adressen (diese kann man mit der Netzmaske angeben)

Damit die Änderung wirksam wird, auf dem Server als root ausführen:

exportfs -a -r

Wichtig: Es dürfen keine Unterverzeichnisse von exportierten Verzeichnisse selbst freigegeben werden:

Bsp:

/raid          tiger.linux.lan(ro)
/raid/doc      tiger.linux.lan(rw)

Hier ist der 2. Eintrag falsch, da /raid/doc ein Unterverzeichnis von /raid ist. Dies führt zu der Fehlersituation, dass der Export funktioniert, beim mounten auf dem Client jedoch die Meldung "permission denied" erscheint.

Überprüfen der Serverfreigabe

Um zu überprüfen, ob die Verzeichnisse auch exportiert werden, könnt Ihr folgenden Befehl auf der lokalen Maschine absetzen:

showmount -e [Nodename]

Vorbereitung Clients

Auf den Clients muss ebenfalls der Portmapper laufen.

Bei RedHat müssen folgende Dienste aktiv sein:

• portmap
• nfslock

Konfiguration Clients

Auf den Clients hängt man an die /etc/fstab folgendes an -

<servername>.<netzname>.<lan>:/home  /home  nfs  rsize=8192,wsize=8192,hard,intr  0 0

Dann benennt man auf dem Client das existierende /home erstmal um, (z.B. mv /home /home.local) oder unmountet das bisherige /home (umount /home) - als root natürlich.

Danach kann ohne reboot des Clients das /home vom Netz gemountet werden:

mount /home

und nun sollte /home den Inhalt von /home auf dem Server anzeigen.

Die angegebenen Optionen, rsize=8192,wsize=8192,hard,intr bedeuten folgendes:

• rsize und wsize sind Tuning-Optionen, die NFS beschleunigen. Man sollte sie nicht auf den Defaultwerten belassen, da dies die NFS-Verbindung bis zu einem Faktor 10 ausbremsen kann. Dies kann dann auch gerne zu weiteren Problemen wegen der Timeouts führen.

• hard,intr sind Kompatibilitätsoptionen, die bei manchen Programmen sonst Probleme machen könnten. hard lässt Programme bei Unterbrechungen ohne Timeout warten bis der Server wieder normal erreichbar ist. intr erlaubt ein wartendes Programm bei Bedarf dennoch zu unterbrechen/killen.

  • Und wie kann man das Dateisystem nun unmounten wenn der Server weg ist, und dadurch alles mögliche blockiert ist?

    • Da empfielt sich umount -l <directory>. Oder auch umount -f <directory> - wobei das gerade bei NFS nicht immer gut funktioniert. Beschreibung zu den Parametern siehe manpage von umount.

• Eine weitere mögliche Option nolock braucht man aber eigentlich nur, wenn kein lockd läuft und das locking sowieso nicht funktioniert. (z.B. bei AutomatisierteInstallation)

Weitere interessante mount-Optionen:

• nodev

• nosuid

Siehe auch man mount.

Der neue Kernel NFS Service ("neu" = ab v2.2)

Wenn man den Kernel-NFS-Daemon benutzen will (z.B. weil man File Locking benötigt), muss man allerdings jeden Rechner, an den die jeweiligen Dateisysteme exportiert werden sollen, explizit in der /etc/exports aufführen - sonst kann es u.U. Probleme bei Wiederverbindung nach Netzwerkunterbrechungen geben (der Tipp ist aus der linux-kernel Mailingliste). Der knfsd ist auch sonst zu empfehlen, er ist nämlich etwas schneller als der normale nfsd. Allerdings hat der knfsd (Stand Kernel 2.2 - ist das auch später noch der Fall?) das Problem, dass er a) noch nicht ganz fertig ist und b) mandatory locks nicht vernünftig implementiert, falls er also nicht funktioniert, benutzt man einfach den alten user-space nfsd - der ist zwar langsamer, aber dafür auch bombenstabil.

Der Standard Red Hat 7.3 Kernel (=2.4.18-3) hat mehrer massive Bugs, die ihn als NFS Client unbrauchbar machen. Lösungsmöglichkeit: Upgrade auf 2.4.18-5 oder aktueller.

Im LinuxKernel 2.4.19 scheint ein Fehler im Kernel NFS Service enthalten zu sein, welcher bei gleichzeitigem Lesen und Schreiben von einem NFS-Verzeichnis zu Fehlern beim Schreiben führt (cp meldet: Input/Output error und bricht ab). Dies scheint im LinuxKernel 2.4.20 behoben zu sein.

Fragen und Antworten

Frage : Was kann/muß ich machen wenn der Server nicht erreichbar ist und Programme blockiert werden ich jetzt aber lieber einen Abbruch bzw. eine Fehlermeldung erzwingen will? Ich kann das NFS nicht unmounten, um es wieder richtig zu mounten. Geht das denn nicht ohne kompletten Neustart? Hätte ich mal besser vorher den mount gelößt.

• Wenn das NFS Filesystem "hard" gemountet ist (default), dann ist das unmounten nicht möglich. Details siehe untenstehend.
• Um zu vermeiden, dass I/O Operationen bei der nichtverfügbarkeit des NFS Servers hängen, muss man beim mounten des Filesystems die option "intr" (mount -o intr) angeben. Dies bewerkstelligt, dass File I/O Operationen unterbrochen werden können. Zusätzlich kann auch die Option "soft" beim mount angegeben werden, damit Filesystemoperationen automatisch abgebrochen werden. Siehe nächster Punkt unten.
• Normalerweise ist es nicht möglich, über NFS gemountete freigaben unzumounten, wenn der NFS Server nicht mehr verfügbar ist, da das mounten per default als "Hard" erfolgt (mount -o hard). Dabei wird immer gewartet bis der NFS Server wieder verfügbar ist. Wird das Filesystem allerdings "Soft" gemountet (mount -o soft) so werden Filesystem Operationen abgebrochen sobald der Server nicht mehr verfügbar ist, das unmounten ist damit möglich.

Frage : Wie kann man am besten die Homeverzeichnisse in Clients einmounten die gleichzeitig auch lokale User beherbergen sollen? falls der Server (Erstrechner) gerade aus ist. (in BSD kann man wohl die lokalen Verzeichnisse unter /home sichtbar lassen, auch wenn ein remote /home "drübergemounted" wird.) Das Problem was ich für umgelegte lokale Homeverzeichnisse sehe ist, dass manche Programme einfach von /home/benutzername ausgehen und nicht z.B /home.local/benutzername. Hat da jemand Erfahrungen?

• InterMezzo sollte AFAIK genau da helfen.

Frage : Da NFS ob der fehlenden Verschlüsselung unsicher ist, wie realisiert man dann alternativ das Im- und Exportieren von Verzeichnissen über's Netz besser? Selbst M$ wirbt inzwischen damit, dass SMB/CIFS verschlüsselt und Linuxfreigaben unverschlüsselt seien .

• Man könnte auf dem Client die unverschlüsselte Freigabe via ["CFS"] Freigeben und das über loopback mounten. Nicht schön, aber sicher.

• Dazu taugen auch alle Formen von sicheren Tunneln. Etwa ein SSH-Tunnel auf den Server oder ein VPN.

OK, man kann ssh und unter KDE mit dem fish:/-Protokoll gaz komfortabel arbeiten, aber somit ist beispielsweise ein transparentes Mounten eines kompletten /home nicht so schön möglich. Ideen?

• Doch das geht schau mal nach [http://shfs.sourceforge.net/ shfsmount] -- ReimarBauer DateTime(2004-03-27T08:17:12Z)

• Alternativ dazu auch mit [http://lufs.sourceforge.net/ lufs] bzw. sshfs von lufs.

Tipps und Tricks

Vor jeder Änderung alle Clients unmounten!

Werden mehrerere Verzeichnisse eines NFS-Servers importiert, so empfiehlt es sich, bei Änderungen alle mounts zu lösen, da sonst beim Export ("exportfs -a") die Fehlermeldung "invalid parameter" erscheint und ein mount dann zur Fehlermeldung "keine Berechtigung" führt. Der "schwierige Zusammenhang" zwischen Fehlerbehebungsort und Fehlermeldung hat mich viel Zeit gekostet.

Alternativen

• Aufgrund von Sicherheitsaspekten ist wohl ["SHFS"] die Lösung: Es verschlüsselt und kann "ganz normal" gemountet werden, wie auch NFS:
  • Je nach Berechtigung durch User
  • In der fstab Weitere Infos befinden sich auf ["SHFS"].
• ["AFS"]
• ["Coda"]

• [http://www.stacken.kth.se/projekt/arla/ arla]

KategorieProtokoll