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

  • Vorab - @don: Mehrere nutzen OMV als DatenServer. Ich stelle den Antrag zum Einrichten eines eigenen OMV-Unterforums, um diese Themen zu bündeln.

    Meine Konstellation:

    • OMV kürzlich von 2.x auf 3.x geupdated. (Unter OMV 2.x hatte ich KEINE Probleme). Ablage für Mediadaten und SQL-Server (MariaDB).
    • Zugriff auf Server (die Freigaben liegen dabei auf einem Snapraid) via

      • OSMC (Kodi 16.1 mit MariaDB) auf Pi2 (funktionierte unter OMV 2.x und nun auch unter OMV 3.x problemlos)
      • Libreelec (Kodi 17 div. Alphas/Betas mit lokaler DB [weil Test]) auf Odroid C2 (funktionierte unter OMV 2.x und nun KEIN Zugriff unter OMV 3.x möglich)
      • Ubuntu 16.04 (einfach nur DatenShare mounten) (funktionierte unter OMV 2.x und nun auch unter OMV 3.x problemlos)

    Hat sich das NFS-Verhalten von OMV 2.x auf 3.x verändert (, z.B. nun NFS4.x Standard, vorher nicht?)?
    Da Kodi seinen eigenen NFS-Client mitbringt - und eigene Mountoptionen nicht vorgesehen sind - möchte ich bei der Problembehebung beim Server ansetzen. (Nur der hat sich ja durch das OMV-Update auch geändert.)

    EDIT
    Die Fehlermeldung im Kodi-Log:

    Code
    ... failed with NFS3ERR_NOENT(-2)

    Beim Einrichten einer Quelle sehe ich zwar die Freigaben, aber keine darin enthaltenen Unterverzeichnisse.
    /EDIT


    Ich möchte weiterhin NFS und kein SMB/CIFS verwenden.
    Hat hier jemand OMV3.x mit NFS-Freigaben auf einem Snapraid erfolgreich mit Kodi 17 als Client am laufen?
    Meine Einstellungen im OMV:

    Hat jemand Lösungsansätze?

    (Der - funktionierende - Pi steht nicht für Tests zur Verfügung - sonst erschlägt mich meine Frau ...)

    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]

  • Hurra! Ich habe das Problem lösen können.
    Es liegt an der uid und gid (User- und Gruppen-ID).

    Der Zugriff muss bei OMV3.x unter bekannten IDs erfolgen - ansonsten wird der Zugriff verweigert. Auf OMV hatte ich einen User angelegt mit uid=gid=1000. Unter OSMC und Ubuntu ist der 1. User standardmäßig immer uid=gid=1000 - daher war und ist der Zugriff kein Problem (gewesen).
    Unter libreelec ist die uid=gid=0 (was dem root-User auch bei OMV entspricht), diesem ist standardmäßig der Zugriff auf OMV so nicht erlaubt (, das ist auch gut so, sonst könnte man als root die Konfiguration von OMV direkt manipulieren).
    Unter meinem android-Device (Marshmallow) mit Kodi ist z.B. die uid=gid=10110 - auch hier war kein Zugriff mehr möglich. da die uid und gid unter OMV3.x nicht eingerichtet waren/sind.

    Der Unterschied von OMV2.x und OMV3.x scheint darin zu liegen, dass unter OMV2.x unbekannte uid und gid auf so eine Art "Gast" gemappt worden sind, den es standardmäßig gab. Unter OMV3.x wird das so nicht mehr gehandhabt, daher die Problem.

    Man kann aber den Freigaben optional angeben, auf welche (bekannte) uid bzw. gid, die unbekannten uid und gid gemappt werden sollen: Bei mir zum Beispiel auf die bekannten - anonuid=1000 und anongid=1000.
    Die Freigabezeile unter zusätzliche Optionen in OMV sieht bei mir nun so aus:

    Code
    subtree_check,insecure,fsid=2,anonuid=1000,anongid=1000

    Nun läuft wieder alles so wie es soll. :D *puuh* - das hat mich mehrere Tage anstrengende Recherche gekostet ... ;(

    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]

  • Du könntest noch die Option all_squash hinzufügen.

    Zitat

    all_squash:
    Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting.

    Also quasi statt ",anonuid=1000,anongid=1000".
    Danke für den Tipp. Kann es sein, dass das die Standardeinstellung unter OMV2.x war?! Das würde zumindest eine Erklärung für das Verhalten sein.
    Hmm - ich überlege, ob ich unter OMV einen speziellen Kodi-User anlege. Das wäre evtl. die sauberste Lösung.

    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]

  • Eher zusätzlich zu ,anonuid=1000,anongid=1000

    NFS ist auf ein Unix Netzwerk mit zentraler Userverwaltung ausgelegt. Also netzwerkweit wird jedem User eine bestimmte UID zugewiesen und mit dieser meldet er sich überall an.
    Bei gemischten Netzwerken (mit Unix, Windows, Android) geht das nicht, weil die User auf den einzelnen Systemen irgendwelche IDs zugewiesen werden.

    Deshalb die Nötlösung mit all_squash und anonuid, um alle IDs auf eine feste ID auf dem NFS Server zu mappen, die auch Lese/Schreibrechte auf dem Server und speziell auf die Mediendateien hat.

    Ohne all_squash kann z.B. passieren, dass du z.B. einen weiteren User auf OMV anlegst '(um irgendwas zu testen).
    Dieser wird 1001 auf dem OMV Server, also eine bekannte ID, aber z.B. ohne Leserechte an deinen Mediendateien.

    Und dann erstellst du (z,B. um deiner Freudin/Frau einen Account einzurichten) auf einen Client einen neuen User. Durch Zufall auch 1001.
    Und versuchst auf die Mediendateien auf OMV mit diesen Account zuzugreifen. Er wird dir nur ein leeres Verzeichnis anzeigen.

    Der Server kennt ID 1001 und lässt dich deshalb rein, aber die Dateien gehören User 1000. Deshalb sind sie für ID 1001 unsichtbar.

    Deshalb alles auf eine feste ID mappen.

  • Erst einmal vielen Dank für Deine ausführliche Erklärung!
    ... und trotzdem habe ich sie nicht verstanden ... :(
    ... bzw. nach langer Tipperei evtl. doch! Bitte alles graue ignorieren und gleich zum blauen Text springen.

    Eher zusätzlich zu ,anonuid=1000,anongid=1000

    Zusätzlich? Das wäre nach meinem Verständnis ein Widerspruch:

    • all_squash mappt auf "anonymous"
    • anonuid=xy,anongid=xy mappt anonymous auf die Werte "xy"

    Siehe dazu auch: *klick*

    Zitat

    NFS ist auf ein Unix Netzwerk mit zentraler Userverwaltung ausgelegt. Also netzwerkweit wird jedem User eine bestimmte UID zugewiesen und mit dieser meldet er sich überall an.
    Bei gemischten Netzwerken (mit Unix, Windows, Android) geht das nicht, weil die User auf den einzelnen Systemen irgendwelche IDs zugewiesen werden.

    Ja ist mir klar: UID und GID sind über Systemgrenzen hinweg unterschiedlich. Unter osmc ist uid=1000 der user osmc; unter Ubuntu bin ich der uid=1000.

    Zitat

    Deshalb die Nötlösung mit all_squash und anonuid, um alle IDs auf eine feste ID auf dem NFS Server zu mappen, die auch Lese/Schreibrechte auf dem Server und speziell auf die Mediendateien hat.

    Dazu macht dann doch genau anonuid=1000 und anongid=1000. Wozu also noch all_squash?

    Zitat

    Ohne all_squash kann z.B. passieren, dass du z.B. einen weiteren User auf OMV anlegst '(um irgendwas zu testen).
    Dieser wird 1001 auf dem OMV Server, also eine bekannte ID, aber z.B. ohne Leserechte an deinen Mediendateien.

    Also: all_squash ordnet allen UserIDs dem Nutzer "anonymous" zu.
    anonuid=1000 und anongid=1000 setzt die anonymen User- und GruppenID explizit auf die angegebenen Werte (hier=1000)

    Das können folglich für jede Freigabe andere Werte sein - gleichbedeutend mit der Aussage, dass die IDs pro Freigabe immer auf bestimmte - explizite Werte - gesetzt werden.

    Zitat

    Und dann erstellst du (z,B. um deiner Freudin/Frau einen Account einzurichten) auf einen Client einen neuen User. Durch Zufall auch 1001.
    Und versuchst auf die Mediendateien auf OMV mit diesen Account zuzugreifen. Er wird dir nur ein leeres Verzeichnis anzeigen.

    Um bei Deinem Beispiel zu bleiben: Der Client-User mit uid=1001 greift auf die Freigabe (nur mit anonuid=1000 und anongid=1000 in den Optionen) zu.
    Nach meinem Verstädnis: Folglich erfolgt der Zugriff auf den NAS/OMV als ob er die uid=1000 hätte. Liegen die Rechte für uid=1000 auf den NAS/OMV für die Freigabe vor, hat also der Client-User mit der uid=1001 Zugriff auf die Freigabe.

    Zitat

    Der Server kennt ID 1001 und lässt dich deshalb rein, aber die Dateien gehören User 1000. Deshalb sind sie für ID 1001 unsichtbar.

    Oder meinst Du, dass nur für den Server unbekannte uid und gid gemappt werden? *klickimhirn* - Dann verstehe ich es nun; neuer Versuch:
    anonuid=1000 und anongid=1000 setzen bei, für den Server unbekannte IDs, diese auf die angegebenen Werte. Ist uid=1001 auf dem Server bekannt wird NICHT gemappt?! Ist uid=1001 auf dem Server unbekannt, wird gemappt?
    Ist all_squash gesetzt werden alle uid - ob dem Server bekannt oder nicht - auf den Wert gesetzt, den ich mit anonuid=1000 und anongid=1000 angegeben habe? Würde ich keine anonuid=1000 und anongid=1000 setzen, hängt es davon ab, ob "anonymous" Zugriffsrechte auf die Dateien in der Freigabe hat. Standardmäßig vermutlich nicht.
    Habe ich es nun gerafft?

    Zitat

    Deshalb alles auf eine feste ID mappen.

    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]

  • Oder meinst Du, dass nur für den Server unbekannte uid und gid gemappt werden? *klickimhirn* - Dann verstehe ich es nun; neuer Versuch:anonuid=1000 und anongid=1000 setzen bei, für den Server unbekannte IDs, diese auf die angegebenen Werte. Ist uid=1001 auf dem Server bekannt wird NICHT gemappt?! Ist uid=1001 auf dem Server unbekannt, wird gemappt?
    Ist all_squash gesetzt werden alle uid - ob dem Server bekannt oder nicht - auf den Wert gesetzt, den ich mit anonuid=1000 und anongid=1000 angegeben habe? Würde ich keine anonuid=1000 und anongid=1000 setzen, hängt es davon ab, ob "anonymous" Zugriffsrechte auf die Dateien in der Freigabe hat. Standardmäßig vermutlich nicht.
    Habe ich es nun gerafft?

    Ja, du hast es :)

    anonymous hat die ID -2 -> was bei 16bit die Zahl 65534 ergibt. Falls du mal dessen ID suchst.

    Allerdings kommt es beim Verhalten des NFS Servers auch drauf an, wie der Server konfiguriert ist.
    z.B. was soll der Server mit ID 0 (root) machen?

    Durchlassen (vielleicht gefährlich) oder aus Sicherheitsgründen immer mappen? Da kommt es dann drauf an, wie der NFS Server vorkonfiguriert wurde.

  • Wollt ihr dort Anleitungen sammeln?

    Ich nutze OMV seit min. 2 Jahren..

    Meine Hardware

    NAS-->: G4560, 8GB, Gigabyte DS3H- WD Red OMV 4.x (latest)| TVHeadend 4.x.x (latest) | DD CineS2 V6. (+Oscam)
    Raspi 4 --> LibreElec (latest)
    Nvidia Shield 2017

  • Mir ging es primär um Problem und -lösungen. Dazu gehören aber auch "stickys" mit Links z.B. auf Anleitungen (nach meinem Verständnis).

    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]

  • Ich habe unter OMV3.x immer noch ein Problem beim Mounten von NFS-Freigaben von Android aus. Zur Erinnerung meine NFS-Freigabe-Optionen:

    Code
    subtree_check,insecure,fsid=2,all_squash,anonuid=1000,anongid=1000

    Der Zugriff klappt von diversen Geräten:

    • Ubuntu 16.04
    • LibreElec mit Kodi 17.x beta
    • OSMC mit Kodi 16.1

    Aber NICHT mit Kodi 16.1 unter Android!

    OMV-Log sagt:

    Code
    Jan 20 10:52:15 omv-treppe rpc.mountd[1525]: authenticated mount request from 192.168.178.40:35411 for /export/kodifutter (/export/kodifutter)

    Im OMV-Log ist sonst weiter nichts zu sehen (also auch kein "refused").
    Im Kodi-Log ist nichts zu sehen (z.Z. allerdings kein höherer debug-Level eingestellt).


    Was auffällt:
    Die Freigabe selbst ist sichtbar, aber die darin enthaltenen Verzeichnisse (Spielfilme, Serien, etc.) nicht.
    Allerdings ist ein der Vergangenheit eingelesener Film in einem Unterverzeichnis aus der Freigabe startbar ...
    Unter OMV 2.x war der Zugriff kein Problem. Am Kodi-Android-Client sind keine Änderungen gemacht worden.

    Ich verstehe es einfach nicht. ?(
    Bei den NFS-Freigabe-Optionen sollte es doch eigentlich mit JEDEM Client klappen?!

    Hat da (hoffentlich) jemand noch eine Idee?

    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]

  • Hat da (hoffentlich) jemand noch eine Idee?

    Als ich das erste Mal mit dem internen NFS Client von kodi zu tun hatte, ist mir aufgefallen, dass dieser fast unbegrenzt cached.

    Wenn also der NFS Server mal falsch eingestellt war und man mit kodi einen Zugriff ausprobiert hatte, zeigt er diesen Fehler an, solange kodi lebt.
    Selbst wenn der NFS Server inzwischen richtig konfiguriert ist, kodi zeigt immer das gleiche an.

    Erst wenn man kodi komplett beendet, lädt er es neu. Unter Android laufen die Prozesse ja normalerweise im Hintergrund weiter, vielleicht reicht bei dir ein Neuboot, so dass kodi mal neu gestartet wurde.

  • Wenn also der NFS Server mal falsch eingestellt war und man mit kodi einen Zugriff ausprobiert hatte, zeigt er diesen Fehler an, solange kodi lebt.
    Selbst wenn der NFS Server inzwischen richtig konfiguriert ist, kodi zeigt immer das gleiche an.

    Hmm - kann ich so für mein Kodi 17 beta (libreelec) auf einem Odroid C2 nicht bestätigen. Als der Server endlich mit Deiner Hilfe korrekt konfiguriert war, konnte ich sofort mit Kodi auf die NFS-Freigaben zugreifen. Aber weil der Teufel ein Eichhörnchen ist, habe ich auf meinem Android (Kodi 16.1) versucht:

    • Warmstart
    • Echter kalter Neustart
    • Neue Kodiinstallation (alte vorher gelöscht)

    Leider hat nichts geholfen. Die NFS-Freigabe ist zu sehen, aber ein Zugriff auf den Inhalt ist nicht möglich.

    EDIT
    Hier scheint jemand das gleiche Problem zu haben ...

    EDIT2
    Kodi-Log

    Code
    ERROR: NFS: Failed to mount nfs share: /export (mount/mnt call failed with "RPC error: Mount failed with error MNT3ERR_ACCES(13) Permission denied(13)")


    OMV3.x (Server) Log:

    Code
    Jan 20 16:49:50 omv-treppe rpc.mountd[9383]: authenticated mount request
    from 192.168.178.40:34292 for /export/kodifutter (/export/kodifutter)
    Jan 20 16:49:51 omv-treppe rpc.mountd[9383]: refused mount request from 192.168.178.40 for /export (/export): illegal port 34296

    Allerdings soll ja /export/kodifutter/xy und nicht nur /export gemountet werden (dafür liegt auch keine separate NFS-Freigabe vor)

    EDIT3
    Habe auf verdacht die /etc/exports auf dem Server manuell manipuliert (und ein insecure bei /export hinzugefügt - diese Zeile wird eigentlich automatisch von OMV erzeugt). - Die Fehlermeldung bleibt dann zwar aus, aber es ist trotzdem kein Zugriff möglich ...

    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]

    6 Mal editiert, zuletzt von KOorDInator (20. Januar 2017 um 17:48)

  • wie schaut denn die /etc/exports komplett aus?

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


    Sie wird von OMV automatisch generiert. Konfiguration erfolgt via WEB-Zugriff:

    Da das "NFSv4 - pseudo filesystem root" in der /etc/exports automatisch mit dazu generiert wird, gibt es dafür im WEB-Zugriff keine explizite Freigabe.

    Zitat

    Ohne Fehlermeldung schwierig zu sagen. Du kannst mal es mal mit

    Code
    no_subtree_check,crossmnt

    als zusätzlichen Parameter probieren.

    Gemäß Manual kann ich statt "crossmnt" bei den Eltern auch ein "nohide" bei den Kindern nehmen; dafür habe ich mich entschieden, da ich über das WEB-Formular nur direkten Zugriff auf die Kinder habe.
    Hinweis: Habe im weiteren Testverlauf zusätzlich auch noch von "subtree_check" auf "no_subtree_check" gestellt. Beide Male kein Erfolg. :(

    Zitat

    Welche IP zeigt denn kodi in Android an?

    Die - passend zum Post weiter oben - : 192.168.178.40

    Bin echt mit meinem Latein am Ende.
    Ich frage mich wirklich, ob es irgend jemanden gibt, der von einem Android-Kodi auf eine OMV3.x NFS-Freigabe zugreifen kann (mit OMV2.x funktionierte es).

    EDIT
    Die OMV-Seite bringt (für mich) auch keine neuen Erkenntnisse.

    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 (20. Januar 2017 um 20:34)

  • Wie wurde denn die kodifutter als NFS-Quelle in den anderen funktionierenden Kodi Varianten eingetragen?

    nfs://usw...

    Und probiere den String dann in der Android Version, indem du den nfs:// String einfach eingibst und nicht per Browsen auswählst.

Jetzt mitmachen!

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