SMB-Verbindung zum NAS: geht (nicht immer)

  • Zu dem Problem habe ich schon Unmengen an Postings hier und in anderen Foren gefunden. So eine richtige Lösung dazu scheint keiner zu haben.

    Setup
    Habe ein Pi2 mit LibreELEC 8 und Kodi 17.3.
    Habe ein NAS (QNAP-Hardware) auf dem Debian stable läuft. Alle anderen Geräte (aus dem Pi) können Problemlos auf das NAS zugreifen. Das NAS macht eigentlich nix, außer Samba laufen zu lassen.

    Problem
    Kodi meldet jedoch hin und wieder beim Zugriff auf die bereits ehemals erfolgreich(!) eingestellten Medien-Quellen (die auf dem NAS) liegen, einen "connection time out". Das passiert nicht immer, nicht reproduzierbar, ohne sicher erkennbares Muster.

    Netzwerk
    Logge ich mich per ssh auf dem Pi ein, kann ich das NAS mit Namen und IP anpingen. Nur Kodi selbst scheint es nicht zu sehen. Den Pi kann ich auch von jedem Geräte aus hier anpingen. Ping in alle Richtungen, nur Kodi bekommt keine Verbindung hin. Internetverbindung von Kodi funktioniert scheinbar auch, da ich Streams per YouTube, Filmstarts und Zattoo AddOn anschauen kann.
    Auch wenn ich das NAS vorher selbst einschalte, passiert der Fehler teilweise. Ein Neustart (soft & hard) von Kodi hilft auch nicht zuverlässig.

    Wake-on-Lan
    Zuerst dachte ich an einem Zusammenhang mit wake-on-lan. Habe daher die KODI-eigene Wake-on-Lan funktion ausgeschaltet. Hab sogar die wakeonlan.xml umbenannt (sozusagen gelöscht). Dann hab ich auch das AdvancedWakeOnLan-AddOn entfernt, um sicher zu gehen. Derzeit wecke ich das NAS mit "ether-wake MAC" in der autostart.sh selbst auf. Hab jetzt auch noch ein "sleep 10s" dahinter gehängt. Im nächsten Testschritt, lasse ich das Aufwecken mal ganz sein.

    Netbios
    Dann vielen mir die Netbios-Namen ein. Mein Samba-Server hat drei davon (wegen einem Windows-Problem). Spannenderweise konnte KODI auf die alternativen (netbios) Namen des Samba-Servers zugreifen. Der Originalname wurde in der WORKGROUP von KODI zwar angezeigt, aber beim Auswählen kam wieder connection time out.

    Kodi 18.x
    Vielleicht hilft ein Update auf Kodi 18? Kann man ein bestehendes LibreELEC 8 mit Kodi 18 betreiben? Wie würde man da vorgehen? Ein Paketmanager gibt es ja nicht. ;) Ist das empfehlenswert, oder ist die atkuelle beta-18 noch "unbrauchbar" für den täglichen Einsatz?

  • Das Protokoll.

    Dachte ich mir. Wollte nur sicher gehen, dass ich hier nichts falsch verstehe. ICh denke die Idee mit "SMB1" ist bei meiner Samba-Version hinfällig.
    Oder nutzt etwa Kodi 17 immer noch ausschließlich SMB1? Denke aber wohl ehr nicht, den es hat ja teilweise funktioniert.
    Im übrigen war ein alter Fantec-Player der nur SMB1 konnte, Grund für den Umstieg auf Pi2+Kodi.

  • jaja, diese Altlasten....

    Damit die Namensauflösung vernünftig klappt in der Umgebung, muss irgendwo im LAN ein WINS Server laufen und von den Klienten auch benutzt werden.
    Microsoft hat WINS schon lange wieder ausgemustert, aber ohne WINS beruht NetBios mit SMB1 nur auf Broadcasts, ist also etwa mit Knochenwerfen und Eingeweidelesen zu vergleichen.

    Versuch, ob Du WINS auf dem NAS aktivieren kannst, ansonsten muß ein anderer Server im LAN dafür herhalten...

    NFS ist eine sehr schlechte Idee. Umständlich zu installieren und sehr fehlerhaft im Umgang mit Windows-Dateinamen. Das ist dann meist den Teufel mit dem Beezelbub ausgetrieben, sobald man Windows Klienten dran hat.

  • Leider ja :( Und die art von Fehlern ist sehr typisch für SMB1, einfach noch nfs freigeben und dann sollte es direkt laufen.

    Das stimmt meiner Erfahrung nicht unbedingt. Habe bei mir (Ubuntu Server) nur SMB2 und 3 erlaubt und Kodi17.3 (von Ubuntu) kann trotzdem auf das Share zugreifen.

    Haupsysteme: Server: Asrock N3160ITX, Ubuntu 24.04, TvH /// DVBSky 952 /// Wohnzimmer: Nvidia Shield Pro 2019
    Nebensysteme 1: Telestar Digibit R1 mit sat-axe25 /// Wohnzimmer: Asrock N3700, Libreelec 12 /// TvH @RPI4 Server /// Gästezimmer: Corelec 2 Tanix TX3
    Nebensysteme 2: Server: Asrock N3455M, OpenMediaVault7, TvH, Telestar Digibit R1 /// 4 Clients: Coreelec S905X

  • Das stimmt meiner Erfahrung nicht unbedingt. Habe bei mir (Ubuntu Server) nur SMB2 und 3 erlaubt und Kodi17.3 (von Ubuntu) kann trotzdem auf das Share zugreifen

    ihr habt beide irgendwie recht :rolleyes:
    Kodi benutzt natürlich gar kein SMB-X, sondern verwendet das installierte Samba auf dem Rechner.
    Und das ist nun mal total unterschiedlich bei den verschiedenen OS-en.

    Deshalb kommt es nicht auf Kodi17 oder nicht, sondern auf Ubuntu oder LibreElec (oder was anderes) an.

    Trotzdem: WINS geht immer, in allen Versionen, mit allen Betriebssystemen...

  • kann trotzdem auf das Share zugreifen

    kannst du wenn du mit Kodi verbunden bist mal smbstatus eingeben und den Output posten ? Weil das wäre "neu" das es geht.
    Bzw Kodi ist auch auf Linux/Android/Mac ?- weil es geht derzeit nur von Windows.

    Kodi benutzt natürlich gar kein SMB-X, sondern verwendet das installierte Samba auf dem Rechner.

    Kodi kann aber nicht selber das Protokoll aushandeln (bzw das ist total kaputt) deswegen wird immer SMB1 genommen

    Einmal editiert, zuletzt von CvH (10. Juli 2017 um 10:50)

  • ich kann gern morgen mal den Status von Kodi (von Ubuntu) und Kodi (von WIndows) posten zusammen mit meiner smb.conf. Bin heute leider den ganzen Tag beruflich unterwegs.

    Haupsysteme: Server: Asrock N3160ITX, Ubuntu 24.04, TvH /// DVBSky 952 /// Wohnzimmer: Nvidia Shield Pro 2019
    Nebensysteme 1: Telestar Digibit R1 mit sat-axe25 /// Wohnzimmer: Asrock N3700, Libreelec 12 /// TvH @RPI4 Server /// Gästezimmer: Corelec 2 Tanix TX3
    Nebensysteme 2: Server: Asrock N3455M, OpenMediaVault7, TvH, Telestar Digibit R1 /// 4 Clients: Coreelec S905X

  • dann macht mein Wohnzimmer PC was komisches ;)

    Haupsysteme: Server: Asrock N3160ITX, Ubuntu 24.04, TvH /// DVBSky 952 /// Wohnzimmer: Nvidia Shield Pro 2019
    Nebensysteme 1: Telestar Digibit R1 mit sat-axe25 /// Wohnzimmer: Asrock N3700, Libreelec 12 /// TvH @RPI4 Server /// Gästezimmer: Corelec 2 Tanix TX3
    Nebensysteme 2: Server: Asrock N3455M, OpenMediaVault7, TvH, Telestar Digibit R1 /// 4 Clients: Coreelec S905X

  • Kodi kann aber nicht selber das Protokoll aushandeln (bzw das ist total kaputt) deswegen wird immer SMB1 genommen

    Quatsch! (Sorry!)
    SMB1 ist erforderlich, da Kodi versucht über eine Funktion der SAMBA Bibliothek, eine eigene Session mit Benutznamen/Passwort aufzubauen. Im schlimmsten Falle sogar mit Klartextübertragung.

    Ab SMB2 gibts nur noch Challenge/Response Tokens, bzw. Kerboros Autorisierung. Aber dafür braucht es eines Domänencontrollers bzw. Kerboros Servers

    Und da aktuelle Windows Versionen gar kein SMB1 mehr mitinstallieren, spricht Kodi gegen eine Wand...

    Aber nicht ablenken hier! Sein Problem hat nichts mit dem Protokolllevel an sich zu tun, bei ihm klemmt die Namensauflösung im LAN. Ganz andere Baustelle...

  • Aber nicht ablenken hier! Sein Problem hat nichts mit dem Protokolllevel an sich zu tun, bei ihm klemmt die Namensauflösung im LAN. Ganz andere Baustelle...

    ;) Sicher verstehe ich was falsch? Ich kann mit "ping" den Server per IP und auch per Namen ansprechen. Also kann ich doch davon ausgehen, dass die Namensauflösung funktioniert?

    Zu WINS: Reicht es in der smb.conf des Servers "wins support = yes" zu machen, um das Problem zu beheben? Hab von WINS echt keine Ahnung, oder was das überhaupt genau ist. ;)

  • Sicher verstehe ich was falsch? Ich kann mit "ping" den Server per IP und auch per Namen ansprechen. Also kann ich doch davon ausgehen, dass die Namensauflösung funktioniert?

    Das ist eine der großen Fallen, die Anwort ist wie bei Radio Eriwan: "Im Prinzip ja, aber..."
    Bei SMB Versionen >=2 reicht es, denn dort verwendet SMB ganz normal auch DNS mit. Leider trifft auf Version 1 das Gegenteil zu: DNS wird ignoriert, der DNS Name (für Ping) hat NICHTS mit dem Netbios Namen (für SMB) zu tun :(
    Also in Deinem Fall hilft Dir "ping" gar nicht weiter.

    Zu WINS: Reicht es in der smb.conf des Servers "wins support = yes" zu machen, um das Problem zu beheben? Hab von WINS echt keine Ahnung, oder was das überhaupt genau ist.

    WINS = Windows Name Service. Also die Windows Entsprechung von DNS (Domain Name Service).
    Du kannst "wins support=yes" setzen bei Deinem NAS, dann musst Du aber bei den Klienten auch die NAS Adresse unter WINS Server in der Netzkonfiguration hinterlegen.

    Viel einfacher und weniger fehlerträchtig ist es aber, bei kodi statt des hostnamens die IP Adresse des NAS einzugeben. Dann wird gar kein Nameservice, egal welchem Protokollevels, angesprochen und Deine Fehlermeldung kann theoretisch nicht mehr auftauchen.

    also statt //NAS/Filme sowas wie //192.168.0.44/Filme als Kodiquelle eintragen.

    ABER ACHTUNG! Das hat dann leider auch wieder einen bösen Haken! Kodi legt in seiner Datenbank (ob lokal oder bei Mysql) immer den vollen Pfad der Datei ab! Änderst Du nun den Share ab, mit Adresse statt Namen (oder umgekehrt, ist egal, eine Änderung an sich reicht schon), so findet Kodi die Daten von früher nicht mehr und Du mußt alle Filme neu einsammeln! Hast Du mehrere Klienten im LAN ist es unbedingt erforderlich, dass bei allen überall durchgängig dieselbe Syntax verwandt wird, sonst killen sie sich gegenseitig!

    Mit der Adresse wird es auf jeden Fall funktionieren, und solange Du kein grösseres Netz hast mit mehreren LANs, oder Dein NAS dauernd eine andere Adresse bekommt, ist das die einfachste und sicherste Lösung. Da kann man auch einmal komplett neu scrapen in Kauf nehmen.

  • SMB1 ist erforderlich, da Kodi versucht über eine Funktion der SAMBA Bibliothek, eine eigene Session mit Benutznamen/Passwort aufzubauen. Im schlimmsten Falle sogar mit Klartextübertragung.

    Die Lib die Kodi benutzt kann problemlos mit >SMB1 kommunizieren, aber die Aushandlung welche Version von SMB benutzt wird ist defekt so das Kodi am ende immer nur SMB1 nimmt. Der vorhanden Fix (der noch nicht gemerged ist) löst/umgeht das Problem. Dann kann auch problemlos auf Server zugegriffen werden die z.B. nur SMB3 aktiv haben.


    Sein Problem hat nichts mit dem Protokolllevel an sich zu tun, bei ihm klemmt die Namensauflösung im LAN.

    kann sein, ist aber auch ein Typisches Symptom von der SMB1 Problematik

Jetzt mitmachen!

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