NFS-Mount schlägt fehl, Berechtigung verweigert, kein Exporteintrag

Ich habe ein Problem beim Mounten einer NFS-Freigabe, das ich nicht lösen kann und das mich verrückt macht. Dies ist die Situation:

Drei Maschinen beteiligt:
Host A: Mandrake, IP 192.168.1.4, NFS-Server
Host B: athlon64, IP 192.168.1.64, NFS-Client
Host C: lap-fzs-2, IP 192.168.1.27, NFS-Client

Auf Host A wird ein NFS-Server ausgeführt, der ein Verzeichnis exportiert, das von Host B bereitgestellt wird. Dies funktioniert einwandfrei und funktioniert seit Ewigkeiten. Kein Problem. Jetzt kommt Host C ins Bild. Ubuntu 12.04 LTS, modernes System. Ich habe versucht, dieselbe Freigabe von Host A bereitzustellen, erhalte jedoch den Fehler "Berechtigung verweigert":

root@lap-fzs-2:~# mount -t nfs mandrake:/data /data -onfsvers=2
mount.nfs: access denied by server while mounting mandrake:/data

Die Tatsache, dass es zwischen Host A und B funktioniert, sollte beweisen, dass der NFS-Export per se funktioniert. Hier sind die Informationen, die ich geben kann, die mich denken lassen, dass es funktionieren sollte. Vielleicht sieht jemand, was ich nicht weiß und weiß, warum dies auf dem neuen Host C fehlschlägt.

Serverexporte:

[root@mandrake /root]# cat /etc/exports
/suse 192.168.1.0/16(ro,no_root_squash)
/data 192.168.1.0/24(rw)
#/data3 192.168.2.0/24(rw)
#/data 192.168.2.0/16(rw,all_squash,anonuid=500,anongid=500)
#/data3 192.168.2.0/16(rw,all_squash,anonuid=500,anongid=500)

[root@mandrake /root]# exportfs
/suse           192.168.1.0/16
/data           192.168.1.0/24

Der Portmapper läuft, die Exporte sind bekannt und werden von Host B "athlon64" gemountet.

[root@mandrake /root]# showmount -e
Export list for mandrake:
/data 192.168.1.0/24
/suse 192.168.1.0/16
[root@mandrake /root]# showmount -a
All mount points on mandrake:
atlhon64.acme.local:/data

Wenn der athlon64-Host die NFS-Freigabe bereitstellt, zeigt das Serverprotokoll den Erfolg an:

Feb 11 20:06:46 mandrake mountd[460]: authenticated mount request from atlhon64.acme.local:770 for /data (/data)

Wenn der Host C jedoch versucht, dieselbe Freigabe bereitzustellen, wird im Serverprotokoll Folgendes angezeigt:

Feb 11 20:12:42 mandrake mountd[460]: refused mount request from lap-fzs-2 for /data (/): no export entry

Host C sieht den Server, erreicht den Portmapper und den NFSD, schlägt jedoch bei den Berechtigungen fehl.

root@lap-fzs-2:~# showmount -e 192.168.1.4
Export list for 192.168.1.4:
/data 192.168.1.0/24
/suse 192.168.1.0/16


root@lap-fzs-2:~# mount -t nfs -v mandrake:/data /data -onfsvers=2,proto=udp
mount.nfs: timeout set for Mon Feb 11 21:49:23 2013
mount.nfs: trying text-based options 'nfsvers=2,proto=udp,addr=192.168.1.4'
mount.nfs: prog 100003, trying vers=2, prot=17
mount.nfs: trying 192.168.1.4 prog 100003 vers 2 prot UDP port 2049
mount.nfs: prog 100005, trying vers=1, prot=17
mount.nfs: trying 192.168.1.4 prog 100005 vers 1 prot UDP port 636
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting mandrake:/data

Ich muss NFSv2 auf dem Client verwenden. Die Verwendung von NFSv4 schlägt fehl, da der Server dies nicht unterstützt. Es schlägt fehl, da versucht wird, eine direkte Verbindung über TCP zu 2049 herzustellen, der Port jedoch nicht geöffnet ist. Es passiert kein Fallback. Die Verwendung von NFSv3 führt zu einer Nichtübereinstimmung von RPC-Programm und -Version.

Was vermisse ich?

Update:
Alle drei Computer befinden sich in einem LAN auf demselben Switch. Auf Host C ist keine Firewall aktiv:

