Kodi kann nicht auf die NFS Verzeichnisstruktur zugreifen

    Hallo,

    ich verzweifle bald, mit meiner VU kann ich ohne weiteres auf die NFS Freigaben zugreifen, nur beim KODI sieht man zwar den freigebenen Mount, aber man kann nicht auf die Unterverzeichisse zugreifen.
    HAbt ihr hierzu eine Idee ich habe die aktuelle Kodiversion von hier in Verwendung auf meinen Google TV

    Maven's Kodi-Builds für Android

    Kannst du mal per SSH auf die VU gehen und von dort aus mal showmount -e <ip-vom-nas> ausführen? Mich würde interessieren, was dort geshared wird.

    Dann würde ich gern wissen, wie du versuchst den Share in Kodi einzurichten. Gerne mit Screenshots oder Fotos vom Handy.

    Wenn du kannst, dann auch gern mal eine SSH Verbindung zum NAS herstellen und mir dort bitte mal den Inhalt der /etc/exports zeigen.

    Wenn alle Stricke reißen, dann legen wir manuell eine "sources.xml" an und schieben die dann in den passenden Ordner. Dafür bedarf es ggf eines Dateibrowsers auf dem Google TV

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

    wenn ich mir die NFS Shares ansehe, kann ich kein Problem feststellen oder?

    NFS shares von meinen QNAP253

    Code
    [~] # cat /etc/exports
"/share/CE_CACHEDEV1_DATA/Public" *(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=de63bcab3687ac23d4ef2ad40e8f2252)
"/share/CE_CACHEDEV1_DATA/music" 192.168.10.21(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=1b8be3854baa08b44971135f482a9e1e) 192.168.10.11(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=1b8be3854baa08b44971135f482a9e1e) 192.168.20.12(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=1b8be3854baa08b44971135f482a9e1e) 192.168.10.55(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=1b8be3854baa08b44971135f482a9e1e)
"/share/CE_CACHEDEV2_DATA/music_videos" 192.168.10.11(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=313e77bbbd038b1d4025f0569f356e4f) 192.168.10.21(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=313e77bbbd038b1d4025f0569f356e4f) 192.168.10.55(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=313e77bbbd038b1d4025f0569f356e4f) 192.168.20.12(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=313e77bbbd038b1d4025f0569f356e4f)
"/share/CE_CACHEDEV1_DATA/pictures" 192.168.10.21(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=a7932f916424fffe2bc11ebacc6d9ab1) 192.168.10.11(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=a7932f916424fffe2bc11ebacc6d9ab1) 192.168.10.55(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=a7932f916424fffe2bc11ebacc6d9ab1)
"/share/CE_CACHEDEV1_DATA/series" 192.168.10.21(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=235aa825ed92d1a80de4eb51dda98349) 192.168.10.55(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=235aa825ed92d1a80de4eb51dda98349)
"/share/CE_CACHEDEV1_DATA/testnfs" 192.168.10.55(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=90ab0b51ddc2e70fecda6f3b8fd138b6)
"/share/CE_CACHEDEV2_DATA/videos" 192.168.10.21(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=aefe693b6eefa2daaf9b9c960870344e) 192.168.10.55(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=aefe693b6eefa2daaf9b9c960870344e) 192.168.20.12(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=aefe693b6eefa2daaf9b9c960870344e) 192.168.10.98(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=aefe693b6eefa2daaf9b9c960870344e)
"/share/CE_CACHEDEV2_DATA/videos_3D" 192.168.10.11(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=6469c0162137bdfa25a1ecc67ae7947e) 192.168.10.21(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=6469c0162137bdfa25a1ecc67ae7947e) 192.168.10.55(sec=sys,rw,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=6469c0162137bdfa25a1ecc67ae7947e) 192.168.20.12(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=6469c0162137bdfa25a1ecc67ae7947e)


    Der 192.168.10.98 ist der Sony.

    Was mir auch aufgefallen Ist auf meinen anderen QNAP219, sobald ich im Kodi die Struktur von NFS suche, nur suchen klicken. Dann zeigt mir Kodi den QNAP 219 an, aber danach funktioniert auf den Server keine NFS Verbindung mehr egal von welchem System. Dann muss ich immer NFS deaktivier und wieder aktivieren. Was genau macht hier KODI, warum kann es auf einen Server NFS Änderungen beeinflussen?

    mounts vom QNAP219

    Code
    "/share/HDA_DATA/Public" *(rw,async,no_subtree_check,insecure,no_root_squash)
