• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

nfs mount refused

gehrke

gehrke

Administrator
Teammitglied
Moin *,

ich stelle mich gerade mal wieder doof an, meinem Raspberry Pi NFS beizubringen. Ich habe schon seit geraumer Zeit hausintern ein Netzwerk mit unterschiedlichen VLANs und da gibt es auch einen NFSv4-Server und mehrere Clients, bei denen NFS tagtäglich funktioniert. An diesem Setup habe ich auch nichts geändert, es ist lediglich in einem der bestehenden VLANs ein Pi mit OpenELEC hinzugekommen, der auch scheinbar netzwerk-technisch alles macht, nur keinen NFS-Mount.

Im folgenden wird das Setup beschrieben. Bei Client 1 funktioniert der NFS-Mount, bei Client 2 nicht.
  • Server: 172.16.11.8
  • Client 1: 172.16.11.7
  • Client 2: 172.16.11.20

Server: CentOS 6.2
Code: 
[root@j4 ~]# ifconfig
bond0     Link encap:Ethernet  Hardware Adresse xx:xx:xx:xx:xx:xx  
          inet6 Adresse: xxxx::xxxx:xxxx:xxxx:xxxx/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:7174559 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1673918 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:10473526900 (9.7 GiB)  TX bytes:632464536 (603.1 MiB)

bond0.11  Link encap:Ethernet  Hardware Adresse  xx:xx:xx:xx:xx:xx 
          inet Adresse:172.16.11.8  Bcast:172.16.11.255  Maske:255.255.255.0
          inet6 Adresse: xxxx::xxxx:xxxx:xxxx:xxxx/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:7138156 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1347257 errors:0 dropped:6 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:10368268463 (9.6 GiB)  TX bytes:493870916 (470.9 MiB)

bond0.13  Link encap:Ethernet  Hardware Adresse xx:xx:xx:xx:xx:xx  
          inet Adresse:172.16.13.10  Bcast:172.16.13.255  Maske:255.255.255.0
          inet6 Adresse: xxxx::xxxx:xxxx:xxxx:xxxx/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:19361 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16318 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:2939991 (2.8 MiB)  TX bytes:116796360 (111.3 MiB)

eth0      Link encap:Ethernet  Hardware Adresse xx:xx:xx:xx:xx:xx  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:62071 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1581786 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:33236497 (31.6 MiB)  TX bytes:511797302 (488.0 MiB)
          Interrupt:16 Speicher:fba00000-fba20000 

eth1      Link encap:Ethernet  Hardware Adresse   xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:7112492 errors:0 dropped:0 overruns:0 frame:0
          TX packets:92136 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:10440290667 (9.7 GiB)  TX bytes:120668154 (115.0 MiB)
          Interrupt:18 Speicher:fb900000-fb920000 

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:387 errors:0 dropped:0 overruns:0 frame:0
          TX packets:387 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:37872 (36.9 KiB)  TX bytes:37872 (36.9 KiB)
Code: 
[root@j4 ~]# uname -a
Linux j4.gehrke.local 2.6.32-220.7.1.el6.x86_64 #1 SMP Wed Mar 7 00:52:02 GMT 2012 x86_64 x86_64 x86_64 GNU/Linux

Client 1 (OpenSUSE 12.3 - funktioniert):
Code: 
j3:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr   xx:xx:xx:xx:xx:xx
          inet addr:172.16.11.7  Bcast:172.16.11.255  Mask:255.255.255.0
          inet6 addr: xxxx::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:55134 errors:0 dropped:0 overruns:0 frame:0
          TX packets:61005 errors:0 dropped:0 overruns:0 carrier:5
          collisions:0 txqueuelen:1000 
          RX bytes:23405663 (22.3 Mb)  TX bytes:30650488 (29.2 Mb)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4956 (4.8 Kb)  TX bytes:4956 (4.8 Kb)
Code: 
j3:~ # uname -a
Linux j3.gehrke.local 3.7.10-1.16-desktop #1 SMP PREEMPT Fri May 31 20:21:23 UTC 2013 (97c14ba) x86_64 x86_64 x86_64 GNU/Linux