root@lap-fzs-2:~# iptables -vnL
Chain INPUT (policy ACCEPT 17 packets, 1853 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 20 packets, 5611 bytes)
 pkts bytes target     prot opt in     out     source               destination

Noch auf Host A:

[root@mandrake /root]# ipchains -L 
Chain input (policy ACCEPT):
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

linux nfs

— Florian
quelle

Firewall auf Host C (oder weniger wahrscheinlich auf Host A)? (Was zeigt / sbin / iptables -vnL?)

— Davidgo

Nein, keine Firewalls, ein LAN-Segment.

— Florian

Versuchen Sie den exportfs -aBefehl auf Host A und dann mountauf Host C. Versuchen Sie es mit dem expliziten Hostnamen oder der vollständigen IP-Adresse in /etc/exports.

— Sägemehl

Wie würde das helfen? Der Server führt exportfs -abeim Booten eine aus und da dies kein neuer Eintrag ist, wird er bereits exportiert. Die Exportdatei hat sich nicht geändert, es ist nur ein neuer Host, der sie bereitstellen sollte und nicht kann.

— Florian

@sawdust Ihre Bearbeitung enthielt den richtigen Hinweis: Wenn Sie die vollständige IP-Adresse in verwenden /etc/exports, funktioniert dies tatsächlich. Ich habe jetzt das / 24-Netz plus die vollständige IP aufgelistet und Host C kann gemountet werden. Ich habe Host B noch nicht ausprobiert. Irgendeine Idee warum das so ist? Ich habe festgestellt, dass Host B (der funktionierende) einen MNT-Aufruf der Version 2 verwendet hat, während Host C auf einen MNT-Aufruf der Version 1 zurückgegriffen hat.

— Florian

11. Februar 20:12:42 mandrake mountd [460]: Mount-Anfrage von lap-fzs-2 für / data (/) abgelehnt: kein Exporteintrag

Da in der Ablehnungsbenachrichtigung des Servers angegeben wird, dass für Host C "kein Exporteintrag" vorhanden ist , sollten Sie möglicherweise eine eindeutige Zeile in der /etc/exportsDatei mit dem expliziten Hostnamen oder der vollständigen IP-Adresse für C versuchen .

Versuchen Sie auch, einen exportfs -aBefehl auf dem Server auszugeben .
Ich habe oft Probleme beim Zugriff auf meinen NFS-Server, auch nach einem Neustart. Die explizite Ausgabe des exportfs -aBefehls ist (für mich) die zuverlässige Lösung.

— Sägespäne
quelle

Das explizite, wiederholte exportfs -ahat für mich nichts geändert. Die Verwendung der vollständigen IP-Adresse für den einen problematischen Host hat mein Problem gelöst. Das erklärt es zwar nicht und ich verstehe es nicht, aber es war die Antwort auf mein Problem und was ich empfehlen kann, es für andere mit demselben Problem zu versuchen.

— Florian

Das Hinzufügen eines Eintrags für die problematische IP-Adresse in / etc / export hat mein Problem ebenfalls behoben. Seltsam.

— PLA

Überprüfen Sie, ob die UID und die GUID für die NFS-Benutzer auf Server und Client identisch sind. Stellen Sie außerdem sicher, dass der Ordner auf dem Server die Berechtigung 777 hat. Dies ist mein / etc / export auf meinem Server, auf den mein Client zugreifen kann.

Erstellen Sie ein NFS-Freigabeverzeichnis: (Erstellen Sie jeden Server mit IP, Speicherplatz getrennt)

mkdir / var / nfs vim / etc / export / var / nfs 10.180.82.250 (rw, sync, root_squash, anonuid = 530, anongid = 530, no_subtree_check)

— Tony-Caffe
quelle

Die UID und die GID sind nicht identisch. Sie müssen es nicht sein, es funktioniert, sobald ich die Freigabe auf dem NFS-Client bereitgestellt habe. Und für den Mount-Vorgang sollten die UIDs des Benutzers irrelevant sein. Ich bezweifle, dass es eine gute Idee ist, den Ordner auf 777 zu setzen, insbesondere wenn sich Benutzer am Server anmelden können. Wieder funktionierte es ohne das, sobald ich es montiert hatte.

— Florian

In meinem Fall ist -o vers = 3 die Antwort:

$ sudo mount -o vers=3 192.168.172.1:/A/DIR /mnt

NFS-Server: Ubuntu Desktop 12.04 32-Bit-VMware-Host
NFS-Client: Ubuntu-Server 12.04 64-Bit-VMware-Gast (Nur-Host-Modus)

— Fumisky Wells
quelle