09.01.2019

55900

Nach Windowsupdate kein Zugriff auf Netzwerkfreigabe mehr möglich

Gegrüsst,

nach dem heutigen Update gelingt der Zugriff auf ein Windows 7 Rechner über die Freigabe nicht mehr.
Bis vor diesem Update hat es tadellos funktioniert. Die Einstellungen sind korrekt und alle notwendigen Dienste vorhanden.
Hat jemand ähnliche Erfahrungen mit dem Update heute?

Gruß

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 397581

Url: https://administrator.de/contentid/397581

Ausgedruckt am: 15.11.2024 um 06:11 Uhr

36 Kommentare

Neuester Kommentar

Moin,

kannst Du mal genauer schreiben, wer auf was zugreiffen will und welche Updates du meinst?
Ggfs. mal die SMB Protokolle prüfen, wenn W10/W2012/W2016 beteiligt sein sollte.

Gruss

Moin ,

jap die SMB Protokolle.
Hatte ich letztens auch noch und mir nen Wolf gesucht .

Gruss

Genauer sollte der W7 Rechner kein SMB1 mehr nutzen da das durch die letzten updates auf neueren Systemen deaktiviert wurde.

Zugriff von Windows 7 PCs auf Windows 7 PC mit Freigabe (der das Update hatte).
Heute / Gestern wurden Updates eingespielt, (leider stehen Updates auf Automatisch).
Standard Windows Freigabe. Windows > 7 nicht beteiligt.

Moin,

lass dir doch bitte nicht alles aus der Nase ziehen...
Domäne? Arbeitsgruppe? Eventlog? Fehlermeldung? Welche Updates wurden installiert?

lg,
Slainte

Zitat von @systemwatcher:

Zugriff von Windows 7 PCs auf Windows 7 PC mit Freigabe (der das Update hatte).
Heute / Gestern wurden Updates eingespielt, (leider stehen Updates auf Automatisch).
Standard Windows Freigabe. Windows > 7 nicht beteiligt.

Welche SMB Version wird denn nun verwendet?

Kannst dir einfach in der Shell die Freigaben anzeigen lassen. Dann siehst du es.

//in einer PS: get-smbconnection

Keine Domäne
Fehlermeldung 0x80004005 (unbekannter Fehler) beim Versuch zu verbinden

Bei den Standard Logs sehe ich nichts auffälliges, ggf. weißt Du wo ich genau nachsehen sollte.

Folgende Updates zuletzt
KB4481480 09.01. (Sicherheitsqualitätsrollup für .NET Framework)
KB4480970 09.01. (Monatliches Sicherheitsqualitätsrollup für x64 basierte Systeme)
KB915597 (Windows Defender Definitionen) 08.01

Wie gesagt, sonst keine Änderungen, keine Installationen oder sonstiges, bis dahin keine Probleme.

net share? zeigt nichts an, PS Befehl führt zur Feldermeldung kein cmdlet, Funktion oder Skript erkannt

Zitat von @Spirit-of-Eli:
//in einer PS: get-smbconnection

Gibt es in der W7 PS nicht

Die ist Version 2, wenn sie nicht aktiv aktualisiert wird.

Aktualisiere mal Deine PS oder schau in den Diensten nach, und lass' Dir nicht alles aus der Nase ziehen.
Das ist nun wirklich kein Hexenwerk nach den SMB Versionen zu schauen/google zu nutzen oder die Suche hier im Forum.
Ggfs. deinstalliere das Update und prüfe dann die Verbindung.

Ist überhaupt ein Ping auf den PC möglich, oder scheiter es schon daran?

Zitat von @sabines:

Zitat von @Spirit-of-Eli:
//in einer PS: get-smbconnection

Gibt es in der W7 PS nicht

Die ist Version 2, wenn sie nicht aktiv aktualisiert wird.

Oh, ich habe leider keine W7 Systeme mehr da ;).
Dazu gibt es aber ein cmd pedant, welches ich auch wieder ergooglen müsste..

Servus,

erst einmal Danke für die Bemühungen.
Aus der Nase ziehen lasse ich mir nicht, ich tappe nur selbst im Dunkeln (bin auch nicht direkt an diesem PC, leiste gerade selbst Ferndiagnose).
Das SMB Protokoll wird SMB 1 sein, da bis vor einiger/kurzer Zeit auch XP PC darauf zugegriffen haben und es nie umgestellt wurde.
Ich wüsste auch nicht, dass ein Update das abgeschaltet hat, zumindest bei Windows 7, kann ja nun passiert sein, aber dann sollte doch trotzdem ein Zugriff von Windows 7 PC möglich sein.
Die Aktualisierung ist im Gange wo kann das in den Diensten nachgesehen werden. Soweit ich es gesehen habe ist das unter Windows 7 nicht so direkt möglich. Bei Windows 10 kann das ja in den Features eingestellt werden. Für gewöhnlich wird ja immer das höchstmögliche Protokoll genutzt und nur bei Bedarf runtergestuft (wenn möglich).

Ein Ping funktioniert. Die Verbindung steht also.

Und hier nochmals Google bemüht.

https://support.microsoft.com/de-de/help/2696547/how-to-detect-enable-an ...

Sorry, aber das war nun wirklich nicht schwer auf den Link zu kommen.

Hallo,

wir suchen aktuell auch bei unseren Kunden.
Fall1:

Windows 7 Clients mit Server 2008R2 Workgroup.
Kein Zugriff auf die Netzwerkfreigabe am Server.
ODBC connect funktioniert tadellos

Lösung: Erstmal Updates am Server deinstallieren - ich weiß nicht korrekt aber erstmal schafft das Abhilfe.

Den zweiten Fall schaue ich mir gleich an. Ist auf jeden Fall eine Domäne mit teilweise Windows 10 Clients.
Melde mich gleich wieder.

Sorry, aber das habe ich auch schon gefunden.
Es wurde an dem PC nichts aktiv deaktiviert oder aktiviert.
D.h. Windows 7 PC mit SMB 2.1 und 1.0.
Lediglich bei den Erweiterten Netzwerkeinstellungen wurde die Verschlüsselung auf 56 Bit statt 128 Bit gesetzt.
Aber selbst ein Zurücksetzen auf 128 Bit Verschlüsselung ändert nichts an dem Zustand.
Nochmals Zugriff von einem Windows 7 PC auf einen Windows 7 PC.

NACHTRAG:
Selbst mit neuer Powershell 5.1 kein get-smbconnection...

NACHTRAG2:
Definitiv beide Protokolle aktiv, wenn man der Registry Methode folgt, aber wie gesagt, es wurde nichts deaktiviert.

Zitat von @systemwatcher:

Sorry, aber das habe ich auch schon gefunden.
Es wurde an dem PC nichts aktiv deaktiviert oder aktiviert.
D.h. Windows 7 PC mit SMB 2.1 und 1.0.
Lediglich bei den Erweiterten Netzwerkeinstellungen wurde die Verschlüsselung auf 56 Bit statt 128 Bit gesetzt.
Aber selbst ein Zurücksetzen auf 128 Bit Verschlüsselung ändert nichts an dem Zustand.
Nochmals Zugriff von einem Windows 7 PC auf einen Windows 7 PC.

NACHTRAG:
Selbst mit neuer Powershell 5.1 kein get-smbconnection...

Wird denn nun SMB1 genutzt oder nicht?
Darum geht es doch die ganze Zeit. Im Artikel steht beschrieben wie man dies am Client in Erfahrung bringt.

Die PS Variante wird auch beschrieben.

Aktuell will der PC das Update KB4480970 erneut installieren, obwohl es bereits installiert ist.
Vermutlich hat MS mal wieder ein Bock geschossen.

Wird denn nun SMB1 genutzt oder nicht?
Darum geht es doch die ganze Zeit. Im Artikel steht beschrieben wie man dies am Client in Erfahrung bringt.

