[Erledigt] VTi >= 13 unterstützt SMB >=2

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Der Mount ist testweise über den Freigabemanager angelegt per Fernbedienung mit option rw,vers=3.02

    smb1 ist abgedreht am NAS

    das wird dann ausgehandelt:
    Ausgabe von mount auf der console der solo4k:

    //192.168.11.29/movie on /media/net/movie type cifs (rw,relatime,vers=3.02,sec=ntlmssp,cache=strict,username=admin,domain=DISKSTATION,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.11.29,file_mode=0755,dir_mode=0755,iocharset=utf8,nounix,serverino,rsize=8192,wsize=8192,actimeo=1)

    wir reden vom samba-client im Kernel 3.14 des VTi nicht vom samba server auf der solo4k

    Ergänzung zu oben:

    Drehe ich SMB3 auf dem NAS ab kommt kein mount zustande.
    Es findet also kein fallback auf SMB 2 oder 2.1 statt wenn der mount mit der option vers=3.02 versehen ist.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von flotzi ()

  • Nur damit ich es nicht (wieder) falsch verstehe:
    • Der Samba-Client auf der VU+-Box kann SMB 3.0.2 ?
    • Der Samba-Server kann dagegen nur 2.0 ?
    Ist das korrekt?

    Wie kann ich auf der VU+-Box überprüfen welche SMB-Version der Client für eine Verbindung zu einem Server nutzt?

    Gruß,
    Stefan

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Teddybär ()

  • jetzt zum samba server 3.6.25 der VU+ (Stand 13.0.1)

    ohne eine Angabe in der smb.conf zu min oder max protocol.
    Hier der mount zur Solo4k vom mac aus gesehen ohne Angabe von Parametern direkt über den Finder:

    auf der mac console: smbutil statshares -a

    rootfs
    SERVER_NAME VUSOLO4K._smb._tcp.local
    USER_ID 501
    SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
    SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
    SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
    SMB_VERSION SMB_2.002
    SMB_SHARE_TYPE DISK
    SIGNING_SUPPORTED TRUE
    EXTENDED_SECURITY_SUPPORTED TRUE
    LARGE_FILE_SUPPORTED TRUE
    FILE_IDS_SUPPORTED TRUE
    DFS_SUPPORTED TRUE


    Also zusammengefasst:
    Der Samba-Client kann sich mit SMB1, 2, 2.1, 3 und 3.02 verbinden. 3.11 geht nicht.

    Aber er kann es nicht aushandeln (anders als dokumentiert), sondern nur stur die per vers= angegebene Version, oder wenn vers= fehlt SMB1.

    Der Samba-Server des VTi (3.6.25) kann nur SMB2 und 1
    erst ab Version 4.1 geht SMB3 siehe hier: Samba (software) - Wikipedia

    Zeigt auch der mac oben sehr schön. Er signalisiert ich kann 1, 2 und 3 und der mount wird dann ein 2.002 mit der Solo4k

    @Teddybär

    auf die console mit telnet oder ssh und mount eingeben dann spuckt er es aus (siehe post oben)

    oder im VTi Panal - Dateisysteme anzeigen
  • Danke für die Antwort. Leider geht das mit dem mount bei mir nicht, da kommt nur folgendes:

    Quellcode

    1. root@vusolo2:~# mount
    2. rootfs on / type rootfs (rw)
    3. ubi0:rootfs on / type ubifs (rw,sync,relatime)
    4. devtmpfs on /dev type devtmpfs (rw,relatime,size=286340k,nr_inodes=71585,mode=755)
    5. proc on /proc type proc (rw,relatime)
    6. sysfs on /sys type sysfs (rw,relatime)
    7. tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
    8. tmpfs on /var/volatile type tmpfs (rw,relatime)
    9. devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
    10. /etc/auto.hotplug on /autofs type autofs (rw,relatime,fd=5,pgrp=455,timeout=5,minproto=5,maxproto=5,indirect)
    11. /etc/auto.network_vti on /media/net/autonet type autofs (rw,relatime,fd=16,pgrp=455,timeout=5,minproto=5,maxproto=5,indirect)
    12. root@vusolo2:~#
    Alles anzeigen
    Gibt es noch eine andere Möglichkeit?

    Danke und Gruß,
    Stefan
  • Hi,

    aus gegebenem Anlass - ich hab' auf einem PC testweise Win10 installiert, daraufhin meinen Linux-Server nicht mehr gesehen und deswegen einige Zeit verbraten - bin ich auf die Samba-Versionsproblematik gestoßen: Artikel hierzu. Jetzt hab' ich mich damit beschäftigt testweise SMBv1 still zu legen - und eine höhere Version zum Laufen zu kriegen.

    Ich hab' durch die Einträge

    Quellcode

    1. min protocol = SMB2
    2. max protocol = SMB3
    in die smb.conf meines Linux-Servers (Debian 9) Samba 4.5.16 gezwungen auf SMBv1 zu verzichten - und dann geschaut, was das auf unsere VU+-Boxen für Auswirkungen hat. Habe festgestellt, dass
    1. das direkte Editieren der /etc/auto.network_vti nicht zielführend ist - man muss den Eintrag 'rw,vers=x.xx' im VTI-GUI mit der Fernbedienung in der Freigaben-Verwaltung machen.
    2. Mit 'rw,vers=2.1' und 'rw,vers=3.02' hatte ich Erfolg.
    3. Die Problematik, die schon 2017 in einer früheren VTI-Version festgestellt wurde...

    flotzi schrieb:

    Aber er kann es nicht aushandeln (anders als dokumentiert), sondern nur stur die per vers= angegebene Version, ...
    ... besteht anscheinend noch immer: man muss den Parameter mitgeben, aushandeln funktioniert noch immer nicht. *)

    Dies zur Info, falls sich jemand damit beschäftigen möchte.

    Ich lass' es jetzt mal so (v 3.02) und schau', ob noch irgendwelche Haken & Ösen auftauchen.

    LG


    *) VTI 14.06
    2 x Duo4k, Solo4k; Duo4kSE in der FeWo; (2 x Duo & Solo2 ausgemustert)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Zenturio () aus folgendem Grund: Version ergänzt

  • /etc/auto.network_vti darf man nicht editieren, stattdessen aber /etc/enigma2/automounts.xml

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von hgdo ()

  • Ach was, die ersten Zeilen

    ##################################################################
    # DO NOT TOUCH THIS FILE - THE FILE IS CREATED AUTOMATICALLY !!! #
    ##################################################################

    in der Datei stehen da doch nur zum Spaß :wall1:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Teddybär ()

  • Naja, in auto.network steht auch

    Quellcode

    1. # automatically generated by enigma 2
    2. # do NOT change manually!
    Trotzdem wurde die Datei jahrlang manuell editiert und für Freigaben verwendet, bevor es "autfos" auch im Freigabe-Editor gab.
    Viele machen das immer noch so.

    Bei auto.network_vti funktioniert es aber nicht.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von hgdo ()

  • Ob die auto.network_vti manuell editiert werden soll / darf / nicht darf ist ja nicht das Wesentliche meines obigen Postings :
    • Ich wollte lediglich die Problematik eines weitgehend obsoleten und anscheinend unsicheren Netzwerkprotokolls auf den Tisch bringen - mir war diese Geschichte bis vor 2 Tagen nicht bekannt.
    • Weiters verwundert es, dass - obwohl das Problem schon 2017 hier im Forum diskutiert wurde - VTI-Freigaben noch immer nicht die höchstwertigste SMB-Version selbsttätig aushandeln können (Updates gab's in der Zeit ja mehrere).
    Btwy: ich hab' den Parameter ('vers=2.1') auch versucht zwischen 2 VU+-Boxen mitzugeben: da funzt das nicht - da ist anscheinend noch etwas Forschungsarbeit angesagt (vllt gibt's Freigaben-serverseitig auch eine config, wo man SMBv1 ausschließen muss?).
    2 x Duo4k, Solo4k; Duo4kSE in der FeWo; (2 x Duo & Solo2 ausgemustert)
  • Bemühe mal die Suche. Es gibt (nicht nur von mir, sondern auch von vielen anderen) ganz viele Beiträge zu den neueren SMB-Versionen.

    Aktueller Stand:
    Der VU+ Samba-Server unterstützt maximal die SMB Version 2.0
    Der VU+ Samba-Client unterstützt maximal die SMB Version 3.02

    Ich weiß mangels Linux-Kenntnissen nicht, ob das bei Samba immer so ist, dass man die Version mitgeben muss. Windows-Geräte handeln immer die maximal unterstützte Version aus und nehmen die höchste Version von ganz allein.
    Wenn Samba das ab einer bestimmten Version auch kann, dann wäre es natürlich toll, wenn man diese mal in das Image einbauen könnte. Ob das aber bei den relativ alten Linux Kerneln der Boxen geht ist wieder eine andere Frage...

    Gruß,
    Stefan
  • Zenturio schrieb:

    ... ich hab' auf einem PC testweise Win10 installiert, daraufhin meinen Linux-Server nicht mehr gesehen und deswegen einige Zeit verbraten ...
    Wenn ich es mir genau überlege, haben sich Win10 und mein Debian-Server auch nicht auf SMBv2 geeinigt, bevor nicht die Einträge 'min protocol = SMB2' und 'max protocol = SMB3' in die smb.conf im Server eingetragen wurden - das hat also auch hier nicht automatisch funktioniert.

    ----

    Habe nun versucht SMBv2 zwischen 2 VU+-Boxen zu realisieren:
    • Eintrag 'min protocol = SMB2' in die 'etc/smb.conf' (+ GUI Neustart) meiner Schlafzimmer-Duo4k,
    • dann auch noch in die 'etc/smb_conf_vers-3.6.25-vti002' (+ GUI Neustart)...
    ... und jeweils mit Parameter 'rw,vers=2.0' bzw. 'rw,vers=2.1' versucht von der Wohnzimmer-Solo4k die Freigabe aufzubauen - leider Fehlanzeige!

    Warum konnte ich SMBv2 zwischen den 2 Boxen nicht aktivieren? Fehlt noch was?

    Thx
    2 x Duo4k, Solo4k; Duo4kSE in der FeWo; (2 x Duo & Solo2 ausgemustert)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Zenturio ()

  • Der Eintrag, den Du zitiert hast, war auf meinem Debian-Server notwendig - dann konnte ich die Boxen mit v 2.1 und 3.02 dort hin verbinden.

    ----

    Die auto.network_vti der Wohnzimmer-Solo4k mit VTi 14.0.6 (2020-02-25-vti-master (216bc5d2a)):

    Quellcode

    1. ##################################################################
    2. # DO NOT TOUCH THIS FILE - THE FILE IS CREATED AUTOMATICALLY !!! #
    3. ##################################################################
    4. vuplussz -fstype=cifs,rw,iocharset=utf8,user=root,password= ://192.168.xxx.yyy/Harddisk
    5. media -fstype=cifs,rw,vers=3.02,iocharset=utf8,user=xxxxxxxx,password=yyyyyyyy ://192.168.xxx.zzz/media
    Anm.: Eintrag 'vers=2.1' hinterm 'rw' bei der Verbindung zur Schlafzimmer-Box vuplussz - Duo4k VTi 14.0.5 (2019-10-05-vti-master (5ede501b9)) - hab' ich heraus genommen, nachdem es nicht funktioniert hat.

    Wie gesagt: wie ich es probiert hab', war in der Duo4k im Schlafzimmer in der smb.conf der Eintrag 'min protocol = SMB2' drin (hat aber nix genutzt).
    2 x Duo4k, Solo4k; Duo4kSE in der FeWo; (2 x Duo & Solo2 ausgemustert)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Zenturio ()

  • Wenn Du auf der "Serverbox" (bei Dir die Duo4k im Schlafzimmer) den Eintrag min protocol = SMB2 machst, dann MUSST Du in der Clientbox auch in der auto.network_vti den Parameter vers=2.0 zufügen, sonst geht es nicht, weil Du SMBv1 in der Serverbox damit ja quasi abschaltest.
    Also entweder die beiden Parameter min und max protocol wieder raus oder immer vers=2.0 nutzen. ves=2.1 geht nicht, wie ich in Beitrag #55 schon geschrieben habe.

    Bei einer Verbindung zu einem Windows 10 oder Server muss seit Version 1709 immer mind. mit vers=2.0 verbunden werden. Da ein Windows aber auch deutlich neuere SMB-Versionen (aktuell bis 3.1.1) unterstützt, kannst Du dort auch immer den Parameter 3.02 nehmen. Dies ist die aktuell maximal von VU+ unterstützte SMB-Version für den Client (siehe ebenfalls Beitrag #55).

    Gruß,
    Stefan
  • Teddybär schrieb:

    Wenn Du auf der "Serverbox" (bei Dir die Duo4k im Schlafzimmer) den Eintrag min protocol = SMB2 machst, dann MUSST Du in der Clientbox auch in der auto.network_vti den Parameter vers=2.0 zufügen,
    ... genau so hab' ich es gemacht - und geht nicht.

    -----

    Damit wir nicht aneinander vorbei reden, hab' ich es jetzt nochmals probiert: in der Schlafzimmer-Duo4k sowohl in die /etc/samba/smb.conf als auch in die /etc/samba/smb_conf_vers-3.6.25-vti002 diesmal beide Einträge

    Quellcode

    1. min protocol = SMB2
    2. max protocol = SMB3
    unter [global] rein getan (beim 1. Versuch hatte ich nur den min-Eintrag) - und von der Wohnzimmer-Solo4k in der Freigaben-Verwaltung die Verbindung versucht: es hat weder mit 'rw,vers=2.0' noch mit 'rw,vers=2.1' funktioniert (dass es mit 3.02 wg Kernel nicht tut, ist klar).

    ???

    Thx & lG
    2 x Duo4k, Solo4k; Duo4kSE in der FeWo; (2 x Duo & Solo2 ausgemustert)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Zenturio ()

  • Nimm doch bitte mal diese max und min protocol-Einträge wieder raus und starte die Box komplett neu (nicht nur die GUI).
    Dann nimmst Du in den Freigabeoptionen die Parameter rw,vers=2.0 und startest auch diese Box neu. Nochmal: 2.1 kann mit einer VU+ aktuell nicht funktionieren, das kannst Du Dir sparen!!!

    Wenn es dann immer noch nicht geht, dann startest Du Deinen Router mal neu und nach dem Hochfahren beide Boxen nochmals.