Meine Filme, Serien etc. liegen dabei auf einen zentralen NAS mit Windows 10 als Betriebssystem.
Vielleicht hilft dir das weiter?
http://kodi.wiki/view/SMB/Windows#Windows_10
Meine Filme, Serien etc. liegen dabei auf einen zentralen NAS mit Windows 10 als Betriebssystem.
Vielleicht hilft dir das weiter?
http://kodi.wiki/view/SMB/Windows#Windows_10
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.
Prima - schön, dass es jetzt geht
Des Rätsels Lösung war also mergerfs.
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.
Du kannst jetzt noch das hier testen:
/etc/exports.d/kodifutter.exports mit dem Inhalt:
/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.
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/
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?
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.
Das ist nicht spielen, das ist Arbeit
Schade ... das es nicht geholfen hat.
Ich hab das nicht
Probier mal mit der 8.0 beta
https://libreelec.tv/2017/01/libreelec-krypton-v7-95-1-beta/
Zumindest unter Intel Systemen gibt es da ab 8.0 die Einstellung für limited color range
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:
ZitatAlles anzeigen# 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,all_squash,anonuid=1000,anongid=1000)
Und was exportfs -rav danach genau ausspuckt.
So ganz verstehe ich die Abkehr von 3d jedoch nicht, oder giebt es aktuell probleme mit den HZ oder Reaktionszeiten aktueller 4k Panels?
Müsste man jemanden fragen, der bei einem TV Hersteller arbeitet.
Aber es kann sein, dass es sich einfach nicht rentiert für den Hersteller. Gibt Features, die einmal entwickelt, man in jeder nächsten Hardware Generation ohne viel Aufwand wiederverwenden kann.
Und es gibt Features, die bei jeder Generation Zeit/Geld fürs Anpassen, Einstellen und Testen benötigen. Und wenn es sich dann nicht für die Firma lohnt, wandert das Feature bei einem kommerziellen Produkt häufig erst in den Premium Bereich oder wird ganz gestrichen.
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?
Schlechte Nachrichten für alle 3D Fans:
"3D-Fähigkeiten für dem Heimgebrauch haben sich nie wirklich breit in der Industrie durchgesetzt und es ist auch kein Entscheidungskriterium, wenn ein neuer Fernseher gekauft werden soll", erklärte Tim Alessi, Chef der Produktentwicklung bei LG, den Rückzug seines Unternehmens. Und auch ein Sony-Sprecher führte aus, dass man "aufgrund der aktuellen Marktentwicklung" in diesem Jahr keinen 3D-Support mehr anbieten wird.
...
Jetzt wollen sich die TV-Hersteller erst einmal auf 4K und HDR konzentrieren, um ihre Produkte anzupreisen. Sicherlich wird 3D auch irgendwann im privaten Bereich wiederkommen - aber wohl erst, wenn es perfekt funktionierende Systeme ohne Brillen gibt. Und wenn die Branche sich von dem aktuellen Fehlschlag erholt hat.
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.
die schaut denn die /etc/exports komplett aus?
Ohne Fehlermeldung schwierig zu sagen. Du kannst mal es mal mit
no_subtree_check,crossmnt
als zusätzlichen Parameter probieren.
Welche IP zeigt denn kodi in Android an?
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.
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.
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.
Du könntest noch die Option all_squash hinzufügen.
Ne weitere Möglichkeit wäre: efibootmgr
Das hat zumindest die Option
-n --bootnext XXXX Einstellen des Bootloaders der beim nächsten Neustart genutzt werden soll (XXXX = der Hexwert des Eintrags) – Dieser Eintrag überschreibt die Bootreihenfolge einmalig, nach dem nächsten Start gilt wieder die Originaleinstellung.
Also nicht grub, sondern dass man die Bootreihenfolge im UEFI Bios beeinflussen kann.