Die PS Variante wird auch beschrieben.

Es zeigt nur an, was aktiviert ist und was nicht. Es wurde aber keines der Protokolle deaktiviert.
So wie es der Befehl Get-SMBConnection anzeigen würde, das gibt es nicht auf Windows 7.
Es sind aber beide SMB Protokolle aktiviert. Welches aktiv genutzt wird (oder würde, wenn es geht) kann ich nicht prüfen!

Moin,

als erstes deaktivierst du mal auf beiden W7 Clients SMB V1 und prüfst zur Sicherheit nochmal ob auf beiden(!) SMB V2 aktiviert ist.

Dann sehen wir weiter.

PS: Durchgepatcher W7 Client kann ohne Probleme auf W7 oder W2008 (beide noch Updatestand 12/2018) Freigaben zugreifen.

Gruss

Zitat von @systemwatcher:

NACHTRAG2:
Definitiv beide Protokolle aktiv, wenn man der Registry Methode folgt, aber wie gesagt, es wurde nichts deaktiviert.

Vielleicht nutzt W7 wenn SMB v1 und v2 aktiv sind, per default v1 und vielleicht hat ein Update nun dafür gesorgt, dass v1 geblockt wird. Da nutzt es nichts, dass Du aktiv nichts geändert hast.

Hat jemand schon eine Lösung gefunden? Ich habe testweise auf einem Win10 PC SMB1 wieder aktiviert, kann aber trotzdem den Win7 Share nicht benutzen. Der Win7 PC kann auch trotzdem den Win7 Share nicht nutzen....

Zitat von @sabines:
PS: Durchgepatcher W7 Client kann ohne Probleme auf W7 oder W2008 (beide noch Updatestand 12/2018) Freigaben zugreifen.

Das Problem ist wenn die Freigabe auf einem Windows 7 mit Update 01/2019 (KB4480970 oder KB4480960) liegt, kann das hier definitiv nachvollziehen, nach Update 01/2019 kommt keine SMB2 Verbindung auf eine W7 Share mehr zustande, hier der Wireshark Trace vom Client der auf den W7 Share zugreifen möchte:

Führt immer zur Fehlermeldung Invalid Handle!

Werde mal einige Tests durchführen ...

Nach dem Deinstallieren von (KB4480970 oder KB4480960) funktioniert alles wieder einwandfrei! Es liegt also definitiv an KB4480970/KB4480960.

Windows 7 SP1 and Windows Server 2008 R2 SP1

KB4480970 Monthly Rollup

    Protection against Speculative Story Bypass CVE-2018-3639 for AMD-based computers
    Security updates to Windows Kernel, Windows Storage and Filesystems, Windows Wireless Networking, and the Microsoft JET Database Engine.

-edit-

Wenn der User der auf das W7 zugreift zufällig ein Administrator auf dem Remote-System ist sollte das hier auf dem W7 welches das Share hostet Abhilfe schaffen (elevated cmd):

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Danach zwingend ein Reboot durchführen!

Es tritt also nur auf wenn der User Administrator auf dem System ist welches das Share hostet, solange er normaler User ist alles OK, also hat MS hier das was für die Administrative Shares gilt, nun auf andere Shares ausgeweitet.

Hier die komplette Lösung: Zugriff auf Shares die auf Windows 7 gehostet werden nach Update 01-2019 (KB4480970 oder KB4480960) nicht mehr möglich

Moin,

erst mal wünsche ich dir ein frohes neues Jahr !

Vielleicht hilft dir mein Beitrag weiter, djoin funktioniert auch bei Windows 7 PC.

Windows 10 Version 1803 (17134) Bug ? lässt sich evtl. nicht mehr an die Domäne anmelden

Sorry hatte die Lösung nicht gesehen. ( Rollup KB4480970)

Schöne Grüsse aus dem schönen Emsland.

Werner

AMD-based computers

