ubuntuusers.de

Kein Zugriff über NFS auf anderes Linuxsystem

Status: Gelöst | Ubuntu-Version: Kubuntu 13.04 (Raring Ringtail)
Antworten |

Fried-rich

Anmeldungsdatum:
2. Mai 2013

Beiträge: 1163

Hallo,

ich habe mich am NFS-Eintrag in der Wiki orientierend versucht eine Netzwerkverbindung von meinem Kubuntu zu einem RaspberryPi mit Raspbian (= Debian) herzustellen. Ich habe auf dem Pi "nfs-kernel-server" installiert, dann die /etc/exports eingetragen

/home/pi 192.168.178.25/24(rw,async)

(Zwischen pi und 192 ist ein Tab, kein einfaches Leerzeichen; x.x.x.25 ist die IP des Kubunturechners, die Netzwerkmaske ist 255.255.255.255)

Dann versuche ich unter Kubuntu die Freigabe zu mounten über

sudo mount 192.168.178.23:/home/pi /media/freigabe

(der Ordner /media/freigabe existiert auch 😉 )

Nach einer ganzen Weile kommt

mount.nfs: Connection timed out

/home/pi liegt auf der SD-Karte die (glaube ich) als ext3 oder ext4 formatiert ist, aber definitiv ein "Linux-Dateisystem". Der angeschlossene USnb-Stick ist als NTFS formatiert. Der Versuch über NFS mit dem Stick endete genauso.

Über Samba klappt der Zugriff zumindest auf den Stick, das home-Verzeichnis fehlt. Greife ich über eine Windows XP-VM (Virtualbox) die eine eigene IP an der Fritzbox hat auf den Pi zu habe ich beide, Stick und home.

An dieser Stelle komme ich nicht weiter.

Friedrich

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 8030

Hast Du mal untersucht, ob die UID und GID übereinstimmen? Über diese werden nämlich die Besitz- und Zugriffsrechte zwischen Linux-Server und Linux-Client verhandelt.

Gruß - Max-Ulrich

TomTobin

Avatar von TomTobin

Anmeldungsdatum:
24. August 2007

Beiträge: 3102

Hallo Fried-rich,

nfs-common ist auf dem Client installiert?

sudo apt-get install nfs-common

Welche nfs Version läuft auf dem pi? Evtl. mal die Schalter

mount -t nfs -o vers=3,nfsvers=3 .....

probieren?

Gruß

Tom

Fried-rich

(Themenstarter)

Anmeldungsdatum:
2. Mai 2013

Beiträge: 1163

nfs-common ist auf dem Client installiert?

Ja.

Welche nfs Version läuft auf dem pi?

Müsste die aktuelle Version 4 sein, je nachdem was mit apt-get install nfs-kernel-server installiert wird. Google spuckte mir aber keine Möglichkeit aus auf dem Server die Version zu überprüfen. Unter man nfs steht nichts, nur allgemeine Angaben.

Hast Du mal untersucht, ob die UID und GID übereinstimmen

Da das in dem NFS-Artikel nicht weiter thematisiert wurde, bin ich davon ausgegangen, dass Kubuntu sowas selber einrichtet. Hier (http://wiki.ubuntuusers.de/Benutzer_und_Gruppen#Nummerierung-der-UID-GID) wird auf die /etc/login.defs verwiesen, die aber etwas unübersichtlich ist. Wie kann man denn prüfen ob die übereinstimmen? Eingerichtet hab ich sowas bisher nicht.

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 8030

Hast Du mal untersucht, ob die UID und GID übereinstimmen

Da das in dem NFS-Artikel nicht weiter thematisiert wurde, bin ich davon ausgegangen, dass Kubuntu sowas selber einrichtet

Es stimmt, das sollte dort deutlicher thematisiert werden!

Nein, Kubntu kann die UID und GID auf Server und Client leider nicht anpassen, das muss man selbst machen. NFS4 bietet auch die Möglichkeit, die UID zu maskieren, aber das kann ich leider so aus dem Stegreif nicht erklären.

Gruß - Max-Ulrich

Fried-rich

(Themenstarter)

Anmeldungsdatum:
2. Mai 2013

Beiträge: 1163

Was heißt denn dieser Punkt des NFS-Artikels?

alle Benutzer im Netzwerk eindeutige UIDs haben und

Unter Kubuntu habe ich ja logischerweise einen anderen Benutzer als auf den anderen Linuxrechnern. Muss ich ja jetzt nochmal genau die gleichen Benutzer anlegen und manuell die UIDs anpassen? Oder heißt das nur, dass "benutzer1" auf dem Kubunturechner die UID 1000, "benutzer2" auf einem anderen Linuxrechner die 1001 bekommt? Dann gäbe es keine doppelten UIDs.

alle Rechner im Netzwerk zentral administriert werden

Was heißt das?

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 8030

Dann gäbe es keine doppelten UIDs.

Ich glaube, das verstehst Du falsch. Denn doppelte UIDs sind nicht das Problem, ganz im Gegenteil!

Die Verwaltung von Besitz- und Zugriffsrechten auf einem Linux-Rechner erfolgt über UID und GID, d.h. eine Datei gehört z.B. dem Benutzer 1000 und der Gruppe 046. Die Namen sind sozusagen nur Hilfsmittel, damit man als Anwender besser klar kommt. Wenn auf dem Server z.B. nur der Benutzer 1000 Schreibzugriff auf eine Datei oder einen Ordner hat, dann gilt dies genau so auch auf dem Client, egal, wie dort der Benutzer 1000 heißt. Damit man nicht völlig durcheinander kommt, ist es empfehlenswert, dass den gleichen UIDs und GIDs auf Server und Client auch gleiche Benutzernamen entsprechen.

Wenn Du nun auf dem Server als Benutzer 1000 angemeldet bist und auf dem Client als Benutzer 1005, dann hast Du wahrscheinlich Probleme mit den Schreibrechten. Das ist gemeint mit "UIDs anpassen".

Bei NFS werden die Dateirechte grundsätzlich zwischen Server und Client übertragen. Bei Samba kann man dies optional auch deaktivieren (z.B. mit der Mount-Option nounix), und bei Windows-Rechnern ist die Übertragung von Dateirechten so gar nicht möglich, also standardmäßig nicht aktiv.

Was bei NFSv4 geht, ist dass UIDs "gemappt" werden, d.h. der UID 1000 auf dem Server entspricht dann z.B. die UID 1005 auf dem Client. Das habe ich aber noch nie verwendet, deshalb kann ich Dir nicht auswendig sagen, wie das geht.

Gruß - Max-Ulrich

Fried-rich

(Themenstarter)

Anmeldungsdatum:
2. Mai 2013

Beiträge: 1163

OK, danke für die Erklärung.

Demnach wäre es egal ob ich die UID des Servers an die UID des Clienten oder umgekehrt anpasse - Hauptsache sie sind gleich.

Bei NFS werden die Dateirechte grundsätzlich zwischen Server und Client übertragen

Dann dürfte ich doch keine Probleme mit der Verbindung haben oder was ist hier gemeint? Für liest sich das so, dass die Dateirechte die der Benutzer auf den Server hat die gleichen sind die der Benutzer auf dem Clienten hat.

Max-Ulrich_Farber

Avatar von Max-Ulrich_Farber

Anmeldungsdatum:
23. Januar 2007

Beiträge: 8030

Demnach wäre es egal ob ich die UID des Servers an die UID des Clienten oder umgekehrt anpasse - Hauptsache sie sind gleich.

Ja. Der einzige Unterschied ist evtl. der Arbeitsaufwand. Wenn Du ausschließlich NFSv4 verwendest, lohnt es sich vielleicht auch, das UID-Mapping mal anzusehen. Das ist vermutlich weniger mühsam. Samba 3 kann das leider (noch) nicht.

Dann dürfte ich doch keine Probleme mit der Verbindung haben oder was ist hier gemeint? Für liest sich das so, dass die Dateirechte die der Benutzer auf den Server hat die gleichen sind die der Benutzer auf dem Clienten hat.

Sofern die UID und nötigenfalls auch die GID auf Server und Client übereinstimmen, ja. Die Dateirechte werden ursprünglich dort festgelegt, wo sich die Dateien physikalisch befinden, also auf dem Server. Sie gelten dann auch auf den Clients und können - mit den üblichen Einschränkungen - auch von den Clients aus übers Netz verändert werden. Mit Root-Rechten übers Netz zu arbeiten ist aber sowohl in NFS als auch in Samba standardmäßig nicht möglich. Dafür bietet sich nötigenfalls dann SSH an.

Also nochmal kurz: Wenn das Anpassen der UID zu mühsam ist, dann gibt es in NFSv4 die Möglichkeit des Mapping; in Samba lässt sich die Übertragung der Rechte ganz deaktivieren. Dann werden sie quasi auf dem Client neu festgelegt ("simuliert") mit den dortigen UID; der Server erfährt davon nichts.

Gruß - Max-Ulrich

Fried-rich

(Themenstarter)

Anmeldungsdatum:
2. Mai 2013

Beiträge: 1163

Hab jetzt mal weiter versucht. Laut "id" haben die Benutzer auf Server und Client jeweils die UID und GID 1000. Daran kann es also nicht liegen.

Ich habe auch

mount -t nfs -o vers=3,nfsvers=3 .....

versucht, mit dem gleichen Ergebnis.

Fried-rich

(Themenstarter)

Anmeldungsdatum:
2. Mai 2013

Beiträge: 1163

Könnte es ein Problem mit dem portmapper sein? Wenn ich "showmount -e 192.168.178.23" am Clienten eingebe kommt

clnt_create: RPC: Port mapper failure - Unable to receive: errno 111 (Connection refused)

Ich habe die hosts.deny und hosts.allow wie in der UU-Wiki beschrieben angepasst.

edit War in der Tat der portmapper. Auf Raspbian lief kein rpcbind. Wenn ich es starte gehts.

Antworten |