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:

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

Zitat von don

Wäre der Unterbereich evtl hier besser aufgehoben?
-> Netzwerk

Ja - auf jeden Fall!

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:

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

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

Zitat von monarc99

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.

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.

Zitat von monarc99

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.

Zitat von monarc99

Ja, du hast es

Endlich! Hurra! Ich hatte einen fetten Knoten im Hirn. Dank Deiner Hilfe konnte ich ihn (endlich) lösen!

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 habe unter OMV3.x immer noch ein Problem beim Mounten von NFS-Freigaben von Android aus. Zur Erinnerung meine NFS-Freigabe-Optionen:

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:

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?

Zitat von monarc99

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

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:

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

Zitat von monarc99

wie schaut denn die /etc/exports komplett aus?

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