# nfs warning: mount version older than kernel ???

## thengelh

Hallo zusammen,

ich habe soeben an einem Client Gentoo 2004.0 mit Kernerl-2.6.3-rc1 fast erfolgreich installiert.

Das /home und ein zusätzliches Verzeichniss werden von einem Gentoo-server mit einem 2.4er Kernel exportiert und am o.g. client eingebunden.

Beim booten hängt der Client ziemlich lange .. 30 sec beim mounten der Netzlaufwerke.

Ein dmesg wirft folgendes aus: nfs warning: mount version older than kernel

portmap wird gestartet, nfs version 3 ist in beiden Kernels eingebunden. Bei hoher Belastung im Netz meldet der Client desöfteren NFS Server not responding... dann wieder NFS Server OK...

Irgendwie weis ich nimmer weiter...

Vielen Dank für Eure Hilfe im vorraus

Thomas

----------

## moe

hast du nolock als Option in der fstab? Die Warnung kannst du ignorieren..

Gruss Maurice

----------

## thengelh

[quote="moe"]hast du nolock als Option in der fstab? Die Warnung kannst du ignorieren..

Gruss Maurice

Nein habe ich nicht. Ist die notwendig ?

----------

## moe

Ich hab jetzt die manpage nicht im Kopf warum und wieso, aber durch nolock geht das mounten erheblich schneller..

----------

## Kraymer

 *thengelh wrote:*   

> Ein dmesg wirft folgendes aus: nfs warning: mount version older than kernel

 

Diese Nachricht erscheint auch, wenn der Kernel des nfs-Servers die Version nicht unterstützt; beispielsweise, wenn der Server NFSv2 hat und Du Client Support für v3. Aber ich seh grad, Du hast ja geschrieben, daß beide v3-Unterstützung haben..

Aber versuch vielleicht mal, die Version beim mounten zu übergeben, ich glaube, es geht mit nfsvers=3.

Bei mir kam diese Fehlermeldung, als ich NFS over TCP ausprobieren wollte, der Server dies aber nicht unterstützte.

Daß der Server manchmal nicht antwortet, liegt vielleicht dran, daß er überlastet ist. Versuche einfach, noch mehr nfsd's zu starten. Ich glaube, default sind 6 oder 8; müßte über eine conf direkt konfigurierbar sein.

Sebastian

----------

## BlackEye

Ich habe essato das gleiche Problem.

Ebenfalls läuft mein Server mit einem 2.4er Kernel mit:

```
CONFIG_NFS_FS=y

# CONFIG_NFS_V3 is not set

# CONFIG_NFS_DIRECTIO is not set

# CONFIG_ROOT_NFS is not set

CONFIG_NFSD=y

CONFIG_NFSD_V3=y

# CONFIG_NFSD_TCP is not set
```

Auf meinem Client 2.6.8.1-mm4 mit:

```
CONFIG_NFS_FS=y

CONFIG_NFS_V3=y

# CONFIG_NFS_V4 is not set

# CONFIG_NFS_DIRECTIO is not set

CONFIG_NFSD=y

CONFIG_NFSD_V3=y

# CONFIG_NFSD_V4 is not set

CONFIG_NFSD_TCP=y
```

und sowohl ein

```
mount -t nfs 192.168.0.254:/usr/portage/distfiles /mnt/temp/
```

als auch ein

```
mount -t nfs -o nfsvers=3 192.168.0.254:/usr/portage/distfiles /mnt/temp/
```

bringen (Serverseitig) das (sieht nach nem OK aus)

 *Quote:*   

> Aug 26 12:46:32 gandalf rpc.mountd: authenticated mount request from murpy.studi.lan:641 for /usr/portage/distfiles (/usr/portage/distfiles)

 

und (Clientseitig) ein (da stimmt was nicht...)

 *Quote:*   

> Aug 26 21:02:54 murpy nfs warning: mount version older than kernel

 

es funktioniert allerdings _kurzzeitig_ problemlos. Wenn ich allerdings ein paar Stunden warte und ein bissl arbeite, kommt bei einem gemounteten NFS-Dir folgendes Problem:

```
murpy temp # touch test

touch: kann ,,test" nicht berühren: Keine Berechtigung
```

und das als root .... Also nach ein paar Stunden ist das Laufwerk nicht mehr ansprechbar... -> unuseable

ergo: da stimmt was nicht!

Ideen?

Bitte, ich mag dieses samba nicht mehr haben in meiner reinen Linuxumgebung :/ So ein hin und her mit den Rechten beim samba machen mich schon ganz irre. NFS wäre so schön einfach... *seufz*

----------

## Kraymer

Verständlich, Samba suckt hinsichtlich Rechtevergabe etc. auf jeden Fall  :Smile:  Wenn kein Windows-Client in der Nähe ist, sollte nfs schon am Start sein..

Die Warnung ..older than kernel verwundert mich auch, doch dies hat wohl nichts damit zu tun, daß die Verbindung irgendwann rumspackt. Wenn ich mich recht erinnere, kommt diese Meldung bei mir auch, und es funktioniert alles soweit sehr gut.

Ich würd mal in die Manpage schauen und nach Optionen für den Dateizugriff suchen.. Beim Mounten über die Kommandozeile werden ja viele Standardwerte benutzt, über deren Bedeutung du dir wohl (noch) nicht im klaren bist. Nichtsdestotrotz ist es natürlich normal, erstmal davon auszugehen, daß es mit den Defaults funktionieren sollte, kein Vorwurf an dieser Stelle.

Ich zeig Dir einfach mal meinen fstab-Eintrag, vielleicht fällt Dir da ja was auf, oder du probierst ihn einfach mal.