"/share/HDA_DATA/Recordings_NAS" 192.168.10.55(rw,async,no_subtree_check,insecure,no_root_squash)

    Mounts von der VU

    Ich sehe:

    192.168.10.98(sec=sys,ro,async,wdelay,insecure,no_subtree_check,no_root_squash,fsid=aefe693b6eefa2daaf9b9c960870344e)

    Hat es einen bestimmten Grund, warum du das nur "ro" einbinden möchtest? Hast du schon mal versucht es auch "rw" einzubinden und bringt das einen Veränderung?

    Um sowas wirklich gut analysieren zu können würde ich immer erstmal mit den minimalsten Einstellungen vorgehen. Also erstmal alles erlauben und dann einschränken und dann schauen, wann es knallt.

    Zitat von doctorultra

    Was genau macht hier KODI, warum kann es auf einen Server NFS Änderungen beeinflussen?

    Kann ich dir nicht beantworten. Ich vermute, dass die Verbindung nicht sauber zu Stande kommt und das QNAP wartet bist es geklappt hat und daher andere Verbindungen blockiert? Müsste man mal in den NFS Logs oder Kernel Logs des NAS nachschauen, was da passiert. Ich würde eher den Fehler am NAS vermuten, was offensichtlich andere Verbindungen blockiert, wenn eine unsaubere Anfrage statt findet. Bin mir da aber unsicher.

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

    hatte ich auch schon probiert, es scheint so das KODI hier im Hintergrund nicht sauber den NFS mount macht, jedes andere System Linux, MAC usw. kann auf diesen NFS zugreifen.

    Komisch ist auch das nur wenn Kodi auf meinen QNAP219 greift plötzlich die NFS mounts von keinen anderen System mehr funktionieren. Das ist zwar nur ein Randthema weil ich auf den QNAP253 mounten möchte. Aber es zeigt mir, das Google TV hier sich nicht an die Standards hält. Ich nutzen einen Sony A84K.

    Weil ich komme auch nicht mit VLC drauf, da komme ich zwar weiter VLC zeigt mir die Unterverzeichnisse aber die sind alle Leer?

    Nur aus Interesse, Dein NAS kann doch auch SMB-Shares zur Verfügung stellen, und die VU kann ebenfalls mit SMB umgehen.
    So läuft es zumindest bei mir, auf dem NAS, VU und der Fritzbox.

    Die "sources.xml" könnte dann so aussehen "<path pathversion="1">smb://192.168.1.33/Videos/Serien/</path>" (natürlich dann mit der IP und dem Pfad Deiner Umgebungen).

    Zitat von DaVu

    Magst du uns die sources.xml mal zeigen? Vielleicht hast du da ja einen Fehler drin?!

    Anbei meine Sources.xml

    Beim SMB-Share fehlt das Passwort...oder ist das noch SMB1 (ich hoffe nicht)

    Ich finde es ein wenig merkwürdig, dass bei dir der Showmount-Befehl einen anderen Pfad anzeigt als der, der auch auf deinem NAS in der exports angegeben ist.

    Was ich meine ist..dein showmount zeigt: /videos
    Deine /etc/exports auf deinem NAS hat aber den Pfad: /share/CE_CACHEDEV2_DATA/videos

    Wenn ich das jetzt mal mit meinem UnRAID hier vergleiche:

    Dann siehst du, dass bei mir der showmount-Befehl den gleichen Pfad ausgibt, wie er auch bei mir auf dem NAS eingetragen ist.

    Das kann natürlich sein, dass das was QNAP-eigenes ist und die da irgendeine Magie machen, die ich aktuell nicht kenne.

    Hast du mal versucht den NFS-Share in deiner sources.xml wie folgt einzutragen:

    [tt]<path pathversion="1">nfs://192.168.10.15/share/CE_CACHEDEV2_DATA/videos</path>

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

    Bei smb wird doch das Passwort über Kodi gespeichert, auch auf den Wiki von Kodi sources.xml ist kein Passwort möglich. Mein QNAP ist auf SMBv2 eingestellt.

    Ich probiere es jetzt mal mit deinen Tipp für NFS, das ist aber normal, weil die VU erkennt ja auch die korrekten mounts, die Share/CE_CACHDEV_DATA ist intern von QNAP, aber ich probiere es mal und berichte

    Habe es hinbekommen


    Code
    192.168.10.108(sec=sys,rw,async,wdelay,insecure,no_subtree_check,all_squash,anonuid=1006,anongid=0,fsid=aefe693b6eefa2daaf9b9c960870344e)

    Aber leider nur mit all_squash und da gefällt mir tatsächlich nicht, weil jetzt eigentlich alle Benutzer Zugriff haben oder wie seht ihr das?

    Ich würde halt nicht auf "anongid 0" setzen. Das wäre die Gruppe von root ;) . anongid bzw. anonuid sollte immer explizit auf den User "anonymous" gesetzt werden. Oder halt auf einen User, der nicht root ist ;). Dort die "0" zu wählen halte ich für nicht so gut.

    Bei meinem Unraid habe ich einen User "nobody". Der hat bei mir die UID 99 und die GID 100. So steht auch mein anonuid und entsprechend mein anongid. Siehst du auch oben in meinen Screenshots.

    Auf einen NFS Share hat sowieso jeder Benutzer Zugriff. Zumindest so, wie du es eingerichtet hast. Du schränkst das ja nur mit der IP ein, die du da angibst. Und die mappt ja auf das Gerät welches anfragt.

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

    Hast du schon mal bei Google

    "Android mount nfs"

    eingegeben? ;)

    Geht schon. Brauchst halt ggf root und be Möglichkeit per SSH auf die Kiste zu kommen. Eine fstab scheint es so nicht zu geben. Aber man kann das mit Scripten lösen.

    Wertschätzung kostet nichts, aber sie ist von unschätzbarem Wert.

    Einmal editiert, zuletzt von DaVu (14. November 2022 um 08:25)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden