[erledigt] NFS funktioniert nicht

[GregorS]

Hallo allerseits!

Ich möchte mir den Hardware-Umzug einer Festplatte sparen und statt dessen NFS benutzen, zumindest vorübergehend. Leider bekomme ich bei mount-Versuchen immer nur
Access denied
angezeigt. In /var/log/messages und ...syslog erscheint nichts. Meine exports:

Code: Alles auswählen

# /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_subtree_check)
#
# 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/gszaktilla/dokumente/datensammlung lili.gsz.xx(ro,no_root_squash)

Mein Mount-Versuch:

Code: Alles auswählen

mount -t nfs mimi:/home/gszaktilla/dokumente/datensammlung /home/gszaktilla/dokumente/datensammlung/

Wo übersehe ich etwas?

TIA

Gregor

[jph]

Schuss ins Blaue: Der NFS-Server kann mit dem Hostnamen lili.gsz.xx nichts anfangen und weist den Mountversuch daher ab. Du kannst mount per Option -v anweisen, umfangreichere Informationen auszugeben. Im Zweifel bei Client UND Server ins Log schauen, das ggf. mit journalctl -f mitlaufen lassen.

Dass du den Mount-Versuch als root ausführst, habe ich einfach mal angenommen.

[debilian]

warum nicht das Netz statt einen hostname?

[GregorS]

Danke schon mal für Eure Antworten!

Dochdoch, lili.gsz.xx (der Neue) und mimi.gsz.xx kennen sich beim Namen. /etc/hosts sind entsprechend angepasst, ping klappt beidseitig.
Auch mit IP-Nummern in exports: Gleiches Ergebnis. Siehe:

Code: Alles auswählen

root@lili:/home/gszaktilla# mount -vvv -t nfs mimi:/home/gszaktilla/dokumente/datensammlung /home/gszaktilla/dokumente/datensammlung/
mount.nfs: timeout set for Mon Dec 19 18:48:35 2022
mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.19,clientaddr=192.168.0.20'
mount.nfs: mount(2): Permission denied
mount.nfs: access denied by server while mounting mimi:/home/gszaktilla/dokumente/datensammlung
root@lili:/home/gszaktilla# 

Gruß

Gregor

[DeletedUserReAsG]

Der nfsd sollte ein eigenes Log besitzen, oder im Verbose-Modus gestartet werden können – das mag Hinweise auf das Problem zutage fördern können. Mein Schuss in Blaue: der User, unter dem der nfsd läuft, hat keine ausreichenden Rechte für das Verzeichnis.

Teil-OT: derlei Sachen macht man heute meist mit sshfs – weil’s erheblich einfacher zu handhaben ist. Wenn es also keinen zwingenden Grund für NFS gibt, wäre das vielleicht einen Blick wert?

[GregorS]

Teil-OT: derlei Sachen macht man heute meist mit sshfs – weil’s erheblich einfacher zu handhaben ist. Wenn es also keinen zwingenden Grund für NFS gibt, wäre das vielleicht einen Blick wert?

Den Blick ist es auf jeden Fall wert, danke für den Hinweis. Problem könnte allerdings sein, dass der „Secure-Teil“ Rechenzeit frisst und in meinem Fall vollkommen überflüssig ist. Es geht wie gesagt um einen „Umzug“, der schrittweise vonstatten gehen soll.
Gruß

Gregor

[jph]

Code: Alles auswählen

mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.19,clientaddr=192.168.0.20'

Das sieht fast so aus, als würde der Client es mit NFS 4.2 versuchen, dieses fehlschlagen und der Client danach aufgeben. Was merkwürdig erscheint, weil der Client ohne explizite Vorgabe die Versionen „von oben herab“ durchprobieren sollte.

Folgende Ideen:

• Versuche, die /etc/exports NFSv4-konform anzupassen. (Was generell empfehlenswert ist, solltest du vorhaben, NFS dauerhaft zu nutzen.)
• Gib beim Mount explizit eine NFS-Version kleiner 4 an (Parameter nfsvers).

[oln]

Teil-OT: derlei Sachen macht man heute meist mit sshfs – weil’s erheblich einfacher zu handhaben ist. Wenn es also keinen zwingenden Grund für NFS gibt, wäre das vielleicht einen Blick wert?

Leider wird sshfs nicht weiterentwickelt. Daher würde ich nicht darauf setzen.

[tijuca]

Aha, nur weil etwas nicht mehr aktiv weiter entwickelt wird heißt das nicht automatisch, dass es unbrauchbar ist.
Die großen Entwicklungen gab es schon seit Jahren nicht mehr bei SSHFS, könnte daran liegen, dass es faktisch feature complete ist.

[oln]

Die großen Entwicklungen gab es schon seit Jahren nicht mehr bei SSHFS, könnte daran liegen, dass es faktisch feature complete ist.

Aha, wenn nicht einmal mehr Bugfixes durchgeführt werden ist es für dich "feature complete" und sicher?

[DeletedUserReAsG]

Leider wird sshfs nicht weiterentwickelt. Daher würde ich nicht darauf setzen.

Es funktioniert, und das völlig problemlos OOTB. Und solange sich auf der FUSE-, oder auf der SSH-Seite nichts ändert, wird das auch so bleiben. Der TE hat angedeutet, dass ihn das „secure“ in „sshfs” eher noch stört, als dass es ihm wichtig wäre – und was die Transportsicherheit angeht, ist das in diesem Kontext sowieso Job von openssh-client. Der wird aber sehr wohl weiterentwickelt.

