Hallo Community,
ich bin dabei ein kleines privates Netzwerk unter dem NFS-Protokoll zu installieren. Die Voraussetzungen: Als Server ein Rechner mit 3 Festplatten unter Debian Wheezy. Auf einer Festplatte ist das Betriebssystem die beiden anderen Festplatten (je 1TB) laufen im Raid 1 Verbund. md0 ist in der fstab als /raid 1 gemountet. Die /etc/expots hat folgenden Eintrag:
/raid1 192.168.1.*(rw,sync,no_sutree_check). Alternative habe ich es auch mit . 192.168.1.0 bzw. .* bzw. 192.168.1.0/255.255.255.0 und 192,168.1.0/24 versucht.
Die fstab auf einem Suse-Rechner als Client sieht so aus:
192.168.1.15:/raid1 /home/user/sonne nfs defaults 0 0.
Wobei die IP auf dem Server eine feste IP ist.
Spannend ist, wenn ich mit Yast auf dem Clienten das Verzeichnis des Servers suche findet yast das Verzeichnis /raid nicht und oh Wunder, der Eintrag in der fstab des Client verschwindet spurlos. Ich habe mehrfach, bevor ich mit Yast arbeitet nachgesehen ob der Eintrag noch da ist , er war jedes mal noch da und nach der Aktion verschwunden. Ich bin zwar keine Experte aber habe schon mehrfach ein funktionierendes -NFS -Netzwerk aufgebaut, noch nie habe ich aber erlebt, dass der Eintrag in der fstab gelöscht wurde. Kann mir da jemand bitte etwas zu sagen und mir helfen.
Mit freundlichen Grüßen und Dank
Josef
Ich kenne mich mit NFS zwar nicht aus, aber Yast ist berühmt dafür, eigenhändig gemachte Konfigurationen wieder zu überschreiben.
Daher die Frage: hast du die Konfiguration selbst eingetragen oder mit dem entsprechenden NFS-Modul von Yast?
Hallo Josef,
einige Gedanken meinerseits zu Deiner Erklärung.
– “… md0 ist in der fstab als /raid 1 gemountet …”
– “Die /etc/expots hat folgenden Eintrag:
/raid1 192.168.1.*(rw,sync,no_sutree_check)”
– “Die fstab auf einem Suse-Rechner als Client sieht so aus:
192.168.1.15:/raid1 /home/user/sonne nfs defaults 0 0.”
In Deiner ersten Angabe existiert ein Leerzeichen zwischen d von raid und der 1. In den anderen beiden Angaben existiert dieses Leerzeichen nicht. Das kann schon ein Problem sein.
Mit dem Befehl showmount -e $HOSTNAME kannst Du kontrollieren ob der Export funktioniert und welche Shares wirklich exportiert werden. Ich würde den Befehl auf dem Server aufrufen und anschließend auf dem Client. Womit ich die Info habe was vom Client aus sichtbar ist.
Da Du Yast erwähnst, liegt es nahe daß Du auf den Clients eine SuSE Distribution benutzt. Unter SuSE muß der Daemon nfs enabled sein. Dieser Dienst sorgt dafür daß beim Booten NFS Shares gemountet werden.
Was passiert eigentlich wenn Du mount /home/user/sonne ausführst? Bei existierendem Eintrag in der /etc/fstab?
MfG
Manfred
Hallo Manfred,
ich bin zwar auch nicht der NFS-Guru, aber nach meinen Unterlagen dürfen in der “/etc/exports” Rechnernamen das Jokerzeichen enthalten, IP-Adressen aber NICHT.
Möglicherweise ist YAST mal unschuldig.
Vielleicht hilft Dir das weiter.
Gruß
Roland
Hallo Manfred,
Dank für Deine Unterstützung. Im Eintrag bei md0 handelt es sich um einen Tippfehler hier, in der fstab und allen weiteren ist das schon o. k… Ich habe das zur Sicherheit noch mal kontrolliert.
Für die Kommandos mit denen ich den Export überprüfen kann bin ich sehr verbunden, werde ich gleich probieren.
Ja auf dem zunächst verwendetem Rechner läuft Suse 11.4 und ich hatte bisher nie Schwierigkeiten. tatsächlich handelt es sich hier um einen Server Austausch. Der alte Server ist bisher unter ähnlicher Konfiguration nur mit Debian 6 gelaufen. Uns zwar störungsfrei seit DEB 6.0 freigegeben wurde.
zu Deiner letzten Frage, das mounten von Hand funktioniert auch nicht.
Ich möchte noch ergänzen: Ping funktioniert in alle Richtungen, und mit dem Dateimanager “Thunar” kann ich in alle Richtungen auf die unterschiedlichen Rechner zugreifen. Ich vergaß zu melden, dass ich als Oberfläche auf allen Rechnern Xfce habe. KDE usw. sind mir zu wuchtig und verspielt. Ein weitere Rechner, unter DEB Wheezy, mit dem ich in der Zwischenzeit mein Glück versucht habe, scheitert ebenfalls.
Soweit die neuesten Erkenntnisse.
Gruß und Dank Josef
Hallo Manfred,
auf dem Server wird das freigegebene Verzeichnis erkannt und angezeigt. Auf dem Client bekomme ich Diese Antwort:
“clnt_create: RPC: Port mapper failure – Unable to receive: errno 113 (No route to host)”
Ich gehe davon aus, dass irgendwas mit dem Port mapper nicht stimmt. Meine Kenntnisse reichen leider nicht dazu aus, um dort einzugreifen.
Siehst Du da eine Möglichkeit?
danke und Gruß
Josef
Hallo Josef,
entschuldige die späte Reaktion.
Die Karnevalstage. ;-)
“clnt_create: RPC: Port mapper failure – Unable to receive: errno 113 (No route to host)”
Der Port mapper meckert also.
Zuerst einige Infos zum Portmapper. Sagen wir auf Rechner A wird ein Serverdienst bereit gestellt, z. B. ein Webserver wie Apache. Allgemein bekannt ist, dass ein Webserver den Port 80 benutzt und dieser offen ist. So kann zum Beispiel der Browser auf Rechner B bei Rechner A am Port 80 anklopfen und sagen “Gib mir mal die Webseite”.
Einige Serverdienste wie der NFS Server haben keine vordefinierten Ports ständig offen. Dafür meldet der NFS Server sich beim Portmapper an, quasi mit den Wort:”Du, ich bin da und nutze den Port XYZ”. Ein NFS Client wiederum meldet sich beim Portmapper und fragt: “Du, welchen Port benutzt der NFS Server auf Deinem Rechner?”. Der Portmapper bringt die beiden dann zusammen.
Bei Dir kommt nun die Fehlermeldung No route to host. Die ist eigentlich eindeutig. Die besagt daß Dein Client den Portmapper auf Deinem “NFS Server” nicht kontaktieren kann.
Dann stellt sich mir die Frage.
– Läuft der Portmapper auf dem NFS Server?
– Läuft die Firewall auf dem NFS Server?
– Wenn die Firewall läuft, sind die entsprechenden Ports freigegeben?
MfG
Manfred
Hallo Manfred,
kommst Du auch aus den Karnevals-Hochburgen? Mir geht das ebenso, allerdings fliehe ich immer ins Ostfriesische. Zunächst ganz herzlichen Dank. Ich hab selten eine, auch für mich als Anfänger, so gute und verständliche Erklärung bekommen. Das Problem ist allerdings in der Zwischenzeit gelöst. Was mir nach wie vor unklar ist, meinen Eintrag in der “exports” habe ich nach den Ausführungen im Kofler und bei Heike Jurzik gestaltet, siehe auch meinen ersten Beitrag. Leider ist das alles wohl für meinen speziellen Fall nicht richtig. Ich habe die “exports” dann dahingehend abgeändert, dass ich nur noch
“… *(rw,sync,no_subtree_check)” eingetragen habe. ich habe also den ganzen Kram mit den IP-Adressen weggelassen.
Irgendwie bleibt das für mich zwar etwas unbefriedigend, aber es funktioniert so.
Ich Danke Dir und allen die mich unterstützt haben nochmals herzlich.
Gruß
Josef
Hallo Josef,
es freut mich daß Du Dein Problem lösen konntest.
Ja, lebe auch in einer Karnevalshochburg. Urlaub über Karneval hab ich bisher noch hin gemacht. Dafür ist es mir um diese Jahreszeit noch zu kalt. Ich danke Dir für Dein Kompliment. Das ist quasi mein täglich Brot. Ich helfe Kunden ihre Probleme mit dem Computer zu lösen. Dabei bemüh ich mich dies so verständlich wie möglich zu machen. Wie heisst es so schön: “Hilfe zur Selbsthilfe”.
Im Laufe meines Linuxlebens habe ich gelernt Dokumentationen wie Kofler und Konsorten nur als “Anstoss”, als Einstieg zu nehmen. Die Manpages oder Dokumentationen die mit der Software kommen, sind meistens besser. Weil der, der das Programm erstellt hat, weiß – sagen wir besser, wissen sollte – wie das Programm zu handhaben ist.
Die manpage zu exports erklärt auch wieso ein Eintrag a la 192.168.178.*(…) nicht funktioniert. Die Einträge 192.168.178.0/255.255.255.0(…) oder 192.168.178.0/24(…) wären syntaktisch richtig gewesen.
Wo schlußendlich der Fehler lag, ist mit den gegebenen Informationen schwer zu erfassen.
Gruß
Manfred
Hallo,
sowohl. als auch. ich habe die Konfiguration händisch aber auch mit dem Yast-Modul eingetragen. In beiden Fällen das gleiche Ergebnis.
Dank und Gruß
Josef
Merkwürdig. Wenn die Schreibrechte für die fragliche Datei entzogen sind, kann ja eigentlich nur ein Programm mit root-Rechten da drüber schreiben.
Im Extremfall könntest du die Prozesse beobachten (lassen) und so vielleicht dem Übeltäter auf die Schliche kommen. Aber vielleicht meldet sich ja noch ein NFS-Experte.