Win10 an Samba-Server - mit SMB2 ein Problem

Oktavus

Enthusiast
Thread Starter
Mitglied seit
16.11.2010
Beiträge
362
Hi,

weil das Samba-Protokoll SMB1 unsicher ist und M$ es in Win10 standardmäßig überhaupt deaktiviert hat, hab' ich meinen Linux-Server (Debian 9; Samba 4.5.16 ) so konfiguriert, dass er mit mindestens SMB2 und max SMB3 Verbindungen aufbaut - SMB2 & SMB3-Verbindungen funktionieren von den Win7-PCs als auch von den SAT-Linux-Kisten.

Nun hab' ich den ersten PC auf Win10 umgestellt, d.h. ein clean install gemacht - ich krieg' schon seit Stunden den Win10-PC nicht mit SMB2 an den Linux-Server! Im Netz findet man viele Tipps SMB1/CIFS auf Win10 wieder zu aktivieren (müsste ich am Server natürlich auch zulassen) - aber das soll aus Securitygründen nicht die Lösung sein.

Ich hab' jetzt andere Tipps gefunden: nach hier SMB2 versucht zu aktivieren, nach hier (letztes Posting) versucht, auch die Dienste, die hier unten angeführt sind, unter dem administrator aktiviert (auch beim Start automatisch) - es geht nix! Meinen SAT-Receiver seh' ich vom Win10-Rechner aus (kann mich auch connecten) - aber der Debian-Server bleibt unter SMB2 verschwunden!

Hat noch jemand Ideen?

Thx
Oktavus


P.S.: als ich vor ein paar Tagen auf einem anderen PC auf eine uralte HDD testweise Win10 drauf gespielt habe, hat's erstaunlicherweise gleich funktioniert...
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dass es ein Linux-Problem meines Debian-Server wäre, glaub' ich nicht: ich schrub ja im P.S., dass es bei der Testinstallation (auf einem andern PC) funktioniert hat - d.h. da konnte ich mit SMB2 auf den Debian-Sambaserver.

Nur bei dem PC (meiner Göga) ist SMB2 nicht zum Laufen zu kriegen. Was ist der Unterschied zwischen den 2 PCs? Ein anderes MoBo und eine etwas anders abgelaufene Installation der NIC: d.h. auf dem Problem-PC konnte beim Aufsetzen von Win10 die Netzwerkkarte nicht problemlos installiert werden - sie blieb mit Rufzeichen im Geräte-Manager hängen. Hierzu gibt's sogar einen Thread, hier in #4 die Lösung (es musste ein Update von Intel nachinstalliert werden, bis die NIC erkannt wurde).

Möglicherweise ist dadurch, dass die NIC von Win10 nicht auf Anhieb erkannt wurde, bei der Installation irgend etwas anders gelaufen. Nur was? Wie suchen?

Ich könnte natürlich morgen auf einem 3. Rechner eine Win10-Testinstallation machen, um ein Problem beim Linux-Server auszuschließen - hilft mir aber bei Gögas PC wenig weiter: wenn ich die Installation wiederhole, wird das Intel-Update wieder zum Nachinstallieren sein...

Thx


NACHTRAG-1: derzeit sehe ich im Netz jede Menge Geräte - SAT-Receiver, die Kamera außen am Haus, den AVR, ... sogar den DNLA-Server vom Debian-Server - nur die SMB2-Connection genau dorthin geht nicht.

-----

NACHTRAG-2:
Habe Win10 auf der Problemkiste neu aufgesetzt und genau das gemacht, was ich vor einem halben Tag schon gemacht habe - diesmal ist die NIC ohne Fragezeichen installiert worden (kein Mensch weiß warum)! Laut hier mit Befehl 'Get-SmbServerConfiguration | Select EnableSMB2Protocol' in der Console nachgesehen - steht auf 'true' - sollte also laufen ... trotzdem keine Connection unter SMB2 :cry:.
 
Zuletzt bearbeitet:
Hallo,

ich verstehe das genaue Problem nicht.
Vermisst du nur die Auflistung des Servers beim Broadcast?
Oder kannst du mit \\server keine Verbindung aufbauen und es gibt einen Fehler?

gruß
hostile
 
Nachtrag: Ich habe mich mal selbst damit beschäftigt und das hier gefunden:

The problem is that NetBios discovery is now disabled by default in Windows for security reasons, and Samba never implemented support for Web Services for Windows (WSD), which is the "modern" way, AFAICT, for things to be visible in Windows Network.

https://bugzilla.samba.org/show_bug.cgi?id=11473

Also see: https://github.com/christgau/wsdd for a possible solution.

Source: https://askubuntu.com/questions/661611/make-samba-share-visible-in-windows-network

Ich habe das auf meiner Gentoo-Kiste implementiert (also wsdd). Funktioniert tadellos.

gruß
hostile
 
@ hostile : danke!