AMD wie AMD CPUs oder AMD wie AMD64 == alle x64 betriebene Systeme?

Ich habe das Update KB4480970 auf dem betreffendem System deinstalliert, was erstmal Abhilfe geschaffen hat. Ich hoffe da kommt noch eine permanente Lösung.
Was Microsoft sich da manchmal leistet geht mir mehr und mehr auf den Sack.

Zitat von @quotum:

Ich habe das Update KB4480970 auf dem betreffendem System deinstalliert, was erstmal Abhilfe geschaffen hat. Ich hoffe da kommt noch eine permanente Lösung.
Was Microsoft sich da manchmal leistet geht mir mehr und mehr auf den Sack.

Ist dein User der auf das W7 zugreift zufällig Administrator auf dem Remote-System ?

Dann sollte das hier auf dem W7 welches das Share hostet Abhilfe schaffen:

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Danach zwingend ein Reboot durchführen.

Updates auf Auto-Installation gelassen? Naja...ist auch nicht das Wahre.

Zitat von @certifiedit.net:
Updates auf Auto-Installation gelassen? Naja...ist auch nicht das Wahre.

Wieso das denn?
Wie soll ich denn sonst wissen, was ich mir erspart habe, wenn andere nicht für mich testen

Nein, natürlich umgestellt.

Sehr gute Arbeit. Danke.
Ich kann von einem ungepatchen Client auf die Freigabe eines gepatchen Clients zugreifen.
Kann das jemand nachvollziehen?

Zitat von @sabines:

Sehr gute Arbeit. Danke.
Ich kann von einem ungepatchen Client auf die Freigabe eines gepatchen Clients zugreifen.
Kann das jemand nachvollziehen?

S. Ergänzung zum Thema in meinem Kommentar oben.

MS hat offensichtlich das was bisher nur für die Administrative-Shares gegolten nun auf alle anderen Shares ausgeweitet. Ist der User Admin auf System was das Share hostet tritt das Verhalten auf, wenn er normaler User ist nicht.
Das OS und Patchstand des Clients spielt dabei keine Rolle, der Host der das Share hostet ist es.

Hallo Zusammen, habe selbiges Problem.

LAN mit Win 7 pro und Win 10 PC's mit normaler Netzwerkfreigabe.
Nach Deinstallation des Updates läuft es wieder. Habe diese geblockt.

Kann man das SMB1 deaktivieren und die Netzlaufe neu verbinden, damit es läuft oder geht das nicht so einfach?
Win 10 kann ich aufgrund vorn einigen Programmen leider nicht überall installieren.

Besten Dank

Gruß

Das Problem hat ja nichts spezifisch mit SMB1 shares zu tun, sondern tritt bei SMB2 ebenso auf.
Das gleiche wird dann ja auch auf 2008 R2 Servern sein... Gut das die noch nicht geupdated wurden..

Habe hier alles dazu in einem Tipp zusammengefasst:
Zugriff auf Shares die auf Windows 7 gehostet werden nach Update 01-2019 (KB4480970 oder KB4480960) nicht mehr möglich

Es ist also im weiteren Sinne kein Problem sondern nur eine reine Sicherheitsausweitung die sich aber mit Registry-Eintrag aufheben lässt!

Hallo Systemwatcher, ja nun hat es mich auch erwischt. Nach diversen Updates, ist es nicht mehr möglich unsere zwei Win 2008 und Win 2012 zuzugreifen. Auch 6x Win7 Pro Rechner sind davon betroffen. Den Netzwerkzugriff auf die Freigaben auf dem Win 2008 Server konnte ich nun wieder bewerkstelligen, in dem ich alle neu eingespielten Updates wieder deinstalliert habe. Eigentlich fummle ich nicht so gern an laufende Server herum. Ich werde einmal auf einem Server-Klon überprüfen welches Update da faul war. Erst vermutete ich das es ein Viren / Firewall Tool sein könnte. Doch es waren definitive die Updates von Microsoft.
Gruss Norasia