[English]Mit den Sicherheitsupdates für Windows 10 und Windows 11, die zum 9. September 2025 freigegeben wurden, hat sich ein Problem beim Zugriff auf SMBv1-Netzwerkfreigaben eingeschlichen. Hier im Blog gibt es Leserkommentare dazu. Nun deutet sich an, dass Microsoft zumindest intern das Problem bestätigt hat.
Windows 10/11 September 2025-Update
Zum 9. September 2025 hat Microsoft kumulative Sicherheitsupdates für die noch im Support befindlichen Versionen von Windows 10 und Windows 11 veröffentlicht. Die Updates beheben einige Bugs und schließen zudem Schwachstellen. Dazu gehören auch die Korrekturen für den UAC-Fehler oder die SMB-Client-Kompatibilität. Die Updates sind im Blog-Beitrag Patchday: Windows 10/11 Updates (9. September 2025) aufgelistet.
SMB-Probleme nach Sept. 2025-Update
Es schaut so aus, dass die oben erwähnten Korrekturen an der Kompatibilität des SMB-Clients zu Problemen mit Netzwerkfreigaben führen. Bereits kurz nach Freigabe der September 2025-Updates meldeten sich diverse Blog-Leser und berichteten, dass Netzwerkfreigaben (Shares) nicht mehr erreichbar seien. Bolko schreibt in diesem Kommentar, dass es bei Windows 11 "mit höherem Patchlevel als 26100.4946 (also z. B. 26100.5074 oder 26100.6584)" Netzwerkprobleme geben und Netzwerkfreigaben nicht mehr erreichbar seien.
Im Kommentar verlinkt er auch Hinweise, an was es liegen könnte. In einem späteren Kommentar kam von Bolko der Hinweis, dass die Probleme an der Korrektur der Schwachstelle CVE-2025-55234 (Windows SMB Elevation of Privilege Vulnerability) liegen. In Folgekommentaren beschreibt er, dass Kunden entweder SMB-Server so konfigurieren müssen, dass die SMB Server-Signatur erforderlich ist. Oder sie müssen am SMB-Server EPA aktivieren, um ihre Systeme gegen die Angriffsklasse aus CVE-2025-55234 zu härten. Das Ganze ist im Support-Beitrag Support for Audit Events to deploy SMB Server Hardening—SMB Server Signing & SMB Server EPA (KB5066913) vom 9. September 2025 beschrieben. Allerdings gibt es derzeit eine neue Entwicklung (siehe nachfolgenden Text).
Microsoft bestätigt das SMB-Problem
Bolko hat zum heutigen 16. September 2025 diesen Kommentar hinterlassen, nachdem Microsoft das SMB1-Problem bei Netzwerkfreigaben seit den September 2025-Updates bestätigt habe. Er zitiert einen Service-Alert:
service alert […] known issue affects those connecting to SMBv1 shares over the NetBIOS over TCP/IP (NetBT) networking protocol.
"After installing the September 2025 Windows security update (the Originating KBs listed above) or later updates, you might fail to connect to shared files and folders using the Server Message Block (SMB) v1 protocol on NetBIOS over TCP/IP (NetBT)"
Workaround:
allow traffic on TCP port 445, which will cause the Windows SMB connection to resume successfully by switching to using TCP instead of NetBT.
Bolko zitiert dabei den Artikel Microsoft says Windows September updates break SMBv1 shares der Kollegen von Bleeping Computer, den ich die Nacht ebenfalls gesehen hatte. An den von Bleeping Computer verlinkten "Service Alert" komme ich mangels zugelassenem Konto nicht heran.
Betroffen sind bei den Clients Windows 10 21H2 – 22H2 sowie Windows 11 22H2 – 24H2. Bei den Servern sind Windows Server 2022 und Windows Server 2025 betroffen. Microsoft arbeitet derzeit an der Behebung dieses Problems. Betroffene Kunden müssen in der Zwischenzeit den oben skizzierten Workaround versuchen.
Das Problem wurde mit den Preview-Updates für September 2025 für Windows 10 22H2 und Windows 11 23H2 behoben (siehe Windows 10 22H2/Windows 11 23H2: Preview Updates (23./25. September 2025)).
Ähnliche Artikel:
Microsoft Security Update Summary (9. September 2025)
Patchday: Windows 10/11 Updates (9. September 2025)
Patchday: Windows Server-Updates (9. September 2025)
Patchday: Microsoft Office Updates (9. September 2025)
Windows 10/11: September 2025-Updates verursachen SMBv1-Probleme
MVP: 2013 – 2016
Ist hier nicht eher SMBv1 das Problem?
allerdings, SMBv1 haben wir schon seit Jahren bei uns geblockt.
Laut Microsoft ist das eher ein SMBv1 via NetBios over TCP Problem. Der Workarround der genannt wurde, sofern das so funktioniert, ist für die Masse der beschriebenen Meldungen doch eh gegeben.
Sofern das wirklich reicht, ist das mal wieder viel Wind um nix, auch der Aufschrei der Leute mit dem Verweis auf Produktionsumgebungen, da wird es selten zwischen den jeweiligen abgeschotetten Produktionslinien noch Geräte geben, die explizt TCP Port 445 wegblocken. So recht versteh ich den Aufschrei dahingehend nicht.
Mich dünkt, dass ist wieder das typische User = Faul Thema, weil anstatt \\Gerät.Domain\Freigabe eben nur \\Gerät\Freigabe verwendet wird und es keine alternative zum übersetzen der Kurznamen in die Umgebung geschafft hat als eben das Assbach NetBios Protokoll zu nutzen…
Das gleiche gilt für Druckerverbindungen usw.
Erzwingt man Windows via DNS aufzulösen (also Gerät.Domain als Ziel zu nutzen), dann wird auch kein NetBios gesprochen. Zudem der Kram je nach Konstellation eh Anfällig für viele Probleme ist, da einer der PCs den Master stellt und die Namen auflöst. Das funktioniert seit über 10 Jahren mehr schlecht als recht und default Funktionen neuerer Windows Systeme verhindern das schon perse out of the Box. Ein Public FW Profil bspw. im LAN Adapter.
SMBv1 sollte man sowieso nicht mehr benutzen! Ganz unabhängig von diesem Problem.
Jain. Prinzipiell hast Du Recht.
Aber – es gibt Firmen, wo CNC-Fräsmaschinen noch über Windows NT 4.0 gesteuert werden. Ja, diese laufen in einem abgeschotteten separaten Netz. Wo eingeschränkter einseitiger Netzwerkverkehr noch zugelassen ist.
Du kannst nicht einfach den Unternehmen vorschreiben, neue Investitionen in Hunderttausende oder gar Millionen zu tätigen, nur weil ein Betriebssystem für den Steuerungs-PC nicht mehr support wird.
Diese CNC-Fräsmaschinen, Blechwalzmaschinen sind ausgelegt auf jahrzehnte Jahre Betrieb. Günter kann Dir das bestätigen.
in einem solchen abgeschotteten Netz muss dann aber weder das aller neuste OS (das ggf. überhaupt kein SMBv1 mehr unterstützt) geschweige denn das letzte Security Patch nach nur 1 Woche installiert werden.
das Netz ist so abgeschottet, dass diese PCs nicht raus können. Und fast niemand drauf. Aber bei uns dann doch gut ein Dutzend Mitarbeiter, die auf bzw von den Maschinen die Programme kopieren. Und die haben natürlich normale aktuelle Win10 bzw Win11 PCs mit denen sie alles tun.
Jo, meinte ein Kunde von uns auch – bis dann ein Trojaner genau darüber (Wannacry? Vergessen was es war) von irgendeinem die Credentials abgezogen hat und damit sich im ganzen Netzwerk verbreitet. Das war auch abgeschottet. Aber wenn ein Port offen ist und eine Möglichkeit gegeben ist halt vorbei.
Dann lieber einen Share auf einem Windowsserver anlegen, wo der Inhalt via RSYNC, FTP oder wie auch immer auf eine Linuxkiste im gesicherten Netzwerk mit der CNC Maschine landet und nur dort, in diesem Netz SMBv1 geht, in welches es dann keine anderen Verbindungen firewallseitig möglich sind – außer eben die Daten da rüberzuschieben.
Nur weil die Kiste in einem eigenen VLAN rumgammelt – sobald du da Zugriff und Auth hast, ist das Tor offen. Gerne mal selbst testen mit Mimicry und was weis ich was es da alles gab.
Also keine Belehrung für dich, kenne ja den Aufbau nicht, aber da muss man echt vorsichtig sein.
Naja da gehört der Admin geterrt und gefedert! Wenn die das direkt von den Win10 Rechnern aus können ist da eben keie saubere Trennung gegeben…
Stuxnet hat sich via USB-Sticks, die in die abgeschotteten Umgebungen getragen wurden, verbreitet. Just saying. Abgeschottet wäre für solche Umgebungen: da geht nichts rein noch raus. Aber rein darf da gar nichts gehen.
So sieht es aus. Solche Aussagen kommen vermutlich von Zeitgenossen die NICHT in einem Produktionsbetrieb tätig sind.
Die haben aber im allgemeinen auch ihre "Alten SteuerPC" so das die kein Win10+ benötigen!
Meistens sogar gar nicht upgegraded werden können! Die laufen dann mit ne Win7 embedded oder gar noch WinXP embedded.
Wenn die bereits mit Win10 laufen brauchen sie auch kein SMBv1 mehr.
Denkfehler: Die Steuer-PCs haben die alten Versionen, das ist richtig. Aber die leben ja nicht alleine vor sich hin, da müssen von anderen Stellen ja Daten rauf oder runter. Und das sind in der Regel dann schon aktuelle Systeme. Siehe das Szenario was "S" oben beschreibt.
Nein kein Denkfehler! Die müssen eben nicht direkt von W10 Kisten angesprochen werden… Das macht man über Zwischenlayer, sonst kannst dir die Abschottung auch direkt sparen! Siehe auch was Anonym auf S antwortet…
aber klar hast recht gepfuscht wird da zu hauf und sieht man ja dann an den "gehackt Meldungen"!
Dann gibt es da noch den Gesundheitssektor, wo die Geräte erstmal einen Zertifizierungsprozess durchlaufen müssen, welche mal gut und gerne 5Jahre dauert. Die Rechner können nicht geupdated werden, da diese in der aktuellen Version zertifiziert wurden und der Hersteller keine Garantie bei anderen übernimmt.
Die Lösung ist doch ganz klar beschrieben. Für diese Kisten ein eigenes Netz, und da braucht es auch keine Updates. Diese Probleme haben wir alle. Ich muss 3 Forschungseinrichtungen supporten wo jede Maschine Unique ist. SMBv1 gehört in Kisten auf dem Normalnetz aber einfach deaktiviert. In den anderen, abgeschotteten Netzen kann man dann machen was man will, und da braucht man dann auch normalerweise keine Updates. Dann aber auch kein Internet. Beides zuzulassen ist dann fahrlässig.
Muss meinen HNO-Doc demnächst mal fragen, ob er noch das IBM Thinkpad für sein Diagnose-Gerät benutzt, da gab es nämlich auch kein Update.
Eigenständige Hardware funktionert auch ohne Updates, das ist vielen nicht (mehr) klar…
"Du kannst nicht einfach den Unternehmen vorschreiben, neue Investitionen in Hunderttausende oder gar Millionen zu tätigen, nur weil ein Betriebssystem für den Steuerungs-PC nicht mehr support wird."
Hmm – kann man nicht?
Hat Microsoft doch schon längst getan. PC Hardware im Wert von Milliarden muss verschrottet werden, weil Microsoft sie mit Windows 11 nicht mehr unterstützen will.
Es ist aber ein entscheidender Unterschied, ob man das bei solchen Investitionssummen einem einzelnen Nutzer oder einer Nutzermenge, wo sich die Einzelbelastung verteilt, aufbürdet. 🤷♂️
Wo ist die Wahrscheinlichkeit auf Akzeptanz wohl größer, dass man mit sowas "durchkommt"?
wenn alle Produktionsmaschinen mit altem Windows neu beschafft werden müssen, kostet das mehr als den Jahres-UMSATZ.
Ja, und… was hab' ich sinngemäß anderes geschrieben?
Erstmal darf man ja nicht davon ausgehen, dass alle produzierenden Unternehmen ausschließlich Produktionsmaschinen auf "altem" Win basierend haben, und dann ist das eben "nur" die Belastung für ein einzelnes Unternehmen, die natürlich trotzdem durch das immense Investitionsvolumen abschreckend wirkt – dsh. würde eben ein geringeres Investitionsvolumen auf eine breitere Masse verteilt auch besser durchsetzbar.
ich hab dir eigentlich zugestimmt.
Beispiel aus meinem Umfeld:
Es gibt einige Win10 LTSC die noch Updates bekommen. Ansonsten wurde noch vor 2 oder 3 Jahren auch neue Maschinen mit Win 10 gekauft. Dort hat die IT kein Mitspracherecht. Natürlich auch Win 11 wenn verfügbar. Und der Kauf von Gebrauchtmaschinen im Alter von 5 bis 15 Jahren hilft fürs Durchschnittsalter auch nicht.
Ich sehe da kein Problem.
Wer nach Wannacry immer noch SMBv1 verwendet ist selbst schuld.
Ich würde mich freuen wenn Microsoft, ohne Ankündigung, SMBv1 einfach abschaltet.
Noch einer, der noch nie mit einem produzierenden Unternehmen zu tun hatte. Es gibt Gründe, warum das in speziellen Situationen noch genutzt werden muss. Siehe auch gerne den Kommentar von "aus dem Rhein-Main Gebiet" weiter oben.
Aber eben NICHT in der produktiven Umgebung und nur "einfach" abgeschottet. Kunde von uns hat sich auch sicher gefühlt, da Firewall abgeschottet, extra Netzwerk usw.
Nachdem das lustige Verschlüsseln dann gelaufen ist, war schnell klar, dass die Idee doch nicht so geil war.
Man kann es durchaus absichern, aber generell sollte die Nutzung im produktiven Netz oder eben in das abgesicherte Netz nicht stattfinden. Sollte "airgapped" sein – und wenn das nur heisst, auf eine Linux VM zu verbinden in dem geschützen Netz und von da aus auf den Server. Halt mit 1-2 Umwegen.
Firmen-Netzwerke werden in der Regel genau dann unsicher, wenn man externe Dienstleister einkauft und ihnen Zugang gewährt.
Deren Marketing verspricht einem aber auch immer das Blaue vom Himmel. SAGE, bspw. – und ich kenne deren Dienstleister, die relativ "ungesichert" auf den Systemen von "Mein Schiff" (AIDA) rumfuhrwerken dürfen.
Selber schuld, sage ich da nur!
Und warum gab es einen Nutzer, der überall die Berechtigung zum Schreiben/Verschlüsseln hatte?
Hat MS doch; SMBv1 wird ab Win10 V1709 (Fall Creators Update) standardmässig gar nicht mehr installiert, man muss es selbst nachinstallieren wenn man es nutzen möchte/muss.
Da laufen also Leute in den Fehler die veraltete Protokolle fahren ohne diese selbst sicher zu handeln.
Es gab schon frueher "Probleme" mit smb v1 und Windows10-Updates. Bei uns betraf das meist Kleinbueros mit älteren Gruppendruckern und der Scan-Funktion zu einer Windows-Freigabe. Etliche alte Drucker (zb develop, konica) bekommt man per Firmwareupdates auch nicht mehr smb v2-fähig.
Besser und bzgl der Windows-Updates störungsfreier als die Reaktivierung von smb v1 scheint mir da der Umweg via ScanToFTP zum Windows-Rechner:
https://compeff-blog.cf2.de/2021/geloest-scantoftp-statt-scantosmb-bzw-scantofolder-fuer-konica-minolta-bizhub-und-develop-ineo-multifunktionsgeraete-ohne-smb-v2-unterstuetzung/
oder Scan to (internem) SMTP
Das SMBv1-Problem kenne ich von meinem alten Buffalo NAS.
Das kann ab Werk nur SMBv1.
In der GUI gibt es keine Möglichkeit, die SMB-Version zu ändern
Aber es gibt eine Möglichkeit, das auf SMBv2 umzustellen.
Man muß per SSH aufs NAS und dann eine Datei editieren, dann Neustart des NAS und es kann SMBv2.
SMBv1 gehört seit Jahren abgeschaltet. Wer das immer noch nutzt braucht sich nicht über Sicherheitstechnische Konsequenzen wundern.
Bin eher geschockt dass es scheinbar immer noch so verbreitet ist, da ist es scheinbar egal, wenn CVEs von knapp 10 bis 10 vorliegen (Kopfschütteln)
Ach, spendest du den Unternehmen die vielen vielen Millionen Euros, um ihre Maschinen zu ersetzen?
Maschinen laufen i.d.R. 20-30 Jahre oder noch länger!
Dementsprechend ist auch die Windows Embedded-Version auf den Steuerungen entsprechend alt.
Und da kann man keine neue Version aufspielen.
Nicht einmal Patches darf man da einspielen, denn:
1. Es ist nicht sicher, ob die Steuerungssoftware danach noch einwandfrei läuft
2. Es ist nicht sicher, ob die Treiber für die Spezialhardware noch laufen.
3. Die Steuerung wurde genau in dem Zustand, in der die ausgeliefert wurde, zertifiziert.
Mit jedem Patch müsste die neu geprüft und zertifiziert werden.
Genau deshalb bekommen Maschinensteuerungen i.d.R. nie Patches irgendwelcher Art und wenn doch, dann vom Maschinenhersteller selbst.
Das ist dann auch geprüft und zertifiziert.
Und deshalb gehören Maschinen auch immer in ein isoliertes, von der Außenwelt abgeschottetes Netzwerk.
Richtig! DA muss du aber auch nicht direkt mit W10 Rechnern drauf… so das du da kein Probleme hast… läufst du da in das Problem hast du deine Systeme nicht ordentlich abgeschottet und im Griff! Nein auch nicht wenn du von und zu den Rechnern Daten kopierst…das machst du nicht direkt sondern über einen Zwischenlayer, dann laufst auch nicht in das Problem!
Wenn du direkt mit den Win10 Rechnern da reingräscht brauchst auch nicht abschotten den das ist für die Katz!
Moin,
wir haben SMBv1 deaktiviert aber z.B. Druckerfreigaben funktionieren seit dem letzten Update trotzdem nicht mehr.
Auch UNC Zugriffe mit anderen Benutzerdaten klappen nicht mehr
\\PCxy\Drucker1 kann ich nicht mehr verbindgen bzw. komme gar nicht mehr auf den UNC Pfad von \\PCxy
Clients: Windows 11 24h2 mit September Patch
Server: Server 19/22 – hier klappt alles wie gewohnt.
Ob das Problem größer ist als vermutet?
Tappen da noch ein wenig im dunkeln gerade?!
Hat sonst wer auch das Problem?
Besten Dank und eine schöne Woche
Moin Moin,
das ist NORMAL.
Klassische Druckerfreigaben basieren auf SMB v1 NetBT Verbindungen.
Mit entsprechenden Weiter führenden Problemen.
Was damals auch der Grund des von MS gestarteten "Printer Nightmare" war.
(Printer Nightmare war kein Technisches Problem in dem Sinne, sondern Technische Sicherheits Probleme die MS halbherzig bekäpft hat. Sie haben NICHT gesagt
"Diese alten Wege sind Unsicher, aus dem Grund werden sie nicht mehr unterstützt. Macht statt dessen dies und das."
Sondern es gestört und geschwiegen..
DAS ist das was man MS berechtigt vorwerfen kann.
Die Probleme aus alter Technik nicht wirklich. Niemand beschuldigt einen Autohersteller eines Wagens der 60 das die keinen Anschnallgurt hatten. Nur wer den Gurt im Nachhinein nicht einbaut, ist selbst schuld bei einem Unfall.)
Wie auch immer, MS sagt schon, nebenbei…, das sie Freigaben ab "jetzt" nur über RPC machen.
https://learn.microsoft.com/de-de/troubleshoot/windows-client/printing/windows-11-rpc-connection-updates-for-print
Aber das auch nicht klar und laut und Offensichtlich.
Wie auch immer.
DAS wird bei der Druckerfreigabe, in zusammenhang damit das die SMBv1 über NetBT einschränken, die Problmatik sein.
So long
Tom
Moin Tom,
vielen Dank schonmal für die Infos.
Aber jetzt hab ich ja noch das Problem, dass ich z.B. gar nicht so weit komme um überhaupt einen freigegebenen Drucker zu sehen an einem PC in der Domäne.
Auch RDP Login funktioniert nicht mehr zu nem anderen Client
Selbst UAC mit Admin-User funktioniert nicht mehr – auch ohne aktivem SMBv1 … also es ist alles grad ein wenig kompliziert?
Zugriffe per UNC auf Server weiterhin funktional.
Ist nur Client-zu-Client das Problem :(
## Ergänzung:
Es liegt wohl an geklonten Systemen mit selber SID…
https://learn.microsoft.com/en-us/answers/questions/5545056/(24h2)-build-26100-5074-(kb5064081)-release-previe
https://www.reddit.com/r/de_EDV/comments/1ne5uiw/comment/ndm4wnn/
https://www.reddit.com/r/sysadmin/comments/1ne4y6q/rdp_anmeldung_fehlgeschlagen/
sehr ermüdend
eine schöne Restwoche
SMBv1 sollte schon lange gar nicht mehr produktiv eingesetzt werden. Leider gibt es trotzdem noch genügend Hersteller z.B. von Scanner & Multifunktionsgeräte die weiterhin nur SMBv1 unterstützen, oder alte Geräte bei Firmen genutzt werden.
ja weil die Hersteller von Printern, Scanner wie auch NAS, noch Jahre nachdem es schon SMB2 und höher gab. Immer noch neue Geräte mit nur SMB1 verkauft haben. Ansonsten hätten die meisten Geräte mit nur SMB1 schon längst das zeitliche gesegnet.
Was will man da groß diskutieren? Einerseits ist Sicherheit gefragt; andererseits sollen alle "Antiquitäten" funktionieren. Dinge wie SMB1 gehören in ein eigenes, entsprechendes Segment (VLAN) mit Routing über Firewall und einer entsprechenden, bis auf das Nötigste reduzierten Firewallregel.
Ich stimme aber zu, dass es eine theoretische (funktionierende) Zugriffsmöglichkiet über/auf SMB1 geben sollte, die per Default aber bitte aus ist.
Ähnliches steht mit NTLM an.
"Ähnliches steht mit NTLM an."
Das ist hier in der Firma seit mindestens 1,5 Jahren abgeschaltet.
Es gibt nur noch Kerberos.
Und was alte MFPs angeht:
Wir haben hier auch noch 2 Stück.
Aber da ist SMB abgeschaltet, weil die nur SMBv1 können.
Die greifen auf die Netzwerkfreigabe per FTP zu.
Eine dritte Möglichkeit, die die anbieten, ist der Versand der gescannten Dokumente per Email.
Ja – leider. Viele (auch neue) Geräte können nur NTLM für SMB. Da bleiben dann nur Proxy, Scan2Mail oder FTP. Was ich meinte ist, dass NTLM möglicherweise irgendwann auch der Deufault aus sein wird. Dann haben wir ein ähnlichs Thema.
Haben seit heute nach der Installation auf einem Druckserver Server 2022 selbiges Problem, dass Drucker als offline angezeigt und nicht mehr erreibar sind.
SMB v1 wird seit Windows Version 1709 nicht mehr automatisch mit installiert.
Man müsste also SMB v1 manuell in den Features nachinstallieren.
Aber selbst dann, wenn man es manuell nachinstalliert hatte, dann wird SMB v1 nach 15 Tagen Laufzeit automatisch wieder deaktiviert, falls man SMB v1 während dieser Zeit nicht benutzt hat.
learn. microsoft. com/en-us/windows-server/storage/file-server/troubleshoot/smbv1-not-installed-by-default-in-windows
Seit 2007 ist SMB v1 durch SMB v2 superseded.
Seit 2014 gilt SMB v1 als deprecated.
Es ist also recht unwahrscheinlich, dass die Fehler beim Zugriff auf Netzwerkfreigaben ausschließlich mit SMB v1 zu tun haben.
2.
Der Microsoft Mitarbeiter Net Pyle, der seit Jahren für Netzwerksicherheit verantwortlich ist, erklärt es in einem Artikel, warum der Netzwerkzugriff auf ein NAS fehlschlagen kann:
– Seit Windows 11 Version 24H2 ist SMB-Signing Pflicht
– der Fallback auf ein Gast-Zugriff wurde abgeschafft
– Microsoft kennt keinen Unterschied zwischen einem NAS, das seine SMB-Verbindung nicht signiert und einem feindlichen Server. Alles, was nicht signiert ist wird als feindlich betrachtet.
– Microsoft kennt keinen Unterschied zwischen einem NAS, das für seine SMB-Verbindung einen unauthentifizierten Gast-Zugriff erlaubt und einem feindlichen Server. Selbst dann, wenn das NAS auf Gast-Zugriff zurückfällt, dann verhindert Windows die Verbindung aufgrund fehlender Signierung.
Er listet dann 9 Fehlermeldungen auf, die wegen fehlender Signierung oder versuchtem Gast-Zugriff als Fallback auftreten können.
Er gibt 5 Anweisungen, um das Problem zu beseitigen:
1. Am NAS die Signatur aktivieren.
2. Am NAS den Gast-Zugriff sperren.
3. Im NAS Benutzername und Passwort für den SMB-Zugriff einrichten.
4. NAS Updaten, falls man SMB-Signatur nicht aktivieren kann
5. NAS ersetzen, falls man das NAS nicht so updaten kann, dass es SMB-Signierung aktivieren kann.
techcommunity. microsoft. com/blog/filecab/accessing-a-third-party-nas-with-smb-in-windows-11-24h2-may-fail/4154300
3.
Seit den September-Updates wurde aber noch irgend etwas zusätzlich verschärft.
Wurde jetzt endgültig die Signierpflicht scharf geschaltet?
Wurde RPC over TCP Pflicht wie bei Druckerfreigaben?
Hängt es mit deaktiviertem NTLM zusammen (Kerberos-Pflicht)?
Microsoft drückt sich nicht klar oder gar nicht aus.
Ich finde es ziemlich erschreckend, wie hier 44 Kommentare lang durch Werweissen und Raten eine Fehler-Ursachen-Analyse betrieben wird, die ihren Namen nicht verdient. Ist das deutsche Fachinformatikerwesen schon so heruntergekommen, dass man bei der Behandlung von Netzwerkproblemen meint, ohne Diskussion gezogener Network Traces auskommen zu können?
Für all die Schlaumeier, die sich über die Verwendung von SMB1 echauffieren:
Es gibt auch ältere Maschinen und Geräte, deren Kosten im 6-stelligen Bereich oder darüber liegen und bei denen ein Steuer-PC mit (inzwischen) älterem Windows eingebaut ist. Die lassen sich tlw. nicht aktualisieren oder müssten danach neu zertifiziert werden, was tlw. auch nicht mehr möglich ist. Und diese Geräte bekommen halt ihre Daten per SMB1 – das ist und bleibt die Realität. Da wird dann wegen irgendwelchem Microsoft-Gedöns nicht einfach eine neue CNC-Maschine gekauft …