Teilerfolg - Workaround gefunden. Aber der Reihe nach und zusammenfassend:
  1. Erst hab' ich Win10 testweise auf einem ASRock-Board aufgesetzt, dann SMB1 am Debianserver abgedreht - (min=SMB2/max=SMB3-Einträge in die smb.conf) - das SMB2-Protocol lief.
  2. Auf den anderen PCs mit Win7 gab's nach dem Abdrehen von SMB1 keine Probleme - der Zugriff funktionierte weiter.
  3. Dann hab' ich auf einem ASUS P8Z68-V (PC der Göga) Win10 'richtig', d.h. mit neuem Key aufgesetzt - SMB2 lief nicht. 1/2 Tag herum probiert. Liegt es an der HW?
  4. Um das auszuschließen, heute Früh ein Lenovo-X230 testweise mit Win10 installiert - dasselbe Problem wie am ASUS. Also liegt's nicht an der HW.
Was also war bei 1.) anders? Ich hatte - bevor ich auf SMB2 umgestellt hatte - einmal eine Connection mit SMB1 gehabt! Weiters hab' ich auch hier Einblick genommen und ein YT-Video gefunden. Letztendlich führte zum Erfolg:
  1. Win10 / Systemsteuerung / Programme / Windows-Features aktivieren & deaktivieren - hier bei Unterstützung für die SMB 1.0/CIFS (nur) den SMB 1.0/CIFS Client anhaken,
  2. Dann am Debian-Server in Samba die min/max-Einträge deaktivieren, Samba neu starten (= SMB1 ermöglichen).
  3. Nach einem Boot der Win10-Kiste sind alle Rechner im Netz sichtbar - und es lässt sich eine SMB1-Connection zum Server aufbauen.
  4. Danach am Server die SMB1 deaktivieren, d.h. die min/max-Einträge in der smb.conf wieder aktiv setzen, Sambaserver restarten.
  5. Ab diesem Zeitpunkt waren auf dem Win10-PC der Debian-Server und jene Rechner, die sambamäßig am Server dran sind, nicht mehr sichtbar - andere Geräte wie TV, Kameras, AVR, DLNA-Server (vom Debian) waren zu sehen.
  6. Nachdem SMB1 am Debian-Server abgedreht war, haben die Connections unter Win10 weiterhin funktioniert (obwohl der Server im Netzwerk nicht mehr sichtbar war). Und hier unterscheiden sich die 2 Win10-Rechner: beim Lenovo-X230 konnte ich SMB 1.0/CIFS Client wieder abhaken - SMB2-Connections haben weiterhin funktioniert, beim ASUS musste ich den Haken drin lassen.
Es funktioniert also jetzt (endlich) :-). Warum da allerdings ein 'Workaround' stattfinden muss und SMB2 nicht gleich funktioniert, ist mir schleierhaft. Hat jemand eine Idee???

Ob ich jetzt das NetBios discovery noch aktiviere (Tipp von hostile im vorherigen Posting) oder es als Sicherheitsfeature sehe und nicht aktiviere, werde ich mir noch überlegen (erst muss ich Gögas Kiste + 3 andere Rechner auf Win10 umstellen, clean install).

Danke!

Oktavus
 
Also der PC mit dem P8Z68-V / Win10 hatte Probleme mit SMB2? Was denn jetzt genau? War der Debian-Server nicht sichtbar oder konntest du nicht per \\server oder \\ip drauf zugreifen?
Ich hätte das von Anfang an als Softwareproblem eingeschätzt. Mit Powershell kannst du diverse Parameter anzeigen. Leider ist das ganze Thema mittelmäßig komplex, da gibt's kein Patentrezept. Mit den Updates wurden da einige Parameter von Microsoft aktiviert/deaktiviert. Evtl. kam es zum Durcheinander.
Ich hätte mir auch mit Wireshark den Traffic mal angeschaut.

Der alte "Discovery-Service" ist eben mit SMB1 abgeschaltet, deswegen tauchen die nicht mehr in der Netzwerkumgebung auf. WS-Discovery nennt sich das Neue (nur damit wir vom Gleichen sprechen). Würde ich nicht als Sicherheitsfeature betrachten (Security by obscurity ^^).

gruß
hostile
 
Also der PC mit dem P8Z68-V / Win10 hatte Probleme mit SMB2? Was denn jetzt genau?
Es haben sowohl das P8Z68-V als auch das Lenovo-X230 Probleme gehabt - und das ASRock hätte sie auch gehabt, wenn zum Zeitpunkt des Win10-Aufsetzen SMB1 am Debianserver deaktivert gewesen wäre.

