Veraltete NFS-Zugriffsnummer

Computer: Software & Programmierung UNIX & Linux
#1

Moin,

ich wundere mich gerade über eine Meldung, die ich hier auf meinem Rechner bekomme:

Devera:/home/ingo # ll /home/ingo/daten/paul/fallrohr
/bin/ls: /home/ingo/daten/paul/fallrohr/.: Veraltete NFS-Dateizugriffsnummer
insgesamt 544
drwxrwxr-x 10 root users 16384 2005-01-31 09:24 ..
drwxrwxr-x 2 root users 147456 2005-01-27 15:44 80V\_10mbar 
-rwxrwxr-x 1 root users 2464 2005-01-28 13:27 80V\_10mbar\_1.2mu\_oben\_mit.dat

Was hat mir diese Meldung " Veraltete NFS-Dateizugriffsnummer" zu sagen bzw. wie kann ich die vermeiden? Es handelt sich bei dem Dateisystem um eine lokale Platte, die ein Fat32-Dateisystem hat:

Devera:/home/ingo # cat /etc/fstab
...

/dev/hdd1 /home/ingo/daten vfat users,gid=users,umask=0002,iocharset=iso8859-1,code=437 0 0

Beste Grüße,
Ingo

#2

Nachtrag
Moin nochmal,

auch ein re-mount behebt das Problem nicht und es ist schon irgendwie nervig, wenn man mit ls in dem Verzeichnis selbst kein Directory-Listing mehr bekommt. Dann bekommt man die selbe Fehlermeldung aber keine Dateien angezeigt.

Gruß zum zweiten,
Ingo

#3

Moin,

Mahlzeit,

ich wundere mich gerade über eine Meldung, die ich hier auf
meinem Rechner bekomme:

> Devera:/home/ingo # ll /home/ingo/daten/paul/fallrohr  
> /bin/ls: /home/ingo/daten/paul/fallrohr/.: Veraltete NFS-Dateizugriffsnummer

Falls Du ueber solche deutschen Fehlermeldungen wenig bis nichts im google findest solltest Du den englischen eine Chance geben. Das englische Pendant kann man temporaer durch ein vorangestelltes LANG=C erhalten:

 $ LANG=C ls -l

Es handelt sich bei dem Dateisystem um eine lokale Platte,
die ein Fat32-Dateisystem hat:

Dort sollte das eigentlich nicht auftreten. Solche Meldungen wirft auch nur der Kernel, ls gibt sie einfach weiter. Der Fehler tritt auf, wenn sich die inode number eines filehandles aendert. Das passiert ueblicherweise nur bei NFS, nicht auf FATs. Wird das Verzeichnis exportiert? Wird es von anderen Rechnern gemounted? Laufen auf dem Rechner die NFS server, namentlich mountd und portmap? Was passiert, wenn Du die abstellst? Welche Kernelversion laeuft bei Dir? Hilft, wenn moeglich, ein update?

Gruss vom Frank.

#4

Salut nochmals,

Falls Du ueber solche deutschen Fehlermeldungen wenig bis
nichts im google findest solltest Du den englischen eine
Chance geben. Das englische Pendant kann man temporaer durch
ein vorangestelltes LANG=C erhalten:

$ LANG=C ls
-l

Merci. Aber auch unter der englischen Bezeichnung stale nfs filehandle läßt sich nicht wirklich etwas mir hilfreiches finden - oder ich habe Tomaten auf den Augen.

Jetzt nach dem Mittag läßt sich der Fehler auch nicht mehr reproduzieren und es funktioniert ohne, daß ich etwas geändert hätte. Sehr merkwürdig.

Dort sollte das eigentlich nicht auftreten. Solche Meldungen
wirft auch nur der Kernel, ls gibt sie einfach weiter. Der
Fehler tritt auf, wenn sich die inode number eines filehandles
aendert. Das passiert ueblicherweise nur bei NFS, nicht auf

Yup, das würde ich auch denken. Auf diesem Rechner wird bzgl. Dateisystemen nichts exportiert und nichts importiert und es läuft weder ein NFS-Server noch Client.

Aber Du brachtest mich auf die Idee, 'mal wieder /var/log/messages mir anzugucken. Neben diversen Versuchen irgendwelcher IPs, sich hier illegal mit Standardlogins per SSH Zugang zu verschaffen, fand ich Folgendes:

Jan 31 07:53:43 Devera modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.21-243-default/modules.dep (No such file or directory)

Ob das 'was damit zu tun haben könnte? Von der Zeit her könnte das passen…

FATs. Wird das Verzeichnis exportiert? Wird es von anderen
Rechnern gemounted? Laufen auf dem Rechner die NFS server,
namentlich mountd und portmap? Was passiert, wenn Du die
abstellst? Welche Kernelversion laeuft bei Dir? Hilft, wenn
moeglich, ein update?

SuSE-Kernel 2.4.21-243-default

läuft, was dem sicherheitsmäßig aktuell gepatchten Kernel für SuSE 9.0 entspricht.

Vielleicht sollte ich 'mal über’n Update nachdenken…

Gruß,
Ingo

#5

Aber auch unter der englischen Bezeichnung stale nfs
filehandle läßt sich nicht wirklich etwas mir hilfreiches
finden - oder ich habe Tomaten auf den Augen.

Nein.

Jetzt nach dem Mittag läßt sich der Fehler auch nicht mehr
reproduzieren und es funktioniert ohne, daß ich etwas geändert
hätte. Sehr merkwürdig.

Ja. Vielleicht brauchte der Rechner eine Pause? Und: auch im Linux sind nicht alle Dinge so, wie sie sein sollten.

> Jan 31 07:53:43 Devera modprobe: modprobe: Can't open  
> dependencies file /lib/modules/2.4.21-243-default/modules.dep  
> (No such file or directory)

Ob das 'was damit zu tun haben könnte?

Eher nicht. Irgendwer hat das dependencie file von Deinen LKMs geloescht.

 # depmod -a

sollte das flicken (eigentlich haette ich erwartet, das SuSE sowas bei jedem booten macht).

Gruss vom Frank.

#6

Aber auch unter der englischen Bezeichnung stale nfs
filehandle läßt sich nicht wirklich etwas mir hilfreiches
finden - oder ich habe Tomaten auf den Augen.

Nein.

Ich erinnere mich vage, daß ich sowas auch mal in meinen Logs hatte …

Eher nicht. Irgendwer hat das dependencie file von Deinen
LKMs geloescht.

depmod -a

sollte das flicken
(eigentlich haette ich erwartet, das SuSE sowas bei jedem
booten macht).

Ich wäre ja bereit gewesen, das zu wetten. Debian macht das jedenfalls …

Gruß,

Sebastian

#7

Moin,

Jetzt nach dem Mittag läßt sich der Fehler auch nicht mehr
reproduzieren und es funktioniert ohne, daß ich etwas geändert
hätte. Sehr merkwürdig.

Ja. Vielleicht brauchte der Rechner eine Pause? Und: auch im
Linux sind nicht alle Dinge so, wie sie sein sollten.

Eher nicht. Irgendwer hat das dependencie file von Deinen
LKMs geloescht.

depmod -a

sollte das flicken
(eigentlich haette ich erwartet, das SuSE sowas bei jedem
booten macht).

Hmm… offensichtlich doch 'mal 'n Restart gefällig. Werde ich 'mal heute im Mittagstief machen.

ingo@Devera:~\> uptime
 8:47am an 35 Tage 4:21, 22 Benutzer, Durchschnittslast: 0,43, 0,29, 0,12

Gruß und Danke für Deine Hilfe,
Ingo