OMV 3.x mit snapraid und NFS - Probleme mit verschiedenen Clients

KOorDInator

Schon getestet:
Die Eingabe ist ohne Fehlermeldung möglich. Jedoch wird beim Aktualisieren der (korrekt eingetragenen) Quelle nichts gefunden. Bei einer Quelle - die noch unter OMV2.x mit Erfolg eingelesen wurde - konnte ich interessanter Weise die Videos abspielen. Ein Neueinlesen versagte aber auch hier: "Datei nicht mehr vorhanden ... - soll gelöscht werden?"

monarc99

Das Problem wird sein, dass mit OMV3 auf NFS4 umgestellt wurde und die libnfs, die kodi verwendet, von nfs4 keine bzw. wenig Ahnung hat. Sondern er wie bei nfs3 drauf zu greifen möchte.
Also wir nen nfs3 Client mit einem NFS4 Server verheiraten wollen.

Da es mit anderen kodis geht, aber unter Android nicht, gibts jetzt 2 Dinge, die mir einfallen.
Entweder ist die libnfs im Android Port älter und macht Probleme.
Oder ein Rechte Problem. Von Android greift er sicherlich mit irgendeiner ID auf OMV zu, die es auf dem Server nicht gibt.

Und beim pseudo root vom nfs4, ist folgendes eingestellt:

Zitat

# NFSv4 - pseudo filesystem root
/export 192.168.178.0/24(ro,fsid=0,root_squash,no_subtree_check,hide)

und das android kodi wird auf anonymous gemappt. Und anonymous darf /export (lokale Dateirechte) vielleicht nicht lesen?

KOorDInator

Die Theorie hatte ich auch, aber gemäß OMV-Seite:

Zitat von OMV

NFSv4
The Kernel supports the following nfs versions +2 +3 +4 +4.1 you can check with cat /proc/fs/nfsd/versions
By default we mount in clients the following way
mount 10.10.10.12:/export/NFS-Share /mnt/NFS-Share This will mount using nfsv3
to mount in NFSv4 we have remove the export path so in any linux client would be
mount 10.10.10.12:/NFS-Share /mnt/NFS-Share

Da ich mit Kodi sowieso nur die Freigaben unter /exports sehe, sollte es eigentlich nfsv3 sein. Ich habe das unter Ubuntu 16.04 auch getestet:

Bash

sudo mount -t nfs
[sudo] Passwort für xxx:
192.168.178.3:/export/kodifutter on /mnt/kodifutter type nfs (rw,nosuid,nodev,noexec,noatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.178.3,mountvers=3,mountport=40083,mountproto=udp,local_lock=none,addr=192.168.178.3,user)

Korrekterweise wird mountvers=3 ausgegeben.

Könnte es am mount-Protokoll liegen? Wüßte aber nicht, wie ich das unter Kodi ändern könnte.

monarc99

Zitat von KOorDInator

Könnte es am mount-Protokoll liegen? Wüßte aber nicht, wie ich das unter Kodi ändern könnte.

Ne, wie man das unter Kodi ändern könnte, ist mir nicht bekannt.

Am mount-Protokoll liegt es vermutlich nicht, weil ja alle kodi sich per nfs3 connecten. Wenn müssten alle nicht gehen.
Leider weiss ich nicht, wie genau der Ablauf ist, wenn ein nfs3 Client auf einen nfs4 Server zugreift.

Aber kannst du mal probieren, was passiert, wenn du die /etc/exports so änderst:

Zitat

# This configuration file is auto-generated.
# WARNING: Do not edit this file, your changes will be lost.
#
# /etc/exports: the access control list for filesystems which may be exported
# to NFS clients. See exports(5).
/export/kodifutterX 192.168.178.0/24(fsid=1,rw,subtree_check,insecure,fsid=3,all_squash,anonuid=1000,anongid=1000,nohide)
/export/kodifutter 192.168.178.0/24(fsid=2,rw,subtree_check,insecure,fsid=2,all_squash,anonuid=1000,anongid=1000,nohide)
/export/ISOs 192.168.178.0/24(fsid=3,rw,subtree_check,secure)
# NFSv4 - pseudo filesystem root
/export 192.168.178.0/24(ro,fsid=0,root_squash,no_subtree_check,hide,all_squash,anonuid=1000,anongid=1000)

Alles anzeigen

Und was exportfs -rav danach genau ausspuckt.

KOorDInator