Ich konnte nicht mit \\MEINSERVER\freigabe\ (oder ip#\freigabe) zugreifen - es kam immer ein Fehler '.... nicht gefunden'. Und dann lief die Fehleranalyse, die zu nix führte.

Ich hab' jetzt die genaue Fehlermeldung zu reproduzieren versucht (um einen Screenshot zu machen) - und auch beim P8Z68-V den Haken bei SMB1/CIFS Client raus genommen - es funzt weiterhin, keine Fehlermeldung! Ich mag da jetzt nicht herum drehen, nur um die Fehlermeldung reproduzieren zu können - ich nehme an, dass ich die in ein paar Tagen, wenn ich den nächsten Rechner auf Win10 umbaue, nachliefern kann.

Für mich sieht es so aus, als dass Win10 durch 1x Verwendung von SMB1 irgend eine Komponente installiert, die es dann unter SMB2 benötigt (mich wundert nur, dass man im Netz dazu nix findet - nur haufenweise Tipps, wie man SMB1 wieder aktivieren kann....).

Dass man die anderen Geräte jetzt nicht sieht, sehe ich eigentlich auch als Sicherheitsfeature. Ich selbst hab' die wichtigen IP# eh im Kopf - und meine Göga interessiert's nicht.

LG
 
Zuletzt bearbeitet:
Ich konnte nicht mit \\MEINSERVER\freigabe\ (oder ip#\freigabe) zugreifen - es kam immer ein Fehler '.... nicht gefunden'. Und dann lief die Fehleranalyse, die zu nix führte.
Alrighty.
Welche Version hast du von Samba? (smbstatus --version)
Welche von Windows 10 genau? (winver.exe)
Welche min / max Parameter genau sind in der smb.conf?

Ich kann das ja gleich mal nachstellen.

gruß
hostile
 
Debian 9; Samba 4.5.16 (schrieb ich schon in #1); Win10 vor ein paar Tagen von M$ herunter geladen - Version 2004 (Build 19041,450);
Code:
min protocol = SMB2
max protocol = SMB3
in der smb.conf unter [global]

NACHTRAG: dem Output vom Befehl smbstatus entnehme ich, dass hier SMB3.1-Connections zustande gekommen sein dürften.
 
Ich habe noch eine alte Debian 8 VM gefunden. Samba 4.2.14-Debian.

Code:
Samba version 4.2.14-Debian
PID     Username      Group         Machine            Protocol Version
------------------------------------------------------------------------------
2550      nobody        nogroup       192.168.0.221 (ipv4:192.168.0.221:50028) SMB3_00 (Win10 2004 per Update)
2481      nobody        nogroup       192.168.0.212 (ipv4:192.168.0.212:50567) SMB3_00 (Win10 2004 Neuinstallation)
2427      nobody        nogroup       192.168.0.206 (ipv4:192.168.0.206:57070) SMB2_10 (Win7)

Service      pid     machine       Connected at
-------------------------------------------------------
IPC$         2550   192.168.0.221  Sat Oct 17 13:05:29 2020
Test         2427   192.168.0.206  Sat Oct 17 13:02:01 2020
IPC$         2427   192.168.0.206  Sat Oct 17 13:02:01 2020
IPC$         2481   192.168.0.212  Sat Oct 17 13:03:25 2020
Test         2481   192.168.0.212  Sat Oct 17 13:03:29 2020

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
2427         65534      DENY_NONE  0x100081    RDONLY     NONE             /mnt/samba/public   asd   Sat Oct 17 13:02:14 2020
2427         65534      DENY_NONE  0x100080    RDONLY     NONE             /mnt/samba/public   .   Sat Oct 17 13:02:04 2020
2427         65534      DENY_NONE  0x100081    RDONLY     NONE             /mnt/samba/public   .   Sat Oct 17 13:02:05 2020
2481         65534      DENY_NONE  0x100081    RDONLY     NONE             /mnt/samba/public   .   Sat Oct 17 13:03:29 2020
2481         65534      DENY_NONE  0x100081    RDONLY     NONE             /mnt/samba/public   .   Sat Oct 17 13:03:29 2020
??

gruß
hostile
 
Äh ... was sollte mir das sagen? Du Hast Connections mit SMB2 + SMB3 laufen .... sonst?

Ich hab' meine (Linux-)SAT-Receiver auch dazu gebracht, mit dem Debianserver zu kommunizieren und auf SMB1 zu verzichten - da geht' sogar v 3.02. D.h. wenn nicht noch was auftaucht, hat die Umstellung >= SMB2 geklappt.
 
Soll dir sagen, dass ich nicht nachvollziehen kann, wie ein Windows (per Upgrade-Pfad oder Neuinstallation) kein SMB2 mag.

gruß
hostile
 
Du dürftest recht haben - könnte mein Fehler gewesen sein.

Ich hab' jetzt einen weiteren Rechner auf Win10 umgestellt (clean install): da hat's - ohne am Server kurzzeitig SMB1 zu aktivieren - gleich mit SMB2 funktioniert. Ich kann's jetzt nicht ausschließen, aber vielleicht hab' ich mich beim Eintippen des Pfades zum Server vergeigt (Stichworte: Slash/Backslash/doppelter Backslash). Jedenfalls war nach 1x SMB1 der Pfad im Pulldown-Menü - da konnte ich dann nix mehr falsch machen....

... vielleicht war's so ... sorry.

LG
 

Ähnliche Themen

Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh