NFS
Siehe auch
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)
/data/nfs 10.80.32.123/32
- Export - read-write - nfsnobody
/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:
/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
/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
/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:
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
:oderfsid=root
- das übergeordnete Dateisystem.insecure:
Client-Anfragen dürfen von einem Port über 1024 kommen. Der Standard wäresecure
.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
). Durchnohide
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 nichtrw
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 heisstno_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
- Was exportiert ein remote Server?
showmount --exports my-nfs-server
- „mount.nfs4: Operation not permitted“ bei Mount über stunnel
In den Mount-Optionen wird
insecure
benötigt.
Built on 2024-11-18