mount.nfs: rpc.statd wird nicht ausgeführt, ist jedoch für das Remote-Sperren erforderlich

20655
RegedUser00x

Ich versuche, eine Diskette von einem Remote-Computer aus zu mounten, aber ich erhalte folgende Fehlermeldung:

root@sidibalkan:~# mount -t nfs rat:/develop /mnt mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: an incorrect mount option was specified

Ich verwende Debian 7. Auf dem Remote-Server wird Debian 5 ausgeführt. Gibt es eine Idee, warum dies passiert? Wenn ich das zusätzliche Argument hinzufüge, funktioniert es, aber das Problem ist, dass ich es automatisch über autofs mounten möchte. Seltsamerweise kann ich Festplatten von einem anderen Server (auf dem Debian 7 läuft) einbinden.

5

4 Antworten auf die Frage

8
Xavi Montero

Ich hatte das gleiche Problem und war, weil der Client versuchte, lokal eine Verbindung zu seinem eigenen RPC herzustellen.

Ich musste 127.0.0.1meine /etc/hosts.allowauf dem Client-Rechner hinzufügen .

Für meine unten kopierte Sitzung sind dies die betroffenen Daten:

  • guarra ist der Name des Client-Rechners.
  • 192.168.2.53der Server (benannt, fluoraber dieser Name wird hier nicht verwendet).
  • /files ist die exportierte Freigabe vom Server.
  • /files/fluor ist das Ziel, an dem es montiert werden kann.

Eine Shell-Session-Voränderung:

root@guarra:/files# cat /etc/hosts.allow rpcbind : 192.168.2.0/24 root@guarra:/files# mount 192.168.2.53:/files fluor/ mount.nfs: rpc.statd is not running but is required for remote locking. mount.nfs: Either use '-o nolock' to keep locks local, or start statd. mount.nfs: an incorrect mount option was specified root@guarra:/files#

Ich habe die Datei geändert und Folgendes erhalten:

root@guarra:/files# cat /etc/hosts.allow rpcbind : 192.168.2.0/24 127.0.0.1 root@guarra:/files# mount 192.168.2.53:/files fluor/ root@guarra:/files#

Nachdem Sie dem Client die lokale IP-Adresse hinzugefügt haben, könnte er seinen eigenen RPC verwenden. Wie Sie sehen, verschwand die Fehlermeldung und ich konnte die Remote-Freigabe ordnungsgemäß einhängen.

Danke, durch das Hinzufügen von 127.0.0.1 zu hosts.allow für den Dienst rpcbind wurde dieses Problem für Ubuntu 16.04 behoben. Autofs mounts NFS-Freigaben jetzt automatisch. w0utert vor 7 Jahren 1
1
RegedUser00x

Ich habe das nolockArgument in die Datei /etc/auto.rat eingefügt und funktioniert jetzt auch mit autofs.

1
anarcat

Ich hatte auch Probleme mit Servern, auf denen die Loopback-Schnittstelle entfernt wurde. In diesem Fall versucht der Verkehr, zur normalen (sprichwörtlichen eth0) Schnittstelle überzugehen und das Zeitlimit zu überschreiten.

Die Lösung in diesem Fall ist die Wiederherstellung der Loopback-Schnittstelle, die wahrscheinlich in etwa wie folgt aussieht (Debian Wheezy 7.6):

# The loopback network interface auto lo iface lo inet loopback
0
smooker

https://wiki.archlinux.org/index.php/NFS_Fehlerbehebung

Um dies zu beheben, müssen Sie den Wert "NEED_STATD" in /etc/conf.d/nfs-common.conf in YES ändern.

Ich kann diese Datei nicht auf meinem System finden, aber ich habe den Wert von NEED_STATD in /etc/init.d/nfs-common auf yes und no gesetzt, und es hilft nicht. RegedUser00x vor 10 Jahren 0
Dies ist eine schlechte Antwort, da 1) ich vermute, dass dies nur für Arch Linux gilt und 2) es kein Beispiel für den vollständigen Code gibt (z. B. "NEED_STATD = yes" oder "NEED_STATD yes") puk vor 10 Jahren 0

Verwandte Probleme