NFS-Problem in EasyMiNT

[mfro]

... Die beiden Ataris mounten die NFS-Freigaben auch, wenn ich aber darauf zugreife, gibt es bei beiden ein "Permission denied"...

Das ist ein anderes (in diesem Fall Permission-) Problem. Wie sieht deine /etc/exports auf dem Server aus und mit welcher UID (auf der MiNT-Seite) versuchst Du, auf die NFS-Freigabe zuzugreifen?

[RealLarry]

Ich habe verschiedene Varianten ausprobiert. Die eine ist

/share 192.168.1.0/24(rw,async,no_root_squash,no_subtree_check)

eine andere (auf uid/gid 0 , also root)

/share 192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash,anonuid=0,anongid=0)

aber auch mit uid/gid 1001 , das ist der User, als auch mit fsid=1 da (je nach verwendetem Linux) sonst NFS auf Serverseite meckert und diesen Parameter erwartet. Habe aber ebenso mit sync/async und all_squash/no_root_squash in verschiedenen Kombinationen gespielt. Ergebnis war entweder: geht gar nicht (Timeout) oder im besten Fall wieder "Permission denied".

Auf Atari-/Client-Seite habe ich bislang keine IDs angegeben. War in den Dokus auch nicht angegeben, werde es aber auch noch ausprobieren.
War da nicht etwas, dass MiNT gar nur NFSv2 spricht? Denn den Linuxen untereinander ist es Wurscht, ob ich die Mounts per NFSv3 oder NFSv4 anspreche. Funktioniert immer.

[mfro]

bei mir funktioniert das:

Code: [Auswählen]

/home   falcon(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)
/home   firebee(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)
/home   m5484lite(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)
/home   m54455(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1000,anongid=1000,root_squash)

uid 1000 ist mein (normaler) Linux-User, dem das exportierte FS gehört. Hostnamen sind bei mir im DNS. exportfs -a nach jeder Änderung nicht vergessen.

[RealLarry]

Hmm, nein, will nicht. Immer noch "Permission denied". Habe dazu jetzt einfach ein neues Verzeichnis angelegt (/test), owner ist 1001:1001, permission ist 777 und Export

/test 192.168.1.0/24(rw,async,no_subtree_check,insecure,no_auth_nlm,anonuid=1001,anongid=1001,root_squash)

Die anderen Linux schlucken auch das klaglos.

Der Vollständigkeit halber sei noch erwähnt, dass ich zwei identische Netzwerkkarten nutze, auf dem TT helmut-19112017 mit ENEC3.XIF, auf dem Falcon freemint-1-19-6b9-020 mit ne2kenec.xif.
Aber auf beiden Ataris/MiNTs das selbe Problem. Auf den Falcon habe ich sowohl mount_nfs (Sparemint), als auch nfsmount.ttp probiert. Kein Unterschied.

Interessant sind halt die Aussagen des NFS-Servers

rpc.mountd[3870]: authenticated mount request from 192.168.1.79:669 for /test (/test)

und

rpc.mountd[3870]: authenticated unmount request from 192.168.1.79:671 for /test (/test)

dass es also prinzipiell funktioniert *rätsel*

exportfs -a nach jeder Änderung nicht vergessen.

Selbstverständlich

[Lukas Frank]

Ich habe solche Probleme unter macOS HighSierra nicht ...

private/etc/eports = /Users/frank/Downloads/Atari -maproot=0:0 -network 192.168.2.0 -mask 255.255.255.0

Mount am Atari über die etc/fstab = 192.168.2.114:/Users/frank/Downloads/Atari /nfs/MacPro nfs rw 0 0

[RealLarry]

...nur mal so in den Raum geworfen, da mein Problem ja vielleicht an meinem MiNT selber liegt:
MiNT liegt auf Laufwerk F: und alles relevante wurde in der mint.cnf per Symlink auf /f/ umgebogen. Das Verzeichnis /nfs aber nicht. Dessen Permissions sind 755 (testhalber auch mal auf 777 gestellt). Ist nichts dorthin gemountet, kann ich auch dorthin zugreifen. Mounte ich (erfolgreich) z.B. nach /nfs/blabla , kann ich weder auf /nfs noch /nfs/blabla zugreifen, da wieder "Permission denied).

Das MiNT ist aus den Sparemint-RPMs gebaut und funktioniert an sich ganz prima. Das einzige, was noch zu meinem orgiastischen Glück fehlt, ist das Netzwerk. Ziel soll NFS (Atari->PC) und rsync sein - dann kann ich bequem Backups machen und Daten austauschen.

[mfro]

... Mounte ich (erfolgreich) z.B. nach /nfs/blabla , kann ich weder auf /nfs noch /nfs/blabla zugreifen, da wieder "Permission denied).

Das bedeutet m.E., dass das Mounten prinzipiell funktioniert und der Fehler erst beim realen Zugriffsversuch passiert. Was steht im syslog auf der Linux-Seite?

Dass Du allerdings schon auf /nfs nicht mehr zugreifen kannst, kommt mir seltsam vor. ls -ld /nfs gibt auch schon "permission denied"?

[RealLarry]

Was steht im syslog auf der Linux-Seite?

Das ist es ja. Es gibt, wie bereits oben erwähnt, nur die erfolgreichen mount/unmount Ergebnisse im syslog. Sonst rein gar nichts dazu:

rpc.mountd[3870]: authenticated mount request from 192.168.1.79:669 for /test (/test)

und

rpc.mountd[3870]: authenticated unmount request from 192.168.1.79:671 for /test (/test)

ls -ld /nfs gibt auch schon "permission denied"?

Nein, das geht. Ausgabe ist "drwxr xr x 1 root root  0 Jan 9 2017 /nfs"
Ein ls -ld /nfs/test allerdings wieder ein "permission denied".

Ich denke, ich werde mal eine ubuntu-VM zum testen aufziehen; die meisten, die von Erfolg berichteten, hatten ein Ubuntu als NFS-Server laufen. Ich habe hier überall Arch-Linux. Vielleicht gibt es dann etwas anderes/neues zu berichten...

[Nervengift]

Hm ... irgendwie scheint das jeder ein klein wenig anders zu machen mit den NFS-Freigaben. Bei mir sieht die "exports" in Mac OS 10.5.8 so aus:

Code: [Auswählen]

/Volumes/Daten/Music -ro -mapall=nobody -alldirs -network 192.168.2.0 -mask 255.255.255.0
/Volumes/Filme/Filme -ro -mapall=nobody -alldirs -network 192.168.2.0 -mask 255.255.255.0
/Volumes/Daten/Transfer -rw -mapall=nobody -alldirs -network 192.168.2.0 -mask 255.255.255.0
Funktioniert super. Ich kann von meinem Milan aus auf die Freigaben ohne Probleme zugreifen.

...nur mal so in den Raum geworfen, da mein Problem ja vielleicht an meinem MiNT selber liegt:
MiNT liegt auf Laufwerk F: und alles relevante wurde in der mint.cnf per Symlink auf /f/ umgebogen. Das Verzeichnis /nfs aber nicht. Dessen Permissions sind 755 (testhalber auch mal auf 777 gestellt). Ist nichts dorthin gemountet, kann ich auch dorthin zugreifen. Mounte ich (erfolgreich) z.B. nach /nfs/blabla , kann ich weder auf /nfs noch /nfs/blabla zugreifen, da wieder "Permission denied).

Das MiNT ist aus den Sparemint-RPMs gebaut und funktioniert an sich ganz prima. Das einzige, was noch zu meinem orgiastischen Glück fehlt, ist das Netzwerk. Ziel soll NFS (Atari->PC) und rsync sein - dann kann ich bequem Backups machen und Daten austauschen.

Du meinst jetzt, dass "F" Deine Unix (EXT2)-Partition ist? Meines Wissens wird der "NFS"-Ordner nur auf "U" angelegt von MiNT. Umbiegungen sind da nicht nötig bzw. vielleicht sogar schädlich? Ich habe an den Zugriffsrechten des "NFS"-Ordners auch nie was geändert. Was das angeht bin ich eh ein Schisser.

Anbei mal ein Foto der Zugriffsrechte meines "NFS"-Ordners. 

[RealLarry]

Ach wie gut, dass ich noch eine ubuntu-VM herumliegen hatte. Sogar noch recht aktuell! Also flott auf den tagesaktuellen Stand gebracht, NFS dazu gepackt, Falcon angeflanscht und - was soll ich sagen: ES GEHT! Da brat mir doch einer eine Fledermaus!
Also werde ich nun anfangen zu schauen, wo denn bitteschön im Detail ein Unterschied in den NFS-Implementierungen Ubuntu/ArchLinux ist... *stöhn* Ich werde berichten

Einstweilen wieder einmal Dankeschön an alle Beteiligten für die seelische Unterstützung!

[RealLarry]

Hm ... irgendwie scheint das jeder ein klein wenig anders zu machen mit den NFS-Freigaben.

Jo, aber das sollte im Großen und Ganzen ja auch nichts ausmachen. Hauptsache, die Parameter passen in etwa an die "örtlichen Gegebenheiten".

Du meinst jetzt, dass "F" Deine Unix (EXT2)-Partition ist? Meines Wissens wird der "NFS"-Ordner nur auf "U" angelegt von MiNT.

Guter Einwand und richtig erkannt Genau so ist es.

Umbiegungen sind da nicht nötig bzw. vielleicht sogar schädlich? Ich habe an den Zugriffsrechten des "NFS"-Ordners auch nie was geändert. Was das angeht bin ich eh ein Schisser.

Ich denke auch, dass man besser nicht weiter an /nfs herumfummeln, umbiegen o.ä. sollte. Versuchshalber hatte ich dessen Permission ja auf 777 gesetzt, aber zumindest nach einem Reboot des Atari ist der Ordner von alleine wieder auf 755.

[RealLarry]

So, erste Ergebnisse:
1. Ja, MiNt nutzt (derzeit) NFSv2
2. NFSv2 ist Baustelle bei ArchLinux https://wiki.archlinux.org/index.php/NFS#NFSv2_compatibility . Per Default ist es AUS, aber ich bekomme es momentan nicht eingeschaltet.
3. Bei Debian (zumindest Stretch) ebenso, aber dort war Abhilfe einfach: https://lists.debian.org/debian-kernel/2017/07/msg00393.html

Somit ist das Thema für mich gelöst, denn solange es mit dem Debian klappt, reicht mir das sogar *freu*
Ich denke aber, dass das Thema NFSv2 bei Ubuntu kurz über lang bei einem der neueren Releases ebenfalls wieder auf den Tisch kommt, denn dann kommt ein neueres nfs-utils zum Einsatz und dann dürfte Abhilfe ebenso wie bei Debian Stretch möglich sein.

[1ST1]

Ich bin noch nicht weiter gekommen, mein Server ging am 24.12 kaputt (Elkos auf dem Mainboard) und Ersatz (ein FSC Esprimo-PC mit gleicher Typenbezeichnung und folglich identischem Board) trudelte erst am letzten Samstag wieder ein, läuft erst jetzt wieder und noch keine Zeit gehabt, die Alternativen zu testen...

[RealLarry]

Ich bin noch nicht weiter gekommen, mein Server ging am 24.12 kaputt [...]

Oh, mein Beileid! Aber wir haben ja jetzt prima Infos zusammen, so dass wir das sicherlich auch bei Dir zum laufen bekommen werden!

[1ST1]

[offtopic]
Naja der "Server" geht ja wieder, ist aber komischerweise etwas zickig, was den zusätzlichen SATA-Controller angeht, sobald da Platten dran hängen (was ja eigentlich SInn der Sache sein sollte) hängt das BIOS vor dem Booten. Mein momentaner Workarround: Die zwei SATA Platten erst anstöpseln, wenn Windows anfängt zu booten. SATA ist ja Plug&Play... Scheinbar hat das ESPRIMO-BIOS Probleme mit zusätzlichen Platten an Extra-Controllern (hab 3 verschiedene ausprobiert, ohne Platten an dem Controller bootet er). Ist aber shice, muss mir da noch was anderes einfallen lassen. Nur das neueste BIOS hat der Esprimo schon, der Alte muss ein anderes BIOS gehabt haben... (in dem Rechner sind insgesamt 5 große Platten drin, plus eine kleine Systemplatte)
[/offtopic]

[gh-baden]

Mein momentaner Workarround: Die zwei SATA Platten erst anstöpseln, wenn Windows anfängt zu booten. SATA ist ja Plug&Play...

Plug & play ist SATA schon, Hot-plug dagegen nur, wenn das explizit unterstützt wird.

[1ST1]

Keine Sorge, es klappt.

[RealLarry]

Kleiner Nachtrag: Ich war mit der Übertragungsrate unzufrieden und habe mal ein bisschen an den mount-Einstellungen geschraubt. Vorlage dafür ist http://nfs.sourceforge.net/nfs-howto/ar01s05.html
Ergebnis ist, dass die in den vielen Dokus angegebene rsize/wsize -Größe von 1024 für den Popo ist. Zumindest bei mir; vielleicht ist das aber auch der Vergangenheit geschuldet, als man noch 10- oder gar schon 100MBit hatte. Heute dürfte ja 1000MBit das Mindeste sein, was man laufen hat.

Die Werte sind wie folgt:

time dd if=/dev/zero of=/nfs/test/testfile bs=16k count=2048 # 32MB
# wsize=1024  11min17
# wsize=2048  08min36
# wsize=4096  07min20
# wsize=8192  05min29
# wsize=16384 05min51

time dd if=/nfs/test/testfile of=/dev/null bs=16k # 32MB
# rsize=1024  10min29
# rsize=2048  7min11
# rsize=4096  5min10
# rsize=8192  read fault nach ~1min
# rsize=16384 manuell abgebrochen nach 20min

Ergibt für mich also rsize=4096,wsize=8192 und damit sieht die Performance schon ganz anders aus

[1ST1]

Hast du diese Einstellung mal mit vielen kleinen Dateien lesen/schreiben verifiziert? Vor allem auch Dateien kleiner als 4 bzw. 8 k ?

[RealLarry]

Hast du diese Einstellung mal mit vielen kleinen Dateien lesen/schreiben verifiziert? Vor allem auch Dateien kleiner als 4 bzw. 8 k ?

...läuft noch Ich werde das auch noch ein-zwei Tage hin und her testen, bevor ich neuen Senf dazu abgebe.