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

  • 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?"

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

  • 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?

  • 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.

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

  • 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:


    Und was exportfs -rav danach genau ausspuckt.

  • Durfte am Wochenende nicht am Server "spielen" - Vorgabe meiner Frau ... :rolleyes:
    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

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

  • Durfte am Wochenende nicht am Server "spielen" - Vorgabe meiner Frau ... :rolleyes:
    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.

  • 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?

  • 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.

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

    Einmal editiert, zuletzt von KOorDInator (24. Januar 2017 um 16:30)

  • 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/

  • 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! :thumbup:

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

    2 Mal editiert, zuletzt von KOorDInator (24. Januar 2017 um 18:06)

  • 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.

  • 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.

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

    Einmal editiert, zuletzt von KOorDInator (25. Januar 2017 um 13:13)

  • 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.

  • 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:

    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.

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

  • 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! :thumbup:


    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.

    Ich nutze: 2x Odroid C2 + 2x Aml-S912-Box (CoreELEC); Skin: Estuary Mod v2 - vielen Dank an: PvD! :thumbup:
    Info: Ich habe eine Emby-Resistenz, daher keine Infektion möglich. [bm]

    2 Mal editiert, zuletzt von KOorDInator (26. Januar 2017 um 15:41)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!