Lies Dir mal dies durch.
Falls Kodi NFS4 als Client kann (weiß ich nicht) - kannst Du beim Einbinden in Kodi manuell /export löschen. Da Kodi aber nur diese Pfade "sieht", könnte es ein Indiz dafür sein, das die Kodi-Clients kein NFS4 können ...
Kurz: mit /export wird NFS3 unterstützt. ohne /export die NFS4. Das ist OMV-Standard.
Beiträge von KOorDInator
-
-
Habe gesehen, dass Du - @tosa1965 - OMV3.x installiert hast. Wie ist Dein Feedback - bist Du zufrieden? Falls Du es noch nicht getan hast: Als nächstes solltest Du dir dann einmal das Modul snapraid und MergerFS (union filesystem) angucken... - damit sind Deine Mediendaten zumindest gegen einen Plattenauswahl gesichert und Du greifst nur auf ein großes Volume zu.
-
OSMC User können ab heute auf Kodi 17 final updaten.
-
SMB 3 ist erst in neueren Serverversionen drinnen.
Und multipath lastet schlicht leitungen besser aus, da mehrere Verbindungen gleichzeitig aufgebaut werden. Senkt bei großen Frames die Latenz und steigert den durchsatz.
ZFS ist ein Filesystem / Festplattenverwaltungstool / noch mehr, das aus solaris stammt.a) Kann mulipath in einem kleinen Homenetzwerk (im Vergleich zu einem großen Firmennetzwerk) überhaupt mehrere Verbindungen nutzen?
b) Trifft Dein Geschwindingkeitsaussage auch für native Linux-Clients zu? (Libreelec oder auch osmc sind ja linuxbasierte Kodi-Clients, daher die Frage.) -
Frage: Gibt es zufällig ein WAMPServer OHNE MySQL? Also nur Apache + PHPMyAdmin?Und: Wenn ich FreeNAS benutze, kann ich zusatzlich dort auch MariaDB, Apache sowie PHPMyAdmin drauf installieren?
Hast Du Dir schon einmal OMV angesehen? - Das nutzen hier doch einige. (Nutze dann aber gleich die Version 3.x). Vieles ist mit der Weboberfläche installier- und konfigurierbar. "Sonderwünsche" lassen sich manuell trotzdem von Hand installieren (natürlich dann nicht über die OMV-Oberfläche konfigurierbar). Bin sehr zufrieden damit.
-
Ist der Port (8080) korrekt - oder hast Du den in der as.xls geändert?
-
-
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.deInhalte 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. -
Ja. - Bei dieser Variante muss eine fsid gesetzt sein. (Kam auch eine Fehlermeldung.)
ZitatWenn 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.
-
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
Codeexporting 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. -
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/
Codels -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
Codels -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!
-
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.3CodeExport 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.
-
In meiner Not habe noch einen anderen Thread aufgemacht - evtl. hilft ein anderer Blickwinkel.
-
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 -
Die Theorie hatte ich auch, aber gemäß OMV-Seite:
Zitat von OMVNFSv4
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 nfsv3to 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-ShareDa ich mit Kodi sowieso nur die Freigaben unter /exports sehe, sollte es eigentlich nfsv3 sein. Ich habe das unter Ubuntu 16.04 auch getestet:
Bashsudo 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.
-
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?" -
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.ZitatGemäß 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.ZitatWelche 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. -
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-LogCodeERROR: 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:CodeJan 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 habe unter OMV3.x immer noch ein Problem beim Mounten von NFS-Freigaben von Android aus. Zur Erinnerung meine NFS-Freigabe-Optionen:
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:
CodeJan 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?
-