Durfte am Wochenende nicht am Server "spielen" - Vorgabe meiner Frau ...
Also - wie vorgeschlagen die /etc/exports manuell manipuliert und Server neu gestartet; Ausgabe von exportfs -rav hat sich nicht unterschieden. Kodi-Test war auch nicht erfolgreich. Obwohl ich gern eine Lösung gehabt hätte, bin ich froh, dass zumindest die Logik nicht in ihren Grundfesten erschüttert wurde: NFSv4 Änderungen sollten keine Einfluss auf NFSv3 haben.
exportfs -rav
exporting 192.168.178.0/24:/export
exporting 192.168.178.0/24:/export/ISOs
exporting 192.168.178.0/24:/export/kodifutter
exporting 192.168.178.0/24:/export/kodifutterX

monarc99

Zitat von KOorDInator

Durfte am Wochenende nicht am Server "spielen" - Vorgabe meiner Frau ...
Also - wie vorgeschlagen die /etc/exports manuell manipuliert und Server neu gestartet; Ausgabe von exportfs -rav hat sich nicht unterschieden. Kodi-Test war auch nicht erfolgreich. Obwohl ich gern eine Lösung gehabt hätte, bin ich froh, dass zumindest die Logik nicht in ihren Grundfesten erschüttert wurde: NFSv4 Änderungen sollten keine Einfluss auf NFSv3 haben.

Das ist nicht spielen, das ist Arbeit

Schade ... das es nicht geholfen hat.

KOorDInator

In meiner Not habe noch einen anderen Thread aufgemacht - evtl. hilft ein anderer Blickwinkel.

monarc99

Zitat von KOorDInator

Obwohl ich gern eine Lösung gehabt hätte, bin ich froh, dass zumindest die Logik nicht in ihren Grundfesten erschüttert wurde: NFSv4 Änderungen sollten keine Einfluss auf NFSv3 haben.

Wenn OMV3 es klassisch macht, sind die kodifutter Verzeichnisse nur per mount bind ins /export gemountet. Und liegen eigentlich woanders auf der Platte?

KOorDInator

Zitat von monarc99

Wenn OMV3 es klassisch macht, sind die kodifutter Verzeichnisse nur per mount bind ins /export gemountet. Und liegen eigentlich woanders auf der Platte?

Ja - unter
/media/uuid/mediadaten/kodifutter
/etc/fstab:

Code

/media/uuid/mediadaten/kodifutterX/ /export/kodifutterX none bind 0 0
/media/uuid/mediadaten/kodifutter/ /export/kodifutter none bind 0 0

Aber die sehe ich nicht beim Verbinden:
showmount -e 192.168.178.3

Code

Export list for 192.168.178.3:
/export             192.168.178.0/24
/export/ISOs        192.168.178.0/24
/export/kodifutter  192.168.178.0/24
/export/kodifutterX 192.168.178.0/24

Hinweis: Die uuid ist ein mergerfs-Dateisystem auf einem snapraid.

monarc99

Ja, ok ... so wie es sein soll.

Worauf ich hinaus will, wir können höchstens noch ne ganz klassiche nfs3 export probieren. Wenn das auch nicht geht, hat nfs4 definitiv nix damit zu tun.
(als Folge würde ich dann vielleicht ein Bugreport bei OMV machen, weil es dann eher nach Bug als nach falsch konfiguriert aussieht)

Was gibt denn das aus (möchte nur die ids vom Verzeichnis und Dateien sehen):

ls -anl /media/uuid/mediadaten/kodifutter/

KOorDInator

Zitat von monarc99

Ja, ok ... so wie es sein soll.
Worauf ich hinaus will, wir können höchstens noch ne ganz klassiche nfs3 export probieren. Wenn das auch nicht geht, hat nfs4 definitiv nix damit zu tun.
(als Folge würde ich dann vielleicht ein Bugreport bei OMV machen, weil es dann eher nach Bug als nach falsch konfiguriert aussieht)
Was gibt denn das aus (möchte nur die ids vom Verzeichnis und Dateien sehen):
ls -anl /media/uuid/mediadaten/kodifutter/

Code

ls -anl /media/uuid/mediadaten/
insgesamt 20
drwx------   4 1000   0 4096 Jun  4  2015 .
drwxr-xr-x   4    0   0 4096 Jan 22 08:52 ..
drwxrwsrwx+ 20 1000 100 4096 Nov  8 18:08 kodifutter
drwxrwsrwx+  3 1000 100 4096 Jun 15  2015 kodifutterX

Code

ls -anl /media/uuid/mediadaten/kodifutter/
insgesamt 236
drwxrwsrwx+   20 1000 100  4096 Nov  8 18:08 .
drwx------     4 1000   0  4096 Jun  4  2015 ..
...
drwsrwsrwx+ 1226 1000 100 73728 Jan 23 16:49 Spielfilme
...

Hinweis: uid=1000 ist in der gid=100

@monarc99: Übrigens vielen Dank für Dein Engagement!

monarc99

Du kannst jetzt noch das hier testen:

