freetz 7390 als nfs client zeigt leeres Verzeichnis

[joze]

Hi,

habe hier das aktuelle Freetz (Nov 2017 von svn) auf einer Fritzbox 7390 mit avm firmware 6.83.
Habe in der Konfiguration (hoffentlich) alles eingeschaltet, was man für einen nfs client braucht.

auf der Box:

cat /proc/filesystems
...
nodev nfs
...

nfs sollte also da sein.

Wenn ich nun per nfs mounte (wobei der server richtig konfiguriert ist und im Subnetz von anderen clients problemlos erreichbar ist), z.B.

mount -t nfs 192.168.178.9:/ /var/mod/root/mnt

dann scheint das auch ohne Fehlermeldungen zu funktionieren.

Ein anschließendes mount ergibt:

192.168.178.9:/ on /var/mod/root/mnt type nfs (rw,vers=3,rsize=524288,wsize=524288,namlen=255,hard,nointr,nolock,proto=tcp,timeo=70,retrans=3,sec=sys,addr=192.168.178.9)

noch immer sieht alles ganz ok aus.

Allerdings:

ls /var/mod/root/mnt
cd /var/mod/root/mnt
ls

Beide ls Befehle (als root auf der Box ausgeführt) zeigen nur ein leeres Verzeichnis an.

Irgendwelche Ideen, warum der nfs mount funktioniert, aber dann nur ein leeres Verzeichnis angezeigt wird?

 

[PeterPawn]

Wie sieht denn der exportierte Eintrag auf den NFS-Server genau aus? Welche Ports verwendet der Client auf der FRITZ!Box für den Zugriff? Ich will auf das mögliche Fehlen von "insecure" hinaus ... wobei dann wohl eigentlich schon das Mounten fehlschlagen müßte.

Andererseits ist so ein leeres Verzeichnis meist ein Zeichen für ein Rechteproblem beim Mapping zwischen Server und Client.

 

[joze]

/etc/exports auf dem Server (debian unstable):

/ 192.168.0.0/255.255.0.0(async,rw,no_root_squash,no_subtree_check)

wobei die besagte Fritzbox die ip 192.168.178.6 hat und das mounten von anderen clients aus im Subnetz wie gesagt (seit Jahren) problemlos funktioniert.
Der Server ist mit der Fritzbox über LAN und einen Switch verbunden und von der Fritzbox aus auch problemlos über ping oder ssh erreichbar.

Bei den ports habe ich überhaupt nichts eingestellt, d.h. ich gehe davon aus, dass da defaults verwendet werden.

 

[PeterPawn]

Da ist ja schon mal ein "no_root_squash" drin in den Optionen auf dem Server ... diese "anderen Clients", greifst Du von denen aus auch als "root" zu bzw. funktioniert das von dort auch noch, wenn Du "root" bist (und zwar nicht nur über ein "sudo" beim Mounten)? Eigentlich sollte das "no_root_squash" zwar dafür sorgen, daß der Zugriff für "root" nicht auf einen unprivilegierten Account umgebogen wird, aber - wie schon einmal geschrieben - solche leeren Verzeichnisse sind in aller Regel das Ergebnis eines Rechteproblems.

Ansonsten sollten die Ports in der Ausgabe von "nfsstat -m" zu sehen sein ... und auch ein Blick ins Syslog des NFS-Servers kann ggf. Aufklärung bringen, falls da z.B. Nachrichen in der Art "nfsd: request from insecure port ..." auftauchen sollten.

Theoretisch stellt das Mounten eines NFS-Shares nur ein Handle bereit und ein "erfolgreiches" Mounten ist noch keine Garantie dafür, daß dort hinterher Zugriffe auch funktionieren - es wird ja keine "Dateisystemstruktur" beim Mounten geprüft. Auch hier kann "nfsstat -v" durchaus Aufschluß bringen, welche NFS-Calls genau fehlschlagen und mit welchen Fehlerbedingungen (badcall, badclnt, badauth, usw.).

 

[joze]

ja ich greife von anderen clients auch als root zu und zwar direkt als root und nicht mit sudo.
Ich mounte da beispielsweise als root für ein volles Systembackup auf einen nfs Server.

nfsstat -m auf der Fritzbox zeigt (nach dem mounten)

/var/mod/root/mnt from 192.168.178.9:/
 Flags: rw,vers=3,rsize=524288,wsize=524288,namlen=255,soft,nointr,nolock,proto=tcp,timeo=70,retrans=3,sec=sys,addr=192.168.178.9

auf dem nfs server bekomme ich mit showmount

# showmount
...
192.168.178.6
...

(192.168.178.6 ist die besagte fritzbox 7390, von der aus ich per nfs mounte).

auf dem nfs server zeigt /var/log/syslog als einzigen relevanten Eintrag:

rpc.mountd[14482]: authenticated mount request from 192.168.178.6:643 for / (/)

nfsstat -v zeigt:

Server rpc stats:
calls            badcalls   badfmt     badauth    badclnt
11897798   0               0              0               0

Hmm... Sieht doch alles ganz ok aus -- nur dass eben das gemountete Verzeichnis auf dem client komplett leer ist.

@PeterPawn -- hast Du noch weitere Ideen?

 

[PeterPawn]

Ideen hätte ich viele ... solange man die alle selbst umsetzen kann, ist das auch kein Problem. Nur das "Erläutern", warum man irgendetwas für sinnvoll hält als Test, ist etwas mühsam.

Ich finde z.B. die vereinbarten Blockgrößen beim Lesen (rsize) und Schreiben (wsize) etwas sehr hoch und würde hier - zur Fehlersuche - erst mal mit den Standardwerten arbeiten (und dabei notfalls auch alle Automatismen überstimmen). Diese Werte sind auch dafür bekannt, daß sie mit älteren Kernel-Versionen (und die 7390 müßte noch einen 2.6.28er haben) Probleme bereiten, wenn man sie zu hoch wählt und der Standardwert bei NFSv3 waren 8 KB, iirc. Da es sich beim Server vermutlich um einen NFSv4-Server handeln wird und der Client in Freetz meines Wissens nur NFSv3 beherrscht (zumindest wird ja auch nur Version 3 angezeigt), würde ich hier den beiden etwas unter die Arme greifen und so wenig wie möglich dem Zufall (bzw. der "Aushandlung") überlassen.

Vielleicht hängst Du ja mal die verwendete ".config" an ... dann kann man auch selbst sehen, was Du nun eingestellt hast und ob Deine Hoffnung aus #1 berechtigt ist.

 

[joze]

vielen Dank.
Interessanterweise kann ich obwohl Verzeichnisse und Dateien per ls auf dem client nicht sichtbar sind auf diese zugreifen.
Das muss ich auf dem client (fritzbox) quasi "blind" machen, indem ich die Pfade auf dem Server kenne.
cd in Unterverzeichnisse des nfs mounts funktioniert auch, sofern der Pfad existiert, aber auch dort zeigt ls nichts an.
Beispiel: wenn ich / des servers per nfs mounte, kann ich auf dem freetz client per vim das /<mountpoint>/etc/passwd des servers öffnen.
Sehr seltsam.
Das einzige was also nicht funktioniert sind ls und die file name completion der shell.
Anbei das freetz .config.