2. Client (OpenELEC 4.0.4 - funktioniert nicht)
Code: 
OpenELEC:~ # ifconfig
eth0      Link encap:Ethernet  HWaddr   xx:xx:xx:xx:xx:xx
          inet addr:172.16.11.20  Bcast:172.16.11.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:224 errors:0 dropped:0 overruns:0 frame:0
          TX packets:314 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:156095 (152.4 KiB)  TX bytes:44156 (43.1 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
Code: 
OpenELEC:~ # uname -a
Linux OpenELEC 3.14.5 #1 PREEMPT Wed Jun 4 14:03:32 CEST 2014 armv6l GNU/Linux

Hier der erfolgreiche Mount von Client 1:
Code: 
j3:~ # mount -t nfs4 j4-private:/ /mnt
In diesem Fall protokolliert der Server das hier:
Code: 
[root@j4 ~]# tail -f /var/log/messages
Jun 14 16:41:20 j4 rpc.idmapd[1913]: nfs4_uid_to_name: calling nsswitch->uid_to_name
Jun 14 16:41:20 j4 rpc.idmapd[1913]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
Jun 14 16:41:20 j4 rpc.idmapd[1913]: nfs4_uid_to_name: final return value is 0
Jun 14 16:41:20 j4 rpc.idmapd[1913]: Server : (user) id "1000" -> name "paul@gehrke.local"
Jun 14 16:41:20 j4 rpc.idmapd[1913]: nfsdcb: authbuf=172.16.11.0/24 authtype=group
Jun 14 16:41:20 j4 rpc.idmapd[1913]: nfs4_gid_to_name: calling nsswitch->gid_to_name
Jun 14 16:41:20 j4 rpc.idmapd[1913]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
Jun 14 16:41:20 j4 rpc.idmapd[1913]: nfs4_gid_to_name: final return value is 0
Jun 14 16:41:20 j4 rpc.idmapd[1913]: Server : (group) id "1000" -> name "private@gehrke.local"

Hier der erfolglose Mount von Client 2:
Code: 
OpenELEC:~ # mount -t nfs4 j4-private:/ /storage/nfstest/
mount: j4-private:/ failed, reason given by server: Permission denied
mount: mounting j4-private:/ on /storage/nfstest/ failed: Bad file descriptor
Server-Log hierzu:
Code: 
Jun 14 16:43:18 j4 rpc.mountd[2227]: refused mount request from 172.16.11.20 for / (/): not exported

Hier die exports-Konfiguration des Servers:
Code: 
[root@j4 ~]# cat /etc/exports 
/home/paul/nfs  172.16.11.0/24(rw,sync,fsid=0)
/home/paul/nfs  172.16.17.0/24(rw,sync,fsid=0)
/home/paul/nfs  172.16.11.20(rw,sync,fsid=0)
Code: 
[root@j4 ~]# cat /etc/hosts.allow 
portmap:172.16.11.0/24
portmap:172.16.13.11/32
portmap:172.16.11.20 
mountd:172.16.11.0/24
mountd:172.16.13.11/32
mountd:172.16.11.20
rquotad:172.16.11.0/24
rquotad:172.16.13.11/32
rquotad:172.16.11.20
statd:172.16.11.0/24
statd:172.16.13.11/32
statd:172.16.11.20
rsyncd:172.16.11.0/24

Die lokale Firewall auf dem Server habe ich für diese Tests übrigens runtergefahren. Da die beteiligten Systeme alle im selben Netz liegen, sollte die außen liegende Firewall (welche auch die VLANs aufspannt) nicht involviert sein. Ich kann auch überall alles pingen.

Stehe auf dem Schlauch. Wer kann mich erleuchten?!?
TNX

cu, gehrke

Edit: Auch selinux scheidet als mögliche Fehlerquelle aus - temporär abgeschaltet.
 
OP
gehrke

gehrke

Administrator
Teammitglied
/dev/null schrieb:
die UID von Paul ist aber auf allen Geräten gleich?
Zum Vergrößern anklicken....
Auf den beiden funktionierenden Systemen schon, nicht aber auf dem OpenELEC@pi. Wenn ich das richtig verstanden habe, arbeitet dort scheinbar immer alles als root, jedenfalls das 'xbmc' out-of-the-box:
Code: 
OpenELEC:~ # ps aux | grep 'xbmc'
  312 root     323:47 /usr/lib/xbmc/xbmc.bin --standalone -fs --lircdev /run/lirc/lircd
 
S

spoensche

Moderator
Teammitglied
Code: 
    Jun 14 16:43:18 j4 rpc.mountd[2227]: refused mount request from 172.16.11.20 for / (/): not exported
Du versuchst / (also root) per NFS zu mounten, was in deiner /etc/exports nicht eingetragen ist. Daher kann es nicht funktionieren.
 
OP
gehrke

gehrke

Administrator
Teammitglied
spoensche schrieb:
Code: 
    Jun 14 16:43:18 j4 rpc.mountd[2227]: refused mount request from 172.16.11.20 for / (/): not exported
Du versuchst / (also root) per NFS zu mounten, was in deiner /etc/exports nicht eingetragen ist. Daher kann es nicht funktionieren.
Zum Vergrößern anklicken....
Ich mache genau den selben mount-Aufruf, welcher auf Client 1 wunderbar funktioniert. Dort wird alles eingebunden, was auf dem Server unter dem Pfad /home/paul/nfs liegt.

Ich denke, das '/' bezieht sich hier nicht auf das Root-Verzeichnis des Servers sondern auf die Wurzel des Exports.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Geier0815 schrieb:
Fehlt in der exports bei client2 die subnetmask oder hast Du nur falsch abgeschrieben?
Zum Vergrößern anklicken....
Du meinst das hier?:
Code: 
[root@j4 ~]# cat /etc/exports
/home/paul/nfs  172.16.11.0/24(rw,sync,fsid=0)
[...]
/home/paul/nfs  172.16.11.20(rw,sync,fsid=0)
Eigentlich sollte die erste Zeile schon das komplette Subnetz abdecken, also auch 172.16.11.20. Aber das funktionierte leider auch nicht. Ich habe es bei meinen Tests daher explizit genau für Client2 zusätzlich adressiert, dann aber ohne Netzwerk-Maske. Ich kann das heute Abend auch gern noch mal mit einem angehängten '/32' probieren.
TNX
 
Geier0815

Geier0815

Guru
Wenn dann müßte es /24 sein. Aber rein testhalber würde ich mal mit dem * arbeiten (also von allen clients Zugriff zulassen) und gucken ob der client2 dann zugreifen kann. Danach weißt Du dann ob es an der Freigabe liegt oder am client.
Außerdem solltest Du nach jedem Ändern der Konfig beide Maschinen (server und client) neu booten. Nervt zwar, stellt aber sicher das nicht irgendein Socket noch hängt und Du dir 'nen Wolf suchst obwohl eigentlich schon Alles richtig ist.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Geier0815 schrieb:
Wenn dann müßte es /24 sein.
Zum Vergrößern anklicken....
Ich wollte mit dieser Zeile explizit diese eine Maschine 172.16.11.20 erwischen. Bin zugegebenermaßen ein lausiger Netzwerk-Techniker, aber ich habe CIDR bislang so verstanden, dass ich dies tatsächlich mit 172.16.11.20/32 erreichen kann.

Diese Seite scheint das zu bestätigen:
https://www.dan.me.uk/ipsubnets?ip=172.16.11.20
 
OP
gehrke

gehrke

Administrator
Teammitglied
Ich habe diese beiden Varianten getestet, jeweils mit Neustart des NFS-Daemon:

Freigabe explizit nur für diese IP
Code: 
/home/paul/nfs  172.16.11.20/32(rw,sync,fsid=0)
Freigabe für das gesamte 172er Subnetz
Code: 
/home/paul/nfs  172.0.0.0/8(rw,sync,fsid=0)
Ich konnte keine Veränderung feststellen.
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
spoensche schrieb:
Code: 
    Jun 14 16:43:18 j4 rpc.mountd[2227]: refused mount request from 172.16.11.20 for / (/): not exported
Du versuchst / (also root) per NFS zu mounten, was in deiner /etc/exports nicht eingetragen ist. Daher kann es nicht funktionieren.
Zum Vergrößern anklicken....
Ich mache genau den selben mount-Aufruf, welcher auf Client 1 wunderbar funktioniert. Dort wird alles eingebunden, was auf dem Server unter dem Pfad /home/paul/nfs liegt.

Ich denke, das '/' bezieht sich hier nicht auf das Root-Verzeichnis des Servers sondern auf die Wurzel des Exports.
Zum Vergrößern anklicken....
Hier noch die Situation auf dem funktionierenden Client 1 zur Verdeutlichung.

Server:
Code: 
[root@j4 ~]# ls -l /home/paul/nfs
insgesamt 64
drwxrwx---.   6 paul private  4096 20. Dez 08:23 bitmap
drwxr-xr-x.   3 paul private  4096 27. Jan 2013  ebooks
drwxrwx---. 344 paul private 28672 22. Mai 20:55 music
drwxrwx--x.   5 paul private  4096  9. Jun 14:21 shared
drwxr-xr-x.   4 paul private  4096  4. Jan 2013  support-vpn
drwx-----x.  13 paul private  4096 18. Feb 08:46 system
drwxr-x---.  13 paul private 12288 14. Jun 2013  video
Client 1:
Code: 
j3:~ # mount -t nfs4 j4-private:/ /mnt
j3:~ # ls -l /mnt
total 68
drwx------   4 nobody nobody  4096 Jan  8  2012 .Trash-1000
drwxrwx---   6 nobody nobody  4096 Dec 20 08:23 bitmap
drwxr-xr-x   3 nobody nobody  4096 Jan 27  2013 ebooks
drwxrwx--- 344 nobody nobody 28672 May 22 20:55 music
drwxrwx--x   5 nobody nobody  4096 Jun  9 14:21 shared
drwxr-xr-x   4 nobody nobody  4096 Jan  4  2013 support-vpn
drwx-----x  13 nobody nobody  4096 Feb 18 08:46 system
drwxr-x---  13 nobody nobody 12288 Jun 14  2013 video
 
Geier0815

Geier0815

Guru
Um dich mal endgültig zu schockieren: Trage mal /home/paul/nfs als Pfad auf deinem client2 ein. Viele nfs4-server schalten automatisch auf nfs3 um wenn sie eine entsprechende Anfrage bekommen. Nimm dann aber auch nfs als Eintrag für den type.
Also so:
mount -t nfs j4-private:/home/paul/nfs /storage/nfstest/
 
OP
gehrke

gehrke

Administrator
Teammitglied
Habe Fassung und Sprache wiedergefunden. Erstmal vielen Dank an Geier0815 !

Ich hatte nicht ansatzweise erwogen, dass bei einem aktuellen Projekt heutzutage NFSv4 nicht supported sein könnte. Die Haltung der Projektbeteiligten kann ich nicht nachvollziehen und muss nun natürlich über die Konsequenzen nachdenken. Echt schade, denn bis dahin sah das schon ziemlich gut aus mit meinem feinen kleinen MediaCenter auf dem Pi.

Geier0815 schrieb:
Um dich mal endgültig zu schockieren: Trage mal /home/paul/nfs als Pfad auf deinem client2 ein. Viele nfs4-server schalten automatisch auf nfs3 um wenn sie eine entsprechende Anfrage bekommen. Nimm dann aber auch nfs als Eintrag für den type.
Also so:
mount -t nfs j4-private:/home/paul/nfs /storage/nfstest/
Zum Vergrößern anklicken....

Ja, das funktioniert tatsächlich irgendwie:
Code: 
OpenELEC:~ # mount -t nfs j4-private:/home/paul/nfs /storage/nfstest/
OpenELEC:~ # ls -ltar /storage/nfstest/
total 76
drwx------    4 1000     1000          4096 Jan  8  2012 .Trash-1000
drwxr-xr-x    4 1000     1000          4096 Jan  4  2013 support-vpn
drwxr-xr-x    3 1000     1000          4096 Jan 27  2013 ebooks
drwxr-x---   13 1000     1000         12288 Jun 14  2013 video
drwxrwxrwx   10 1000     1000          4096 Dec 15  2013 .
drwxrwx---    6 1000     1000          4096 Dec 20 07:23 bitmap
drwx-----x   13 1000     1000          4096 Feb 18 07:46 system
drwxrwx---  344 1000     1000         28672 May 22 18:55 music
drwxrwx--x    5 1000     1000          4096 Jun  9 12:21 shared
drwxr-xr-x   13 root     root          4096 Jun 17 05:51 ..
Damit bekomme ich aber Berechtigungsprobleme:
Code: 
OpenELEC:~ # ls -ltar /storage/nfstest/video/
ls: can't open '/storage/nfstest/video/': Permission denied
total 0
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
gehrke schrieb:
drwxr-x--- 13 1000 1000 12288 Jun 14 2013 video

OpenELEC:~ # ls -ltar /storage/nfstest/video/
ls: can't open '/storage/nfstest/video/': Permission denied
Zum Vergrößern anklicken....
Welcher Benutzer werkt hier:
Code: 
id
Zum Vergrößern anklicken....

Auf dem Server der User 'paul' (uid=1000, ,gid=100(users) Gruppen=100(users),1000(private)), bei OpenELEC passiert scheinbar immer alles als root. Jedenfalls läuft der xbmc-Prozess als root, welcher die Daten dann abgreifen soll.
 
Geier0815

Geier0815

Guru
Jetzt stellt sich die Frage wohin die Reise gehen soll. Ich hatte dir die mount-möglichkeit eigentlich nur genannt um dir zu zeigen das dein Server ohne dein Wissen die "vorgeblichen Sicherheitsfeatures" von nfs4 abschaltet wenn der client nur doof genug anfragt. Jetzt weißt Du auch warum sich nfs4 nicht wirklich durchgesetzt hat und auch keinen interessiert.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Geier0815 schrieb:
Jetzt stellt sich die Frage wohin die Reise gehen soll.
Zum Vergrößern anklicken....
Das ist jetzt tatsächlich die Gretchenfrage. Ich sehe derzeit diese Alternativen:
  • Verwendung einer anderen Distribution mit dem Ziel, darin NFSv4 nativ zu mounten. Die Einschränkung bezieht sich ja nur auf XBMC, nicht auf das Linux darunter. Dazu müsste ich aber wahrscheinlich auf Xbian oder RaspBMC o.a. wechseln, weil OpenOLEC nicht für Anpassungen gedacht ist (kein Paketmanagement, Onion-FS)
  • Verwendung eines anderen Netzwerk-Protokols. Hier könnte UPNP helfen, ein entsprechender DLNA-Server läuft in dem Netz schon.
  • Oder ich versuche eine andere export-Parametrisierung und teste mal, ob v3 von der Performance her nicht doch auch reicht.
Geier0815 schrieb:
Ich hatte dir die mount-möglichkeit eigentlich nur genannt um dir zu zeigen das dein Server ohne dein Wissen die "vorgeblichen Sicherheitsfeatures" von nfs4 abschaltet wenn der client nur doof genug anfragt. Jetzt weißt Du auch warum sich nfs4 nicht wirklich durchgesetzt hat und auch keinen interessiert.
Zum Vergrößern anklicken....
Ich weiß jetzt nicht, welche Sicherheitsfeatures Du genau meinst. Und ob die in meinem Fall serverseitig konfiguriert sind. Letztlich ist derzeit zu Debug-Zwecken auch lokale Firewall und SELinux abgeschaltet.

Dass es sich nicht durchgesetzt hat, kann ich nicht bestätigen. Ich habe es schon an mehreren Stellen im Einsatz gesehen. Wahrscheinlich machen sich aber tatsächlich die wenigsten die Mühe, eine funktionierende v3 Installation ohne Not zu ändern. Wenn, dann ist wohl zumeist die bessere Performance das Hauptmotiv.
 
OP
gehrke

gehrke

Administrator
Teammitglied
gehrke schrieb:
*Verwendung eines anderen Netzwerk-Protokols. Hier könnte UPNP helfen, ein entsprechender DLNA-Server läuft in dem Netz schon.
Zum Vergrößern anklicken....
Ich habe es jetzt in einem ersten Versuch mit UPNP (serverseitig miniDLNA) versucht und das funktioniert überraschend gut. Es handelt sich um FullHD-Videos (h.264), die der PI aus dem LAN zieht und tatsächlich ohne Ruckeln abspielt. Ich denke, dass ich in dieser Richtung weiterarbeiten werde, lass das hier aber noch geöffnet. Sicher kommt da noch was...

Vielen Dank an alle.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben