ubuntuusers.de

Hallo,

ich habe ein Problem mit meinem Netzwerk (1 Server, 3 Arbeitsplatzrechenr). Dieses läuft mit NFS. Auf dem Server ist ein aktuelles Debian Squeeze 6.0.7 installiert.

Das Problem einmal kurz optisch dargestellt. Die Verzeichnisse auf dem Server:

1
2
3
4
5
6

drwxr-xr-x  2 mala users  4,0K Okt  1  2010 Bilder
drwxr-xr-x  2 mala users  4,0K Mär 12 13:52 Desktop
drwxrwxrwx 18 mala users  4,0K Mär 11 12:40 Dokumente
drwxrwxrwx 10 mala users   16K Mär 13 11:23 Downloads
drwxr-xr-x  2 mala users  4,0K Okt  1  2010 Musik
drwxrwxrwx  3 mala users  4,0K Jun  3  2011 Videos

Auf dem Arbeitsplatzrechner kommt das Ganze so an:

1
2
3
4
5
6

drwxrwxr-x   4 4294967294 4294967294  4096 10. Mär 12:40 Bilder
drwxr-xr-x   2 4294967294 4294967294  4096 12. Mär 13:52 Desktop
drwxrwxrwx  18 4294967294 4294967294  4096 11. Mär 12:40 Dokumente
drwxrwxrwx  10 4294967294 4294967294 16384 13. Mär 11:23 Downloads
drwxrwxrwx 145 4294967294 4294967294 12288 28. Feb 16:37 Musik
drwxrwxrwx   3 4294967294 4294967294  4096  3. Jun 2011  Videos

Daraus ergeben sich diverse Problem. Um nur eines zu nennen: wine ist nicht mehr in der Lage gestartet zu werden. Es erfolgt die Meldung, dass /home/mala/.wine nicht in meinem Besitz ist.

Nun zur Konfiguration auf dem Server: Die /etc/exports enthält folgendes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

  GNU nano 2.2.6            Datei: /etc/exports                                 

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_sub$
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#

/home 192.168.178.0/255.255.255.0(rw,async,no_subtree_check)

Die Dateien /etc/hosts.allow bzw. /etc/hosts.deny wurden nicht verändert und haben ihren vorgegebenen Inhalt.

Eingehängt werden die Daten auf dem Arbeitsplatzrechner in der /etc/fstab:

1

192.168.178.100:/home /home nfs rw 0 0

Jetzt könnte man natürlich auf die Idee kommen, dass die UID/GID auf Server und Arbeitsplatzrechner nicht übereinstimmen. Dem dürfte aber nicht so sein. Auf dem Server sieht es wie folgt aus (cat /etc/passwd):

1

mala:x:1000:1000:MaLa,,,:/home/mala:/bin/bash

Und auf dem Arbeitsplatzrechner:

1

mala:x:1000:1000:MaLa,,,:/home/mala:/bin/bash

Bislang lief das System über zwei Jahre fehlerfrei. Wieso das nun nicht mehr so ist, kann ich nicht ganz nachvollziehen. Es wurde in den vergangenen Tagen lediglich ein Update am Server durchgeführt, das hierfür ursächlich sein könnte. Aber soweit ich es sehe, sollte eigentlich alles korrekt sein. Daher verstehe ich nicht, wieso auf dem Arbeitsplatzrechner die Verzeichnisse nicht korrekt zugeordnet werden.

Vielleicht hat jemand von Euch eine Idee?

Hallo MaLa,

bist du dir sicher das an den Clients nichts verändert wurde? Keine Fehlermeldungen? "grep NFS /var/log/messages" Wäre es möglich, dass die Clients den Eintrag in /etc/fstab als NFS4 Share deuten? Evtl. einmal händisch mit "mount.nfs" probieren.

Hallo gendjaral,

1

grep NFS /var/log/messages

ergibt

1
2
3
4
5

Mar 11 11:14:37 ml-linux-2 kernel: [   36.408826] RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 11 13:26:08 ml-linux-2 kernel: [   35.386020] RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 12 10:36:50 ml-linux-2 kernel: [   40.652939] RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 12 17:24:51 ml-linux-2 kernel: [   43.472876] RPC: Registered tcp NFSv4.1 backchannel transport module.
Mar 13 10:35:36 ml-linux-2 kernel: [   41.428977] RPC: Registered tcp NFSv4.1 backchannel transport module.

Ich sehe hier zumindest keinen Fehler?!

Der Eintrag in der /etc/fstab steht so schon seit Jahren ohne dass es Probleme gab. Ich kann natürlich gerne das mit mount.nfs testen. Wobei ich mit dieser Syntax spontan nichts anfangen kann. Wie wäre hier ein gültiger Eintrag zu gestalten?

Stimmt, im Logfile wird scheinbar kein Fehler gefunden. Welche Updates wurden denn an deinem Server vorgenommen?

"mount.nfs" ist nur eine vereinfachte Version von "mount -t nfs" für das händische mounten.

1

mount.nfs ip-addy:/home /home

Wenn du NFS3 in der fstab erzwingen möchtest müsstest du bei den optionen (rw, usw.) vers=3 angeben:

1
2
3
4
5
6
7
8

       nfsvers=n      The NFS protocol version number used to contact the server's NFS service.  If the server does not sup‐
                      port  the  requested  version,  the  mount request fails.  If this option is not specified, the client
                      negotiates a suitable version with the server, trying version 4 first, version 3 second, and version 2
                      last.

       vers=n         This  option  is  an  alternative  to the nfsvers option.  It is included for compatibility with other
                      operating systems.

Da waren einige Updates, die mittels apt-get -u dist-upgrade vorgenommen wurden.

Ich musste nach dem Update per Hand Änderungen am Apache vornehmen, da dieser zunächst ebenfalls nicht mehr lief. Ich meine es war irgendetwas an der /etc/apache2/apache.conf.

Dein Vorschlag mit vers=3 hat bisher auch zu keiner Lösung des Problems geführt.

Gibt es noch irgendeine Idee, wie ich das Problem fixen könnte? Oder alternativ das ganze auf Samba umstellen?

Wenn ich auf dem Arbeitsplatz-PC ein Verzeichnis erstelle, sieht es wie folgt aus:

1

drwxr-xr-x   2 4294967294 4294967294  4096 17. Mär 13:05 test

Auf dem Server ist es allerdings korrekt:

1

drwxr-xr-x  2 mala mala 4,0K Mär 17 13:05 test

Hehehe... zwischen einem Update und (Dist)Upgrade sollte dann doch noch differenziert werden. ☺

Wie hast du denn nun das NFS share am Client gemountet? "vers=3" beim Client in die /etc/fstab gepackt? Die richtige (eigene) UID wird ja nun durch den Client gesetzt. Nur der Lookup scheint immer ins leere zu laufen und wird mit einem nfsnobody quittiert.

Von wo nach wo hast du den Server nun eigentlich migriert?

ugrade oder dist-upgrade: Das sollte man wohl unterscheiden...! Da gebe ich Dir völlig Recht! Der kleine, aber feine Unterschied ist mir allerdings erst vorhin wieder aufgefallen, nachdem ich nochmal genau nachgeschaut habe.

Zu deinen Fragen: Am Client sieht die /etc/fstab wie folgt aus:

1

192.168.178.100:/home /home nfs rw 0 0 vers=3

Der Server meldet aktuell:

1
2
3
4
5

LSB Version:	core-2.0-ia32:core-2.0-noarch:core-3.0-ia32:core-3.0-noarch:core-3.1-ia32:core-3.1-noarch:core-3.2-ia32:core-3.2-noarch
Distributor ID:	Debian
Description:	Debian GNU/Linux 6.0.7 (squeeze)
Release:	6.0.7
Codename:	squeeze

Das dist-upgrade war aufgrund einiger Pakete notwendig, die nicht mittels upgrade aktualisiert werden konnten.

Huh? Geht das denn so? Noch nie gesehen... IMHO müssen die Optionen in der /etc/fstab durch Komma getrennt zusammen stehen:

1

192.168.178.100:/home   /home   nfs   rw,nfsvers=3   0 0

Wenn du händisch mountest, siehst du dann die richtigen UIDs?

1
2
3

mkdir /mnt/nfstest && mount.nfs 192.168.178.100:/home /mnt/nfstest
---
umount /mnt/nfstest && rmdir /mnt/nfstest

Demnach, du hattest vorher Debian Lenny und hattest kürzlich auf Squeeze migriert? Ich hoffe du hattest vor dem Upgrade ein Update des Systems vollzogen... unter Berücksichtigung das am 6. Feb 2012 Lenny offiziell eingestellt und das Repos. ins Archiv verschoben wurde?

http://wiki.ubuntuusers.de/NFS#Auf-Freigaben-zugreifen Hier wird es auch ohne Komma eingesetzt. Und scheinbar funktioniert es. Werde es aber testweise umstellen.

Auch das mounten per Hand hilft nicht weiter. Die UID bleiben - zumindest am Client - falsch. Auf dem Server hingegen ist alles richtig.

Nein, der Server wurde bereits mit Squeeze aufgesetzt. Lenny war nie installiert. Aber es kam nach apt-get update && apt-get upgrade die Meldung, dass ein Teil der Pakete nur mittels apt-get -u dist-upgrade aktualisiert werden können.

MaLa schrieb:

Hier wird es auch ohne Komma eingesetzt. Und scheinbar funktioniert es. Werde es aber testweise umstellen.

nein, die fstab hat einen festen Syntax mit 6 Spalten (Leer oder Tab getrennt), wobei in Spalte 4 die Optionen mit Komma ohne Leerzeichen getrennt stehen. Im genannten wiki Link ist hierzu auch kein "falsches" Beispiel.

richtig wäre also:

192.168.178.100:/home /home nfs rw,nfsvers=3 0 0 

viele Grüße u1000

So steht es im Wiki:

Beispiel für den Eintrag in die /etc/fstab:

192.168.6.13:/home /media/server nfs rw 0 0

Lese ich da etwas falsch? Oder erscheint es nur so, weil hier lediglich rw als einzige Option eingesetzt wird?

Jub, genau das. "rw" ist die einzigste Option. Es spielt übrigens keine Rolle wieviele Leerzeichen du zwischen den einträgen hälst. Sieh dir einfach einmal den Artikel fstab im Wiki an.

Gut, das erklärt dann zumindest einen Teil. Ich habe den Eintrag nun entsprechend angepasst:

1

192.168.178.100:/home /home nfs rw,vers=3 0 0

Mal schauen, wie es nach einem Restart des Clients aussieht.

Da lag der Hund begraben! Nun scheint alles in Ordnung zu sein. Wieso das allerdings jahrelang fehlerfrei lief, ist mir schleierhaft.

Vielen Dank für die Hilfe!