Sebastian

```
borgcube:/storage       /mnt/borgcube   nfs             defaults,wsize=32768,rsize=32768,nfsvers=3,hard,intr,posix
```

----------

## BlackEye

Danke für den Tipp mit den Standardwerten. Denn genau das die waren das Problem. Aber nicht mal auf Clientseite sondern auf der Serverseite. NFS exportiert Verzeichnisse standardmässig so, dass ein Root-Zugriff Serverseitig auf ein guest-Account umgelegt wird. Da ich die Distfiles vom Server bei mir eingemountet hatte, bekam ich dann diesen Zugriffsfehler. Ein Blick in die man-Page löste dann das Problem!

Deine Parameter "wsize=32768,rsize=32768,nfsvers=3,hard,intr,posix" sind allerdings interessent. Ich werd mir mal anschauen, was die alle zu bedeuten haben. Z.zt. mounte ich einfach so

```
gandalf.studi.lan:/usr/portage/distfiles        /usr/portage/distfiles          nfs             tcp                     0 0
```

Dann werd ich aber mal schauen, was an Denen Werten besser ist  :Smile: 

Gruß

----------

## Kraymer

Allright   :Cool:    Schön, daß es jetzt bei Dir zu funktionieren scheint.  Allerdings ist mir nicht klar, wie Du die (fehlerhaften, wg. root->guest) Zugriffe geändert hast, allein durch die Option tcp?!

Die r-/wsize-Parameter sind hauptsächlich drin, weil ich auf Filmmaterial und Musik über nfs zugreife. Bei kleineren Dateien (ebuilds, sourcecode etc.) ist dies mit Sicherheit nicht nötig. Bei Kopien, die MB-weise geschehen, könnte Dir das was bringen. Ich hab versucht, damit die Performance zu erhöhen, da ich beim Umstieg auf 2.6er-Kernel und/oder gentoo (weiß nicht mehr genau, wann genau es passierte) Geschwindigkeitseinbußen beim Lesen von nfs hatte..

Berichte mal ruhig von deinen Erfahrungen, nfs-Tweaking interessiert mich immer  :Smile: 

Sebastian

----------

## BlackEye

neee, die Option tcp ist ja in der fstab hier lokal. Auf dem Server hab ich das Verzeichniss folgendermaßen exportiert

```
gandalf root # cat /etc/exports

# /etc/exports: NFS file systems being exported.  See exports(5).

/usr/portage/distfiles          192.168.0.0/24(rw,sync,no_root_squash)
```

Das 'no_root_squash' ist der verantwortliche Parameter. Der sorgt dafür, dass root _nicht_ als guest fungiert. Standardmässig ist 'root_squash' angestellt.

manpage:

 *Quote:*   

>        root_squash
> 
>               Map requests from uid/gid 0 to the anonymous uid/gid. Note  that
> 
>               this does not apply to any other uids that might be equally sen-
> ...

 

So.. ist natürlich auch eine Sicherheitsfrage, klar. Aber das distfiles-Verzeichnis ist ja nicht wirklich ein sicherheitskritischer Bereich  :Smile: 

Die Option tcp scheint wohl die bessere Wahl zu sein, wenn es um eine stabile Verbindung bei hoher Netzwerklast geht. Kann man sich sicherlich drüber streiten, aber zum Test hab ich sie mal aktiviert.

Gruss

----------

## Kraymer

 *BlackEye wrote:*   

> 
> 
> So.. ist natürlich auch eine Sicherheitsfrage, klar. Aber das distfiles-Verzeichnis ist ja nicht wirklich ein sicherheitskritischer Bereich 
> 
> Die Option tcp scheint wohl die bessere Wahl zu sein, wenn es um eine stabile Verbindung bei hoher Netzwerklast geht. Kann man sich sicherlich drüber streiten, aber zum Test hab ich sie mal aktiviert.

 

Naja, wenn Dir jemand ein Ebuild verändert, so daß Du beim nächsten update über ein Patch kompromittierten Code eingeschleust kriegst.. Aber das ist wohl über-paranoid.

Man könnte allerdings mal abchecken, ob mit sandbox, userpriv und usersandbox in den features nicht sogar Rechte für portage reichen.. Aber egal, hauptsache, funktioniert  :Smile: 

Viel Spaß

Sebastian

----------

## BlackEye

Du verwechselst gerade das distfiles-Verzeichnis mit dem Portage-Tree  :Smile: 

Ich meine das /usr/portage/distfiles Verzeichnis, welches _nur_ die Pakete der ebuilds vorrätig hält. Und da selbige noch per MD5 Checksumme vor dem Entpacken verglichen werden, ist also eigentlich (fast) jede sicherheitskritische Frage geklärt  :Smile: 

So, und nun geh ich ins Bett. Gerade komm ich noch vom Stadtfest und kann eigentlich nur noch an mein Bett denken *g*

Gn8!

----------

## Kraymer

 *BlackEye wrote:*   

> Du verwechselst gerade das distfiles-Verzeichnis mit dem Portage-Tree 

 

Stimmt natürlich   :Rolling Eyes:  Vermutlich, weil ich mir wg. dieses Threads überlegt hab, mit meinem Server /usr/portage zu teilen, damit auch 'emerge sync's nicht doppelt gemacht werden müssen.

----------

## BlackEye

mit diesem Gedanken hab ich dann gespielt, als Du es mir gesagt hast  :Smile: 

Ich werde das mal so machen denke ich... warum auch nicht? Gute Idee  :Smile: 

Gruß

----------

