QVINTVS · SCRIBET

NFS ist nicht gleich NFS

Probleme mit dem NFS-Automount können auch ganz einfach an Kleinigkeiten liegen.

Ich habe auf meinem Raspberry Pi ein NFS eingerichtet, auf das ich gern von meinen anderen Rechnern aus zugreifen möchte (was ja auch der Sinn von NFS ist).

% showmount -e rpi
Export list for rpi:
/srv/nfs 192.168.0.0/16

Das Einbinden via manuellem mount funktioniert dabei auch ganz wunderbar:

% sudo mount -t nfs rpi:/srv/nfs /mnt/share
(1155) [23:00:53 quintus@hades] ~
% ls /mnt/share
backup  lost+found  public

Wie man unschwer erkennen kann, liegt das NFS auf der Serverseite in /srv/nfs. Hier die dazugehörige /etc/exports:

# /etc/exports
#
# List of directories exported to NFS clients.  See exports(5).
# Use exportfs -arv to reread.
#
# Example for NFSv2 and NFSv3:
#  /srv/home       hostname1(rw,sync) hostname2(ro,sync)
#
# Example for NFSv4:
#  /srv/nfs4	   hostname1(rw,sync,fsid=0)
#  /srv/nfs4/home   hostname1(rw,sync,nohide)
# Using Kerberos and integrity checking:
#  /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt)
#  /srv/nfs4/home   gss/krb5i(rw,sync,nohide)
#

/srv/nfs          192.168.0.0/16(rw,sync,fsid=0,no_subtree_check)

Nichts Wildes, wie man erkennen kann. Also dachte ich mir: „Prima, jetzt noch automatisch beim Booten einbinden und fertig.“ Denkste. Hier ist mein Eintrag in der /etc/fstab:

rpi:/srv/nfs                              /mnt/share nfs4   rsize=8192,wsize=8192,timeo=14,intr 0 0

Meldungen beim Booten im Systemlog:

Jan 06 22:36:29 hades systemd[1]: Starting Remote File Systems (Pre).
Jan 06 22:36:29 hades systemd[1]: Reached target Remote File Systems (Pre).
Jan 06 22:36:29 hades systemd[1]: Mounting /mnt/share...
Jan 06 22:36:29 hades avahi-daemon[345]: Registering new address record for fe80::22cf:30ff:feaa:3403 on eth0.*.
Jan 06 22:36:30 hades kernel: NFS: Registering the id_resolver key type
Jan 06 22:36:30 hades kernel: Key type id_resolver registered
Jan 06 22:36:30 hades kernel: Key type id_legacy registered
Jan 06 22:36:30 hades mount[400]: mount.nfs4: mounting rpi:/srv/nfs failed, reason given by server:
Jan 06 22:36:30 hades mount[400]: No such file or directory
Jan 06 22:36:30 hades systemd[1]: mnt-share.mount mount process exited, code=exited status=32
Jan 06 22:36:30 hades systemd[1]: Failed to mount /mnt/share.
Jan 06 22:36:30 hades systemd[1]: Dependency failed for Remote File Systems.
Jan 06 22:36:30 hades systemd[1]: Job remote-fs.target/start failed with result 'dependency'.
Jan 06 22:36:30 hades systemd[1]: Unit mnt-share.mount entered failed state

„No such file or directory“? Was? Und das Schlimmste: Im Log des Servers taucht rein gar nichts auf, nichtmal eine abgewiesene Verbindung.

Also nochmal von Hand versucht:

% sudo mount -t nfs rpi:/srv/nfs /mnt/share
(1162) [23:05:53 quintus@hades] ~
% ls /mnt/share
backup  lost+found  public
(1163) [23:05:57 quintus@hades] ~
% 

Was denn, geht doch?! Nach intensiven Herumsuchen im Internet und mehrfachen sicherstellen, dass das Netzwerk zum Zeitpunkt des Einhängens auch wirklich da ist (ich verwende eine statische IP auf eth0 mit netcfg), stand ich vor einem Rätsel. Ich habe mir sogar den Artikel zum veralteten NFSv3 im Archlinux-Wiki durchgelesen, falls mir da irgendwas hereingekommen sein sollte. War es auch, ich hatte unnötigerweise den rpc-statd aktiviert, der für NFSv4 aber gar nicht benötigt wird — abgeschaltet, hilft nicht. Beim Booten gab’s nur immer wieder dieselbe Fehlermeldung.

Also weiter herumprobiert und noch einmal händisch herumgefrickelt:

% sudo mount -t nfs4 rpi:/srv/nfs /mnt/share
mount.nfs4: mounting rpi:/srv/nfs failed, reason given by server:
  No such file or directory

Danach war ich erstmal verblüfft. Warum ging es denn jetzt auf einmal auf der Kommandozeile nicht mehr? Wieder gegoogelt, wieder Systemlogs gelesen, nichts. Nochmal probiert:

(1165) [23:10:02 quintus@hades] ~
% sudo mount -t nfs rpi:/srv/nfs /mnt/share 
(1166) [23:10:54 quintus@hades] ~
% ls /mnt/share
backup  lost+found  public
(1167) [23:10:57 quintus@hades] ~
% 

WTF? Wieso geht’s jetzt wieder? Ohne Reboot in derselben Sitzung?

So. Wer Hirnakrobatik mag und seine Aufnahmefähigkeit testen möchte, dem empfehle ich, in dem bisher geschriebenen Teil den Fehler ausfindig zu machen. Ich hab echt lange gebraucht, und möchte niemandem den Spaß daran verderben, selbst auf den Fehler zu kommen.

Lösung

OK, hier kommt die Auflösung. Wo ist der Unterschied (erstes Kommando funktioniert, zweites nicht):

% sudo mount -t nfs rpi:/srv/nfs /mnt/share
% sudo mount -t nfs4 rpi:/srv/nfs /mnt/share

Da möchte man doch durch die Wand gehen. Wegen eines dämlichen Zeichens funktioniert das alles nicht mehr. Naja, egal. Das Ende vom Lied ist, dass der Typ nfs wohl versucht, mit Legacy-NFSv3-Pfaden zu arbeiten, die immer die volle Wurzel auf dem Server brauchen. nfs4 hingegen arbeitet relativ zur NFS-Wurzel, also dem Eintrag in der /etc/exports, der mit fsid=0 (oder dem gleichwertigen fsid=root) definiert wurde, das ist bei mir:

/srv/nfs          192.168.0.0/16(rw,sync,fsid=0,no_subtree_check)

Demnach muss das mount-Kommando wie folgt heißen:

(1169) [23:17:54 quintus@hades] ~
% sudo mount -t nfs4 rpi:/ /mnt/share 
(1170) [23:18:00 quintus@hades] ~
% ls /mnt/share
backup  lost+found  public

Die böseste Falle an der ganzen Sache ist das showmount-Kommando, dass immer die Legacy-Pfade angibt, die nur und nur mit dem Typ nfs, nicht aber mit nfs4 funktionieren. Naja, mit diesem Wissen um die zwei Dateiwurzeln kann man nun den korrekten Eintrag in der /etc/fstab machen:

rpi:/ 	    				  /mnt/share nfs4   rsize=8192,wsize=8192,timeo=14,intr 0 0

Alternativ kann man natürlich auch den Eintrag mit rpi:/srv/nfs machen und als Typ nfs statt nfs4 angeben, aber ich vermute, dass nfs als Typ vielleicht noch andere Legacy-Effekte mit sich bringt als nur die Pfadbezeichnungen.

Viel Spaß mit NFS
Valete.