Beiträge von KOorDInator

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

    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.

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

    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.

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

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

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

  • FHEM Verständnisfragen

    Zitat von witchking

    Ja es lag an den Porteinstellungen. Ich hatte seiner Zeit einen indiduellen Port benutzt, mit dem funktioniert es aber ganz plötzlich nicht mehr, mit dem Standartport von OSMC 8080 gehts wunderbar. Warum auch immer

    Denn kenne ich, hatte mich auch mehrere Tage gekostet ... :(
    Wenn man in der [definition='2','1']advancedsettings[/definition].xml den tcpport manuell ändert (warum ich das mal gemacht hatte, weiß ich auch nicht mehr ...), dann ist bei der Definition von einem Kodi-Device in fhem der Port einfach mit anzugeben.

    Code
    <jsonrpc>
		<compactoutput>false</compactoutput>
		<tcpport>9092</tcpport>
	</jsonrpc>
    Code
    192.168.178.21:9092 tcp

    Dann klappt auch alles wieder, wie es soll. :D

  • LibreELEC Alpha 7.90.010 mit Kodi 17 Beta 7

    Zitat von DaVu

    Gerade mal den Titan Skin installiert und ja, es stimmt. Da ist noch das OpenELEC logo sichtbar. Anscheinend hat der Skinner da seine Hausaufgaben nicht gemacht.

    Siehe:

    Da sieht man recht deutlich einen "OpenELEC" Ordner. Da der Skin auf dem Kodi-Repository liegt, hat es rein gar nichts mit LibreELEC zu tun und der Skinner sollte das ggf anpassen. Von daher ist der Bugreport hier fehl am Platz. ;)

    In der Tat benutze ich den Titan-Skin. Danke für Deine Rückmeldung! :thumbup:

  • Einplatinen Computer (Odroid, RaspBerry ...)

    Zitat von DjangoTV

    Ich hab es bei mir so gelöst, ich habe den Raspberry Pi per USB an den Fernseher angeschlossen. Müsstest einmal schauen wieviel Energie der USB-Port deines Fernseher ausgibt. Wenn ich den Fernseher anschalte geht der Rpi mit an und das gleiche auch beim Ausschalten. Ist super einfach und ich bin damit sehr zufrieden.

    Wie lange nutzt Du das bereits so? Vermutlich nicht (mehr) so lange - Deine MircoSD-Karte leidet extrem bei dieser Behandlung. (Der Pi wird so nicht sauber runter gefahren, er könnte gerade schreiben - da sollte nicht plötzlich der Strom fehlen ...)

  • KODI 17 auf Raspberry installiert und möchte nun ein apk installieren

    Zitat von Rudoif

    danke. Und da gibt es keine Möglichkeit?

    Gibt ja am FireStick wo Kodi installiert ist auch eine Möglichkeit

    Willkommen hier im Forum!

    Zu Deinem Verständnis:

    • Kodi gibt es für unterschiedliche Betriebssysteme.
    • Würdest Du versuchen ein Windowsprogramm auf ein Android- oder IOS-Smartphone zu installieren? (Ich hoffe nicht ... :D )
    • Bei Dir - das schrieb Dir @don bereits - läuft nun ein Linux und kein Android.
    • apk sind Android Programm Pakete und daher für die anderen Betriebssysteme (z.B. Windows, Linux) nicht zu gebrauchen.