/etc/exports.d/kodifutter.exports mit dem Inhalt:

Bash

/media/uuid/mediadaten/kodifutter 192.168.178.0/24(rw,async,no_subtree_check,crossmnt,all_squash,anonuid=1000,anongid=100,insecure)

Und dann -> exportfs -rav

Also kodifutter mal außerhalb der nfs4 /export pseudo Dateisystem freigeben und dann mit den Clients testen, ob es einen Unterschied macht. Die Freigabe ist dann nicht anders als noch unter omv2.
Wenn es dann nicht geht, würde ich bei OMV fragen.

KOorDInator

Habe getestet:

musste Verzeichnis /etc/exports.d anlegen
danach Datei /etc/exports.d/kodifutter.exports mit "Deinem" Inhalt erstellt (musste noch fsid=2 ergänzen)

Ausgabe von:exportfs -rav

Code

exporting 192.168.178.0/24:/media/uuid/mediadaten/kodifutter
exporting 192.168.178.0/24:/export
exporting 192.168.178.0/24:/export/ISOs
exporting 192.168.178.0/24:/export/kodifutter
exporting 192.168.178.0/24:/export/kodifutterX

Aufruf Freigabe mit Android-Kodi 16.1:
Freigabe sichtbar, aber KEINE Inhalte.
Aufruf Freigabe mit non-Android-Kodi:
Freigabe sichtbar, Inhalte sichtbar.

Daher: Du vermutest einen Bug?!

EDIT
Problem ist nun auch direkt bei openmediavault gepostet.

monarc99

Zitat von KOorDInator

Habe getestet:
musste Verzeichnis /etc/exports.d anlegen
danach Datei /etc/exports.d/kodifutter.exports mit "Deinem" Inhalt erstellt (musste noch fsid=2 ergänzen)

fsid wegen dem mergerfs?

Wenn du fsid benutzen willst, musst du ne eindeutige ID nehmen. Und die 2 ist bestimmt schon vergeben.
Nummeriere mal alle fsid durch, so dass keine Nummer doppelt ist.

KOorDInator

Zitat von monarc99

Ja. - Bei dieser Variante muss eine fsid gesetzt sein. (Kam auch eine Fehlermeldung.)

Zitat

Wenn du fsid benutzen willst, musst du ne eindeutige ID nehmen. Und die 2 ist bestimmt schon vergeben.
Nummeriere mal alle fsid durch, so dass keine Nummer doppelt ist.

Sie ist eindeutig, hatte sie im normalen OMV3.x-Betrieb rausgeschmissen. War eine neue Erkenntnis, dass das unter OMV3.x geht. Zudem aktualisierte gerade heute OMV ihren NFS-Hinweistext:

Zitat von OMV

Pooling filesystems (AUFS, MHDFS and MergerFS)
Since this type filesystems don't have a uuid, you need to add fsid=1 or fsid=anynumber to the nfs extra options, make sure the number is not 0 and unique in case you're exporting multiple pools. You also need to add the crossmnt option for mergerfs.
openmediavault 3.0 now generates a unique fsid per exported folder by default so you don't need to add it manually.

KOorDInator

Inspiriert durch Deine "Simulation" von OMV2.x, kam mir noch ein anderer Gedanke:

Statt des bpo-Kernels habe ich nun den Standard-Kernel (also quasi den bpo-Kernel von OMV2.x) in OMV3.x genommen. Und siehe da - nun funktioniert es wie es soll!

Meine Frau wird froh sein - guckt sie doch öfter auf ihrem Smartphone via Kodi etwas aus unserer "Mediathek".

Externer Inhalt www.technikaffe.de

Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

Noch einmal vielen Dank an Dich @monarc99!

EDIT:
Das openmediavault-Forum hat auch eine Lösung mit bpo-Kernel gefunden:
Bei Nutzung von MergerFS muss zusätzlich die Option use_ino gesetzt werden, dann klappt es auch mit dem bpo-Kernel!
Siehe dazu auch hier.

monarc99

Zitat von KOorDInator

EDIT:
Das openmediavault-Forum hat auch eine Lösung mit bpo-Kernel gefunden:
Bei Nutzung von MergerFS muss zusätzlich die Option use_ino gesetzt werden, dann klappt es auch mit dem bpo-Kernel!
Siehe dazu auch hier.

Prima - schön, dass es jetzt geht

Des Rätsels Lösung war also mergerfs.

KOorDInator

Zitat von monarc99

Des Rätsels Lösung war also mergerfs.

Korrekt! - Hätte ich so nicht vermutet.

OMV 3.x mit snapraid und NFS - Probleme mit verschiedenen Clients

Jetzt mitmachen!

Benutzer online in diesem Thema