NFS

Das ursprünglich von Sun Microsystems Ende der 1980er-Jahre entwickelte NFS (Network File System) ermöglicht im Gegensatz zu Protokollen wie FTP den Zugriff auf Dateien über ein Netzwerk so, als ob sie auf der lokalen Festplatte abgespeichert wären. NFS in der Version 3 (NFSv3) authentifiziert den Client-Rechner und setzt wahlweise auf TCP oder UDP, ab Version 4 (NFSv4) ist eine Benutzerauthentifikation und nur noch der Einsatz von TCP über einen Port möglich.

Wegen der Zustandslosigkeit des NFS-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.

NFS überträgt Daten im Klartext, zudem verlässt es sich für die Benutzerauthentifizierung auf den Client. Um NFS abzusichern, kommt Kerberos zum Einsatz.

Ich gehe auf NFSv4 ein, welches die UNIX-Lastigkeit früherer Versionen so weit wie möglich verringert.

Der gleichzeitige Export eines Verzeichnisses per NFS und Samba wird in CentOS 7 nicht unterstützt, da beide Mechanismen unterschiedliche File Locking-Mechanismen verwenden.

Installation

Auf dem NFS-Server:

yum -y install nfs-utils
systemctl enable --now nfs-server

Ports 2049/tcp und 2049/udp öffnen.

Zu exportierende Verzeichnisse werden historisch bedingt in der Datei /etc/exports aufgelistet. Es empfiehlt sich jedoch, eigene *.exports-Dateien unterhalb von /etc/exports.d anzulegen. Die Dateinamen müssen zwingend auf .exports enden.

NFS-Export einrichten

Am Anfang steht immer das Anlegen des zu exportierenden NFS-Verzeichnisses sowie das Setzen des Owners. Für die nachfolgenden Beispiele:

mkdir -p /data/nfs
chown -R nfsnobody:nfsnobody /data/nfs
Export - read-only (der einfachste Export)
/etc/exports.d/ro.exports
/data/nfs  10.80.32.123/32
Export - read-write - nfsnobody
/etc/exports.d/rw.exports
/data/nfs 10.80.32.0/24(rw)
Export - read-write - für root

Wenn Verzeichnisse auf dem Server mit dem root-User angelegt und auf dem Client auch unter root gemountet werden sollen:

/etc/exports.d/rw.exports
/data/nfs 10.80.32.5/32 192.168.26.6/32 (rw,no_root_squash)
Export - einfacher NFS-Share für eine oVirt Storage-Domain
/etc/exports.d/ovirt.exports
/data/nfs 10.80.32.0/24(rw,anonuid=36,anongid=36,all_squash)

plus

chown 36:36 /data/nfs

Nach Konfiguration der Exporte wird der NFS-Server neu geladen:

exportfs -rv

Um Clients für den Zugriff auf die Server-Shares zu identifizieren, werden Hostnamen, IP-Adressen, Netzangaben und reguläre Ausdrücke unterstützt. Ein paar Beispiele:

/data/nfs1  clt1(sync,ro) 10.26.6.99(sync,rw)
/data/nfs2  clt[1-10].linuxfabrik.ch(...)
/data/nfs3  *.linuxfabrik.ch 10.26.6.0/24(...)

NFS und Kerberos

Kerberos sorgt für die Client-Authentifizierung und die Verschlüsselung des Datenstroms. Voraussetzung ist ein funktionierender Kerberos-Server plus Angaben zur Erreichbarkeit und eine binäre Kerberos Keytab-Datei für den NFS-Server. Auf dem Server:

yum -y install nfs-secure-server
wget ‐‐output-document=/etc/krb5.keytab http://.../keytabs/server.keytab
systemctl enable --now nfs-secure-server
/etc/exports.d/rw-kerberos.exports
/data/nfs 10.80.32.0/24(rw,sec=krb5p)

Soll das Verzeichnis Kerberos-geschützt mit SELinux-Labeln exportiert werden, muss das von Hand eingeschaltet werden. Das klappt ab NFS-Server-Version 4.2 und geht so:

/etc/sysconfig/nfs
RPCNFSDARGS="-V 4.2"
systemctl restart nfs-secure-server

NFS-Optionen

Die NFS-Optionen werden in Klammern zu den Hosts und Netzwerken angegeben und bestimmen das Verhalten des Shares gegenüber den Clients. Man beachte das fehlende Leerzeichen zwischen der Angabe des erlaubten Netzes und den Optionen. Verschiedene Netze oder Rechner gibt man nach den Optionen durch ein Leerzeichen getrennt an. Mögliche Optionen sind:

  • all_squash:
    Anfragen der Standard-Benutzer werden auf eine anonyme UserID auf dem Server gemappt. Ein File-Tracking anhand der User-ID ist so nicht mehr möglich.
  • fsid=0:
    oder fsid=root - das übergeordnete Dateisystem.
  • insecure:
    Client-Anfragen dürfen von einem Port über 1024 kommen. Der Standard wäre secure.
  • nohide:
    Wenn unterhalb eines exportierten Verzeichnisses (z.B. /home/user) ein zusätzliches Dateisystem eingebunden wurde (z.B. /dev/sdb3 in /home/user/myfiles), sieht der Client das Unterverzeichnis im Normalfall nicht (hide). Durch nohide werden eingebundene Unterverzeichnisse dem Client präsentiert.
  • no_root_squash:
    Der root-User auf dem Client darf auf dem NFS-Server auch als root auf Dateien und Verzeichnisse zugreifen (no_root_quash = „root nicht anonymisieren“).
  • no_subtree_check:
    Ist zwar die Standard-Einstellung, sollte aber im Echtbetrieb explizit so angegeben werden.
  • ro:
    Read-Only. Standard, falls nicht rw angegeben wird.
  • root_squash:
    Anfragen eines root-Users der Client-Maschine werden auf eine anonyme UserID auf dem Server abgebildet. Diesen Mechanismus nennt man Root-Squashing. Standardeinstellung. Die gegenteilige Einstellung heisst no_root_squash.
  • rw:
    Schreibzugriff.
  • sync:
    Alle Schreibzugriffe müssen tatsächlich geschrieben werden, bevor der Befehl als ausgeführt quittiert wird. Sorgt für erhöhte Schreib-Sicherheit, kostet aber Performance.

Mount als Nicht-root-Benutzer

Das Mounten von Dateisystemen ist dem root-Benutzer vorbehalten. Wie kann sich ein Standard-Benutzer ein Verzeichnis per NFS mounten?

Auf dem NFS-Client als root folgendes einrichten:

echo "192.168.26.5:/backup/user/markus.frei /home/markus.frei/backup nfs4 rw,noauto,user 0 0" >> /etc/fstab
mount --all

Danach darf der Benutzer selber ran:

mkdir /home/markus.frei/backup
mount /home/markus.frei/backup

Troubleshooting

„Stale file handle“ auf dem NFS-Client?

umount -f mountpoint && mount --all (falls der NFS-Mountpoint in der /etc/fstab eingetragen ist)

Verzeichnis lässt sich auf dem Client nicht mounten, obwohl der Pfad 100%ig stimmt?

In dem Fall schauen, ob es bereits bestehende NFS-Mounts zum Server gibt (auch auf andere Verzeichnisse), diese einmal umounten. Danach neu mounten.

Was exportiert der Server?
exportfs -v
„mount.nfs4: Operation not permitted“ bei Mount über stunnel

In den Mount-Optionen wird insecure benötigt.

Built on 2022-06-03