Vielleicht möchtest du ja noch einen tatsächlich nachvollziehbaren Grund anführen, warum man es Stand jetzt nicht zur Migration hernehmen sollte? „Versionsnummer zählt nicht mehr hoch” ist zumindest im vorliegenden Szenario nicht wirklich von Belang.

[GregorS]

Code: Alles auswählen

mount.nfs: trying text-based options 'vers=4.2,addr=192.168.0.19,clientaddr=192.168.0.20'

Das sieht fast so aus, als würde der Client es mit NFS 4.2 versuchen, dieses fehlschlagen und der Client danach aufgeben. Was merkwürdig erscheint, weil der Client ohne explizite Vorgabe die Versionen „von oben herab“ durchprobieren sollte.

Folgende Ideen:

• Versuche, die /etc/exports NFSv4-konform anzupassen. (Was generell empfehlenswert ist, solltest du vorhaben, NFS dauerhaft zu nutzen.)
• Gib beim Mount explizit eine NFS-Version kleiner 4 an (Parameter nfsvers).

Für die NFSv4-konforme Anpasssung benötige ich Hilfe. Die Beispiele

Code: Alles auswählen

# 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)

sind unklar. Was bedeuten die Client-Angaben „gss/krb5“? IP-Nummern oder Namen scheinen hier nicht gefragt zu sein.

Zum zweiten Vorschlag:Wie/wo kann ich das angeben? Den genannten Parameter kann ich unter „mount --help“ nicht finden.

Gruß

Gregor

[tijuca]

Aha, wenn nicht einmal mehr Bugfixes durchgeführt werden ist es für dich "feature complete" und sicher?

Ich habe seit Jahren keine Probleme mit diesem Tool, insofern kann ich hier keine Kritik anführen. Oder fehlt Dir ein Feature? Der Debian Bugtracker hat insgesamt 41 Bug Reports gelistet, ist da einer dabei der bei DIR ernsthafte Auswirkungen hat? Selbst auf meinen älteren armv5 basierten Geräten funktioniert sshfs ohne erkennbare Leistungseinbusen, der begrenzende Faktor ist an sich immer das Netzwerk wenn es denn mal das lokale Netz verlässt. sshfs funktioniert deutlich schmerzfreier wie NFS.

[MSfree]

Selbst auf meinen älteren armv5 basierten Geräten funktioniert sshfs ohne erkennbare Leistungseinbusen

Aber nur, wenn die CPU AES in Hardware kann. Bei meinem alten Core2-Quad bekomme ich kaum mehr als 25MByte/s über das GBit-Netz. Das unverschlüsselte NFS kommt problemlos auf 110MByte/s.

sshfs funktioniert deutlich schmerzfreier wie NFS.

Das würde ich nicht unterschreiben.Mein letzter selbstinduzierter Schuß in den Fuß war, daß weder NFS noch sshfs funktioneirt haben.

Letzten Endes lag es an /etc/hosts, in der der Hostname auf 127.0.1.1 gezeigt hat. Durch löschen des Eintrags konnte DNS dann seinen Dienst tun und NFS hat völlig reibungslos funktioniert. sshfs hat übrigens auch nicht funktioniert, aus dem selben Grund.

[jph]

Was bedeuten die Client-Angaben „gss/krb5“? IP-Nummern oder Namen scheinen hier nicht gefragt zu sein.

gss/krb5 bedeutet Authentifizierung via Kerberos, dann sind IP-Adressen irrelevant. Wenn du NFS nur vorübergehend verwenden willst, dann ist Kerberos wahrscheinlich Overkill. Schau mal unter „sec=“ in die man exports.

Falls du NFS dauerhaft verwenden möchtest und ein paar Maschinen/Dienste mehr hast, dann ist Kerberos ganz interessant, denn darüber lässt sich auch ssh, Postgres usw. abwickeln.

Letzten Endes lag es an /etc/hosts, in der der Hostname auf 127.0.1.1 gezeigt hat. Durch löschen des Eintrags konnte DNS dann seinen Dienst tun und NFS hat völlig reibungslos funktioniert. sshfs hat übrigens auch nicht funktioniert, aus dem selben Grund.

Bei einem Server sollte der eigene Hostname und der eigene FQDN auf die eigene statische IP zeigen, am einfachsten per Eintrag in der /etc/hosts. 127.0.1.1 kann dann weg:

Code: Alles auswählen

jan@t460s:~$ ssh proliant.fritz.box 'cat /etc/hosts'
127.0.0.1	localhost
192.168.10.8	proliant.fritz.box proliant

Zum Vergleich der Laptop, auf dem ich gerade tippe:

Code: Alles auswählen

jan@t460s:~$ cat /etc/hosts
127.0.0.1	localhost
127.0.1.1	t460s.fritz.box t460s

[GregorS]

Vielen Dank für die Antworten!

Das Thema hat sich inzwischen erledigt: Ich habe meine ehem. Backup-Platte umfunktioniert und angeschlossen und mounte jetzt direkt. Jetzt muss ich mir halt ein neues Backup-Medium zulegen.

Gruß

Gregor