Why does Windows 11 fail to connect to my NAS via SMB after the latest update?

[Jony]

Hi zusammen,

ich habe seit dem letzten Windows 11 Update (23H2, Build 22631.2861) ein Problem mit dem Zugriff auf meinen NAS (Synology DS220+). Vor dem Update lief alles einwandfrei, aber jetzt bekomme ich beim Versuch, eine Netzwerkfreigabe zu verbinden, die Fehlermeldung:

Netzwerkpfad nicht gefunden. \\NAS\Freigabe ist nicht zugänglich.

Ich habe folgende Schritte bereits erfolglos versucht:

• Netzwerkerkennung und Dateifreigabe sind aktiviert (Privates Netzwerkprofil).
• Firewall (Windows Defender) deaktiviert – keine Änderung.
• SMB1 ist deaktiviert (sollte ja auch nicht nötig sein, der NAS unterstützt SMB2/3).
• Anmeldeinformations-Manager: Alte Einträge gelöscht und neu hinzugefügt.
• UNC-Pfad direkt im Explorer eingegeben: \\192.168.1.100\Freigabe – gleicher Fehler.
• Ping auf die NAS-IP funktioniert, auch über den Hostnamen.

Der NAS selbst ist online, andere Geräte (Mac, Smartphone) greifen problemlos zu. Auch ein anderer Windows 10 Rechner im selben Netzwerk hat keine Probleme.

Hat jemand eine Idee, woran das liegen könnte? Liegt es an einer geänderten SMB-Policy in Windows 11? Oder muss ich in den erweiterten Freigabeeinstellungen noch etwas umstellen? Ich bin für jeden Tipp dankbar!

System: Windows 11 Pro 23H2, aktuellste Updates, Netzwerk: LAN (kein WLAN).

 

[WinPower]

Hi zusammen,

ich habe seit dem letzten Windows 11 Update (23H2, Build 22631.2861) ein Problem mit dem Zugriff auf meinen NAS (Synology DS220+). Vor...

Hallo und willkommen im Forum!
Vielen Dank für die detaillierte Beschreibung – das hilft sehr, um das Problem einzugrenzen. Du hast schon viele richtige Schritte unternommen. Dass der Ping funktioniert und andere Geräte problemlos zugreifen, deutet auf eine Windows-spezifische Einstellung hin, die durch das Update beeinflusst wurde.

Hier sind einige weiterführende Ansätze, die du noch prüfen kannst:

1. SMB-Sicherheitseinstellungen überprüfen
Windows 11 hat mit Updates manchmal strengere Vorgaben für SMB-Verbindungen. Insbesondere die SMB-Signierung oder der Gastzugriff können blockiert werden.

• Öffne die Ereignisanzeige (eventvwr.msc)
• Gehe zu *Windows-Protokolle → System* und filtere nach Quelle SMBClient oder MrxSmb
• Suche nach Fehlermeldungen mit Ereignis-ID 31017, 31008 oder 31013

Diese geben oft den genauen Grund an (z. B. „Der SMB-Server unterstützt keine SMB2- oder SMB3-Signierung“ oder „Gastzugriff verweigert“).

2. Gastzugriff in Windows 11 deaktivieren/aktivieren
Seit Windows 10 Version 1803 ist der Gastzugriff standardmäßig deaktiviert. Falls dein NAS Gästezugriff erlaubt, kann das zu Problemen führen.

• Drücke Win + R, gib gpedit.msc ein (nur in Pro/Enterprise)
• Navigiere zu *Computerkonfiguration → Administrative Vorlagen → Netzwerk → Lanman-Arbeitsstationsdienst*
• Aktiviere die Richtlinie Unsichere Gastanmeldungen aktivieren (falls dein NAS Gästezugriff nutzt)
• Starte den PC neu

3. SMB-Protokollversion erzwingen
Manchmal hilft es, die SMB-Version direkt festzulegen. Öffne PowerShell als Administrator und gib ein:
Set-SmbClientConfiguration -EnableSMB2Protocol $true -EnableSMB3Protocol $true
Danach: Set-SmbClientConfiguration -RequireSecuritySignature $false (falls die Signierung das Problem ist)

4. Netzwerkprofil und Freigabeoptionen vertiefen

• Stelle sicher, dass das Netzwerkprofil auf Privat gesetzt ist (Einstellungen → Netzwerk & Internet → Ethernet → Netzwerkprofil).
• Gehe zu *Systemsteuerung → Netzwerk- und Freigabecenter → Erweiterte Freigabeeinstellungen*
• Aktiviere unter *Alle Netzwerke*: Kennwortgeschütztes Freigeben deaktivieren (falls du ohne Benutzeranmeldung zugreifen möchtest)
• Aktiviere Datei- und Druckerfreigabe für das private Netzwerk

5. Netzwerk zurücksetzen (letzter Ausweg)
Wenn nichts hilft, kannst du das Netzwerk zurücksetzen:
Einstellungen → Netzwerk & Internet → Erweiterte Netzwerkeinstellungen → Netzwerk zurücksetzen
Wichtig: Notiere vorher deine WLAN-Passwörter und VPN-Konfigurationen, da diese gelöscht werden. Nach dem Reset musst du die Netzwerkkonfiguration neu einrichten.

6. NAS-seitig prüfen

• Stelle im Synology DSM sicher, dass SMB3 aktiviert ist und Minimum SMB-Protokoll auf SMB2 oder SMB3 gesetzt ist (nicht SMB1).
• Überprüfe, ob der SMB-Dienst unter *Systemsteuerung → Dateidienste → SMB/AFP/NFS* läuft.
• Erstelle testweise eine neue Freigabe mit einem einfachen Namen (ohne Leerzeichen/Sonderzeichen).

7. Windows Update-Rollback testen
Falls alles scheitert, kannst du das letzte Update deinstallieren:
Einstellungen → Windows Update → Update-Verlauf → Updates deinstallieren → KB-Nummer des letzten kumulativen Updates entfernen.
Danach das Update über *Updates anhalten* für 7 Tage pausieren, um zu sehen, ob es am Update lag.

Ich hoffe, einer dieser Schritte hilft dir weiter. Melde dich gern, wenn du die Ereignisanzeige-Fehlermeldung gefunden hast – dann können wir gezielter vorgehen!

 

[Jony]

Hallo und willkommen im Forum!
Vielen Dank für die detaillierte Beschreibung – das hilft sehr, um das Problem einzugrenzen. Du hast schon viele...

Hallo und vielen Dank für die ausführliche Hilfe! Das sind viele gute Ansätze, ich habe schon einige davon getestet.

Ich habe die Ereignisanzeige durchsucht, aber leider keine Einträge mit den genannten IDs (31017, 31008, 31013) gefunden. Es gibt nur allgemeine Netzwerkfehler, aber nichts SMB-spezifisches. Die Gruppenrichtlinie „Unsichere Gastanmeldungen aktivieren“ war bei mir bereits aktiv – ich habe sie also nicht umstellen müssen.

Ich habe auch schon testweise die SMB-Signierung über PowerShell deaktiviert (

Set-SmbClientConfiguration -RequireSecuritySignature $false

), aber das hat nichts geändert. Der Zugriff schlägt weiterhin mit demselben Fehler fehl:

Netzwerkpfad nicht gefunden.

Eine Sache ist mir allerdings aufgefallen: Wenn ich über den Hostnamen zugreife (also

\\NAS\Freigabe

), kommt der Fehler, aber über die IP-Adresse (

\\192.168.1.100\Freigabe

) auch – das war ja bereits so. Allerdings habe ich festgestellt, dass der Zugriff über \\192.168.1.100\Freigabe manchmal kurz funktioniert, wenn ich vorher den DNS-Cache leere (

ipconfig /flushdns

) und dann sofort verbinde. Das ist aber sehr unzuverlässig.

Könnte es sein, dass das Update etwas an der Netzwerkprofileinstellung geändert hat? Ich habe bereits sichergestellt, dass mein LAN-Profil auf Privat steht, aber vielleicht ist da noch irgendwo eine versteckte Änderung? Oder gibt es noch eine andere Möglichkeit, das SMB-Problem gezielt zu analysieren?

Ich bin gespannt auf deine Einschätzung – danke im Voraus!

 

[WinPower]

Hallo und vielen Dank für die ausführliche Hilfe! Das sind viele gute Ansätze, ich habe schon einige davon getestet.

Ich habe die Ereignisanzeige...

Hallo! Danke für die Rückmeldung und deine Geduld – das ist wirklich ein kniffliger Fall.
Die Tatsache, dass der Zugriff nach einem DNS-Cache-Flush kurzzeitig funktioniert, ist ein sehr wichtiger Hinweis. Das deutet darauf hin, dass das Problem nicht primär bei SMB selbst liegt, sondern eher bei der Namensauflösung oder der Netzwerkprofil-Zuordnung.

Hier sind einige gezielte Schritte, die auf dieses Symptom abzielen:

1. Netzwerkprofil und versteckte Einstellungen prüfen
Windows speichert Netzwerkprofile in der Registry. Ein Update kann hier manchmal ungewollte Änderungen hinterlassen.

Öffne die Registry (Win + R → regedit) und navigiere zu:
HKEYLOCALMACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

Dort findest du mehrere Profile (GUIDs). Prüfe bei jedem Profil den Wert ProfileName und Category:
Category = 0 (Öffentlich) oder 1 (Privat)
Setze das aktive Profil (das mit deinem LAN verbunden ist) auf Category = 1 (Privat) und starte den PC neu.

Achtung: Ändere nur die Werte, wenn du dir sicher bist. Notiere dir vorher die Originalwerte.

2. DNS-Client-Cache und Netzwerkadapter zurücksetzen
Da der Flush kurz hilft, könnte der DNS-Client oder der Netzwerkadapter selbst das Problem sein.

Öffne PowerShell als Administrator und führe aus:
ipconfig /flushdns
ipconfig /registerdns
netsh int ip reset
netsh winsock reset

Danach den PC neu starten. Das setzt die IP- und Socket-Konfiguration zurück, ohne deine Netzwerkeinstellungen zu löschen.

3. SMB-Client-Protokoll und Netzwerkadapter-Einstellungen
Manchmal hilft es, den Netzwerkadapter auf „Auto-Negotiation“ zu stellen oder die Energieverwaltung zu deaktivieren, da das Update möglicherweise die Treibereinstellungen geändert hat.

Geräte-Manager → Netzwerkadapter → Eigenschaften → Energieverwaltung
Deaktiviere „Computer kann das Gerät deaktivieren, um Energie zu sparen“
Gehe zu Erweitert und stelle sicher, dass „Energy Efficient Ethernet“ auf Deaktiviert steht (falls vorhanden).

4. SMB-Client-Protokoll direkt zurücksetzen
Setze die SMB-Client-Konfiguration auf die Standardwerte zurück:
Set-SmbClientConfiguration -EnableSMB1Protocol $false
Set-SmbClientConfiguration -EnableSMB2Protocol $true
Set-SmbClientConfiguration -EnableSMB3Protocol $true
Set-SmbClientConfiguration -RequireSecuritySignature $true (Standardwert)
Set-SmbClientConfiguration -EnableInsecureGuestLogons $false

Danach den PC neu starten und testen.

5. Netzwerkadapter-Treiber aktualisieren oder zurücksetzen
Da das Problem nach einem Update auftrat, könnte der Treiber inkompatibel sein.

Lade den aktuellen Treiber direkt vom Hersteller deines Mainboards/Laptops herunter (nicht über Windows Update).
Alternativ: Geräte-Manager → Netzwerkadapter → Treiber → „Treiber zurücksetzen“ (falls verfügbar) oder „Deinstallieren“ und dann „Nach geänderter Hardware suchen“.

6. Wireshark oder Netzwerkmonitor zur Analyse
Wenn du technisch tiefer gehen möchtest, kannst du mit Wireshark (kostenlos) den Netzwerkverkehr während des Verbindungsversuchs aufzeichnen.

Starte Wireshark, wähle dein LAN-Interface und filtere auf smb2 oder smb
Versuche dann, die Freigabe zu verbinden.
Achte auf Fehlermeldungen wie STATUSBADNETWORKNAME oder STATUSACCESS_DENIED – das zeigt, ob das Problem auf Protokollebene liegt.

7. Windows-Update-Rollback als Test
Falls alle Stricke reißen, deinstalliere das letzte kumulative Update (Einstellungen → Windows Update → Update-Verlauf → Updates deinstallieren).

Wähle das neueste KB-Update und starte neu. Wenn der Zugriff danach funktioniert, liegt es definitiv am Update – dann kannst du es erneut installieren und die Fehlersuche gezielt fortsetzen.

Ich hoffe, diese erweiterten Schritte helfen dir weiter! Besonders der Registry-Eingriff und der Treiber-Reset könnten den entscheidenden Unterschied machen. Melde dich gern, falls du weitere Beobachtungen machst – wir kommen dem Übeltäter bestimmt auf die Spur!

 

[Jony]

Hallo! Danke für die Rückmeldung und deine Geduld – das ist wirklich ein kniffliger Fall.
Die Tatsache, dass der Zugriff nach einem...

Gute Ideen! Ich habe die Registry überprüft – die Kategorie war tatsächlich auf 0 (Öffentlich) gesetzt, obwohl ich in den Einstellungen "Privates Netzwerk" ausgewählt hatte. Habe sie auf 1 geändert, aber nach dem Neustart sprang sie wieder auf 0 zurück.

Dann habe ich mein LAN-Profil gelöscht (Profil in der Registry entfernt) und Windows neu gestartet. Danach wurde das Netzwerk als "Öffentlich" erkannt und ich habe es wieder auf "Privat" umgestellt. Jetzt scheint die Kategorie stabil zu bleiben. Aber der Zugriff auf den NAS klappt immer noch nicht – gleicher Fehler.

Ich befürchte, das Problem liegt tiefer. Vielleicht hat das Update wirklich den SMB-Client beschädigt oder eine Group Policy überschrieben. Wäre es sinnvoll, direkt den SMB-Client komplett zu deinstallieren und neu zu installieren? Oder gibt es noch eine andere Idee?

Danke für deine Hilfe!

 

[WinPower]

Gute Ideen! Ich habe die Registry überprüft – die Kategorie war tatsächlich auf 0 (Öffentlich) gesetzt, obwohl ich in den Einstellungen "Privates...

Hallo! Das ist wirklich frustrierend – ich verstehe deinen Ärger. Dass die Registry-Kategorie zurückgesprungen ist, deutet auf eine aktive Gruppenrichtlinie oder ein Skript hin, das das Netzwerkprofil überschreibt. Aber da du das Profil gelöscht und neu erstellt hast, sollte das erstmal stabil sein. Dennoch bleibt der Zugriff verwehrt – das spricht für ein tiefer liegendes Problem mit dem SMB-Client oder der Systemkonfiguration.

Hier sind die nächsten, gezielten Schritte:

1. SMB-Client deinstallieren und neu installieren (über Windows-Features)
Öffne *Systemsteuerung → Programme und Features → Windows-Features aktivieren oder deaktivieren*
Deaktiviere den Haken bei *SMB 1.0/CIFS-Dateifreigabeunterstützung* (falls aktiviert) – das ist nicht nötig und kann stören.
Scrolle zu *Unterstützung für SMB-Dateifreigabe* (oder ähnlich) und deaktiviere es kurz, starte den PC neu, aktiviere es dann wieder und starte erneut.
Das setzt den SMB-Client zurück, ohne dass du Treiber manuell entfernen musst.

2. Systemdateien reparieren (SFC und DISM)
Öffne PowerShell als Administrator und führe nacheinander aus:

sfc /scannow

DISM /Online /Cleanup-Image /RestoreHealth

Nach Abschluss beider Befehle den PC neu starten. Das repariert beschädigte Systemdateien, die durch das Update entstanden sein könnten.

3. SMB-Dienste prüfen und zurücksetzen
Öffne *Dienste (services.msc) und stelle sicher, dass folgende Dienste laufen und auf Automatisch* gesetzt sind:
- Server (LanmanServer)
- Workstation (LanmanWorkstation)
- TCP/IP NetBIOS Helper
Starte sie ggf. neu.

Setze dann die SMB-Client-Konfiguration komplett zurück (PowerShell als Admin):

Set-SmbClientConfiguration -EnableSMB1Protocol $false
 Set-SmbClientConfiguration -EnableSMB2Protocol $true
 Set-SmbClientConfiguration -EnableSMB3Protocol $true
 Set-SmbClientConfiguration -RequireSecuritySignature $true
 Set-SmbClientConfiguration -EnableInsecureGuestLogons $false
 Set-SmbClientConfiguration -DisableCompression $true

Starte den PC neu.

4. Group Policy zurücksetzen (falls du Pro/Enterprise hast)
Öffne *Eingabeaufforderung als Administrator* und gib ein:

gpupdate /force

Danach:

gpresult /h C:\gpresult.html

Öffne die erstellte HTML-Datei und suche nach Richtlinien, die *Netzwerk oder SMB betreffen. Falls du eine Richtlinie siehst, die das Netzwerkprofil auf Öffentlich* setzt, müsstest du diese in der lokalen Gruppenrichtlinie (gpedit.msc) oder über die Registry deaktivieren.

Speziell: *Computerkonfiguration → Windows-Einstellungen → Sicherheitseinstellungen → Netzwerklisten-Manager-Richtlinien* – dort kann ein Netzwerkprofil erzwungen werden.

5. Netzwerkadapter-Treiber komplett neu installieren
Lade den neuesten Treiber für deinen LAN-Chip (z. B. Realtek, Intel) direkt vom Hersteller.
Deinstalliere im Geräte-Manager den Netzwerkadapter (Haken bei *Treibersoftware löschen* setzen).
Starte den PC neu – Windows installiert den Treiber automatisch neu. Installiere dann den heruntergeladenen Treiber.

6. Letzter Ausweg: In-Place-Upgrade (Reparaturinstallation)
Falls alles scheitert, kannst du Windows 11 mit einem In-Place-Upgrade reparieren, ohne Daten zu verlieren:
Lade das Media Creation Tool von Microsoft, starte es und wähle *Upgrade dieses PC jetzt*.
Folge den Schritten – dabei werden Systemdateien ersetzt, aber deine Apps und Dateien bleiben erhalten.
Das behebt oft hartnäckige Probleme nach Updates.

Ich hoffe, einer dieser Schritte bringt den Durchbruch! Besonders die SMB-Client-Neuinstallation über Windows-Features und die Systemdateireparatur sind vielversprechend. Melde dich gern mit dem Ergebnis – wir bleiben dran!

 

[Jony]

Hallo! Das ist wirklich frustrierend – ich verstehe deinen Ärger. Dass die Registry-Kategorie zurückgesprungen ist, deutet auf eine aktive...

Hi, danke für die detaillierte Anleitung! Habe jetzt etliche deiner Vorschläge durchprobiert:

• SMB 1.0 deaktiviert (war eh aus) und den Client über Windows-Features zurückgesetzt. Leider keine Änderung.
• SFC und DISM durchgeführt – keine Fehler gefunden, Systemdateien sind angeblich intakt.
• Dienste alle auf automatisch und laufen.
• Group Policy zurückgesetzt und geprüft – keine auffälligen Richtlinien gefunden.
• Treiber (Realtek) frisch vom Hersteller installiert – kein Erfolg.

Der Zugriff schlägt bei mir nach wie vor mit dem gleichen Fehler fehl. Ping funktioniert, Zugriff von anderen Geräten im selben Netzwerk funktioniert.

Ich bin langsam echt ratlos. Was mich wundert: Der Zugriff über die IP-Adresse (\\192.168.1.100\Freigabe) liefert ebenfalls den Fehler. Normalerweise wäre das ja der "härteste" Test.

Gibt es vielleicht noch eine Möglichkeit, die SMB-Kommunikation direkt zu testen? Oder könnte das Update tatsächlich den SMB-Client korrupt gemacht haben, ohne dass SFC/DISM das erkennt?

Danke für die Hilfe!

 

[WinPower]

Hi, danke für die detaillierte Anleitung! Habe jetzt etliche deiner Vorschläge durchprobiert:


SMB 1.0 deaktiviert (war eh aus) und den Client über...

Hallo! Ich verstehe deine Frustration – du hast wirklich alles durchprobiert, und der Fehler bleibt hartnäckig. Doch keine Sorge, es gibt noch einige spezifischere Diagnose-Schritte, die wir gehen können, um dem SMB-Client auf den Grund zu gehen.

Da der Zugriff sowohl per Hostname als auch per IP scheitert, liegt das Problem definitiv auf SMB-Ebene oder tiefer im Netzwerkstack. Hier sind die nächsten, gezielten Maßnahmen:

1. SMB-Port direkt testen
Zuerst prüfen wir, ob Windows den SMB-Port (TCP 445) überhaupt erreichen kann. Öffne PowerShell als Administrator und gib ein:

Test-NetConnection 192.168.1.100 -Port 445

Was zeigt die Ausgabe?

• TcpTestSucceeded: True – dann liegt es am SMB-Client selbst, nicht an der Firewall/Netzwerk.
• TcpTestSucceeded: False – Firewall, Router oder NAS blockieren den Port (trotz deaktivierter Defender-Firewall könnte eine Dritt-Firewall oder der Router dazwischen sein).

Ergänzend: netstat -an | findstr 192.168.1.100:445 zeigt, ob eine Verbindung aufgebaut wird.

2. SMB-Client-Protokoll in der Ereignisanzeige aktivieren
Standardmäßig loggt der SMB-Client nur kritische Fehler. Aktiviere die erweiterte Protokollierung:

wevtutil sl Microsoft-Windows-SmbClient/Operational /e:true

Dann versuche erneut den Zugriff auf die Freigabe, wechsle in die Ereignisanzeige (eventvwr.msc) zu *Anwendungs- und Dienstprotokolle → Microsoft → Windows → SmbClient* und suche dort nach Fehlermeldungen.

3. SMB-Client-Kommunikation per Befehl testen
Nutze den Befehl net use mit Prüfung der genauen Fehlercodes:

net use * \\192.168.1.100\Freigabe /user:BENUTZERNAME

Notiere dir die genaue Fehlernummer (z. B. 53, 64, 85, 1231, 1312) – das hilft bei der gezielten Suche.

4. SMB1 doch testweise aktivieren?
Obwohl du SMB1 nicht nutzen willst, könnte ein kurzer Test Aufschluss geben: Aktiviere SMB1 temporär (Windows-Features), starte neu und versuche den Zugriff. Falls es dann funktioniert, liegt eine Inkompatibilität mit SMB2/3 vor (z. B. Signierung oder Versionsaushandlung). Danach SMB1 wieder deaktivieren.

5. Netzwerkstack komplett zurücksetzen (erweiterte Variante)
Führe in PowerShell (Admin) folgende Befehle in genau dieser Reihenfolge aus:

netsh int ip reset C:\resetlog.txt
netsh int tcp reset
netsh int ipv4 reset
netsh winsock reset
ipconfig /flushdns
ipconfig /release
ipconfig /renew

Dann PC neu starten.

6. SMB-Direktverbindung über Port 445 per Telnet testen
Aktiviere Telnet-Client (Windows-Features) und teste:

telnet 192.168.1.100 445

Wenn ein leerer Bildschirm erscheint (oder Text), ist die Verbindung erfolgreich. Wenn „Verbindungsfehler“ oder Timeout, blockiert etwas den Port.

7. NAS-seitig gegenseitige SMB-Version erzwingen
Stelle auf dem Synology DSM unter *Dateidienste → SMB → Erweitert die Minimale SMB-Protokollversion auf SMB2 und Maximale auf SMB3. Deaktiviere dort auch alle unnötigen Optionen wie Unterstützung für SMB-Throughput oder SMB-Compression*.

8. Letzte Option: Inplace-Upgrade
Falls alles nichts hilft, bleibt nur noch ein Inplace-Upgrade (Reparaturinstallation), das das System ohne Datenverlust komplett aktualisiert. Lade das Media Creation Tool, starte es und wähle *Upgrade dieses PC jetzt*. Das ersetzt alle Windows-Komponenten und behebt selbst hartnäckige SMB-Probleme. Vorher aber unbedingt ein vollständiges Backup machen (nicht zwingend nötig, aber sicherheitshalber).

Ich bin gespannt, was der Port-Test und die Ereignisanzeige ergeben. Sobald du die Ergebnisse hast, können wir noch gezielter vorgehen. Du schaffst das!

 

[Jony]

Hallo! Ich verstehe deine Frustration – du hast wirklich alles durchprobiert, und der Fehler bleibt hartnäckig. Doch keine Sorge, es gibt noch...

Hallo, danke für die vielen neuen Ansätze! Ich habe einige davon getestet und hier sind die Ergebnisse:

• Test-NetConnection 192.168.1.100 -Port 445: Zeigt TcpTestSucceeded: True an – der Port ist also erreichbar.
• net use * \\192.168.1.100\Freigabe /user:MeinBenutzer: Fehler 53 – Der Netzwerkpfad wurde nicht gefunden.
• Ereignisanzeige (SmbClient operational): Nach Aktivierung des Logs und erneutem Zugriffsversuch finde ich nur einen Eintrag mit ID 1000 (Client verbunden), aber keinen Fehler.
• SMB1 testweise aktiviert: Keine Änderung – gleicher Fehler 53.
• Telnet 192.168.1.100 445: Es erscheint ein leerer Bildschirm (kein Timeout), also ist die Verbindung grundsätzlich möglich.
• Netzwerkstack komplett zurückgesetzt (netsh int ip reset etc.): Hat leider auch nichts gebracht.

Ich bin langsam echt am Verzweifeln. Der Port ist offen, Telnet funktioniert, aber SMB selbst scheint zu blockieren. Gibt es noch eine Möglichkeit, den SMB-Client auf Werkseinstellungen zurückzusetzen, ohne Windows neu zu installieren? Oder könnte es sein, dass eine kürzlich installierte Drittanbieter-Software (z. B. VPN oder Antivirus) den SMB-Client kapert? Ich habe zwar keine aktive VPN-Verbindung, aber vielleicht hängt da noch ein Treiber im System.

Hat jemand eine Idee, wie ich herausfinden kann, welcher Filtertreiber oder welche Komponente den SMB-Client stört? Danke für jede weitere Hilfe!

 

[WinPower]

Hallo, danke für die vielen neuen Ansätze! Ich habe einige davon getestet und hier sind die Ergebnisse:


Test-NetConnection 192.168.1.100 -Port 445:...

Hallo! Das ist wirklich ein hartnäckiger Fall – aber die Ergebnisse bringen uns jetzt auf die richtige Spur!

Der Fehler 53 bei gleichzeitig erfolgreichem Telnet auf Port 445 ist ein starkes Indiz dafür, dass der SMB-Client selbst blockiert wird – nicht der Netzwerkpfad. Deine Vermutung mit den Filtertreibern ist absolut berechtigt! Hier sind die nächsten, gezielten Schritte:

1. Filtertreiber identifizieren
Öffne PowerShell als Administrator und gib ein:

fltmc filters

Das zeigt alle aktiven Filtertreiber. Achte besonders auf Einträge von:

• Antivirus-/Security-Software (z. B. Sophos, Trend Micro, Bitdefender)
• VPN-Clients (z. B. Cisco AnyConnect, OpenVPN, WireGuard)
• Backup- oder Verschlüsselungssoftware

2. SMB-Client-Treiber prüfen
Der SMB-Client nutzt den Treiber mrxsmb.sys und mrxsmb20.sys. Prüfe deren Status:

sc query mrxsmb
sc query mrxsmb20

Beide sollten den Status RUNNING zeigen. Falls nicht, starte sie:

sc start mrxsmb
sc start mrxsmb20

3. Bootzeit-Protokollierung aktivieren
Aktiviere die Bootzeit-Protokollierung, um zu sehen, welche Treiber beim Start geladen werden:

bcdedit /set bootlog on

Danach neu starten. Die Datei C:\Windows\ntbtlog.txt zeigt dann alle geladenen Treiber. Suche nach SMB-bezogenen Einträgen.

4. Drittanbieter-Software im Clean Boot testen
Führe einen Clean Boot durch, um zu sehen, ob eine Drittanbieter-Software das Problem verursacht:

msconfig → Dienste → Alle Microsoft-Dienste ausblenden → Alle deaktivieren
Autostart-Programme über Task-Manager deaktivieren
Neu starten und SMB-Zugriff testen

Falls es dann funktioniert, aktiviere die Dienste nach und nach wieder, um den Übeltäter zu finden.

5. SMB-Client-Komponenten manuell zurücksetzen
Setze die SMB-Client-Konfiguration auf die absoluten Werkseinstellungen zurück:

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "EnableSecuritySignature" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "RequireSecuritySignature" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "EnableInsecureGuestLogons" -ErrorAction SilentlyContinue

Danach neu starten.

6. Netzwerkadapter-Treiber im abgesicherten Modus testen
Starte im abgesicherten Modus (msconfig → Boot → Abgesicherter Modus → Minimal) und versuche den SMB-Zugriff. Falls es dort funktioniert, liegt es definitiv an einem Treiber oder Dienst, der im Normalmodus geladen wird.

7. Wireshark-Diagnose (fortgeschritten)
Installiere Wireshark und filtere während des Verbindungsversuchs auf smb2 oder smb. Du solltest sehen:

• SMB2 Negotiate Request → Response
• SMB2 Session Setup Request → Response

Wenn du nur Requests siehst, aber keine Responses, blockiert ein Filtertreiber die Antworten.

8. Letzte Rettung: Inplace-Upgrade
Falls alles nichts hilft, bleibt nur noch das Inplace-Upgrade (Reparaturinstallation). Das ersetzt alle Systemkomponenten, ohne deine Daten zu löschen. Lade das Media Creation Tool, starte es und wähle „Upgrade diesen PC jetzt“.

Ich bin mir ziemlich sicher, dass der Clean Boot oder die Filtertreiber-Analyse den Übeltäter finden wird. Melde dich mit den Ergebnissen von fltmc filters und dem Clean Boot – dann sehen wir weiter! Du bist auf dem richtigen Weg!

 

[Jony]

Hallo! Das ist wirklich ein hartnäckiger Fall – aber die Ergebnisse bringen uns jetzt auf die richtige Spur!

Der Fehler 53 bei gleichzeitig...

Perfekt, das ist ein riesiger Fortschritt! Der Clean Boot hat also funktioniert – das bedeutet, wir haben den Übeltäter auf eine Drittanbieter-Software eingegrenzt. Jetzt geht es darum, genau herauszufinden, welcher Dienst oder welches Autostart-Programm den SMB-Client blockiert.

Hier ist die bewährte Methode, um den Verursacher zu identifizieren:

1. Systematische Aktivierung der Dienste
- Starte msconfig und wechsle zum Reiter „Dienste“.
- Aktiviere die Hälfte der deaktivierten Drittanbieter-Dienste (einfach per Haken setzen).
- Starte den PC neu und teste den SMB-Zugriff.
- Funktioniert es nicht mehr? Dann ist der Übeltäter in dieser Gruppe. Teile die Gruppe erneut und wiederhole den Vorgang (binäre Suche).
- Funktioniert es weiterhin? Dann ist der Fehler in der anderen Hälfte. Aktiviere die andere Hälfte und wiederhole den Test.

2. Autostart-Programme nicht vergessen
- Falls die Dienste alle okay sind, liegt es an einem Autostart-Eintrag.
- Aktiviere im Task-Manager unter „Autostart“ ebenfalls die Hälfte der deaktivierten Programme und starte neu.
- Gleiches Vorgehen wie bei den Diensten.

3. Typische Kandidaten
- Halte besonders Ausschau nach:
- VPN-Clients (Cisco AnyConnect, OpenVPN, NordVPN, etc.)
- Antivirus-/Firewall-Suiten (auch wenn die Windows-Firewall deaktiviert war)
- Backup-Software (Acronis, Veeam, etc.)
- Tools zur Netzwerkoptimierung oder -verschlüsselung
- Ältere SMB- oder DFÜ-Software

4. Alternative: Process Monitor
- Falls die binäre Suche zu aufwendig ist, kannst du auch Process Monitor von Sysinternals nutzen.
- Starte es, filtere auf mrxsmb.sys oder mrxsmb20.sys und beobachte, welcher Prozess beim Zugriffsversuch auf den SMB-Treiber zugreift. Das erfordert aber etwas Einarbeitung.

Ich bin gespannt, was du findest! Sobald du den Dienst oder das Programm identifiziert hast, können wir gezielt entscheiden, ob du es deinstallieren, aktualisieren oder nur dessen SMB-bezogene Komponente deaktivieren kannst.

 

[WinPower]

Perfekt, das ist ein riesiger Fortschritt! Der Clean Boot hat also funktioniert – das bedeutet, wir haben den Übeltäter auf eine...

Hallo! Vielen Dank für diese hervorragende Zusammenfassung – du hast die Methode perfekt beschrieben! Die binäre Suche ist wirklich die effektivste Methode, um den Übeltäter zu identifizieren, ohne unnötig viele Neustarts zu machen.

Ich möchte noch einige praktische Ergänzungen hinzufügen, die dir die Arbeit erleichtern können:

Erweiterte Tipps für die systematische Suche

1. Dienstabhängigkeiten beachten: Manche Dienste starten nur, wenn ein anderer Dienst aktiv ist. Aktiviere daher immer ganze Gruppen auf einmal, um Abhängigkeiten nicht zu übersehen.

2. Export der Dienstliste: Vor dem Clean Boot: sc query state= all > C:\Dienste_vorher.txt in PowerShell. Nach der Aktivierung einer Gruppe erneut exportieren – so hast du immer eine Referenz.

3. Autostart-Programme nicht vergessen: Falls die Dienste unauffällig bleiben, liegt es mit hoher Wahrscheinlichkeit an Autostart-Einträgen. Besonders tückisch sind:
- VPN-Clients wie Cisco AnyConnect, Pulse Secure, GlobalProtect – diese installieren oft Netzwerkfilter
- Antivirus-Lösungen wie Bitdefender, Kaspersky, McAfee – sie können SMB-Pakete abfangen
- Backup-Tools wie Acronis True Image oder Veeam – sie greifen tief in das Dateisystem ein

4. Schnelltest ohne Neustart: Für Dienste, die keine Abhängigkeiten haben, kannst du auch im laufenden Betrieb testen:
- Dienst starten: net start "Dienstname"
- Zugriff testen
- Dienst stoppen: net stop "Dienstname"
Das spart Zeit, ist aber nicht bei allen Diensten zuverlässig.

Falls die binäre Suche zu langwierig ist: Process Monitor

1. Lade Process Monitor von Microsoft Sysinternals herunter
2. Starte es als Administrator
3. Setze einen Filter: Process Name ist smb.exe oder Pfad enthält smb
4. Versuche den Zugriff auf die NAS-Freigabe
5. Beobachte, welcher Prozess auf Dateien oder Registry-Schlüssel zugreift – oft siehst du dort direkt die blockierende Software

Nach der Identifizierung

Wenn du den Übeltäter gefunden hast, gibt es verschiedene Lösungswege:

• Deaktivieren: Dienst auf „Manuell“ oder „Deaktiviert“ setzen, wenn die Funktion nicht benötigt wird
• Aktualisieren: Viele Hersteller haben inzwischen Patches für Windows 11 23H2 veröffentlicht
• Einstellungen anpassen: In der Software selbst nach einer Option suchen, die SMB-Client-Überwachung deaktiviert (z. B. „Netzwerkfilter“ oder „SMB-Protokoll“ ausschalten)
• Kompatibilitätsmodus: Als letzten Versuch die Software im Kompatibilitätsmodus für Windows 10 ausführen

Du bist auf einem sehr guten Weg! Sobald du den Verursacher gefunden hast, melde dich gern mit dem Namen – dann kann ich dir gezielt helfen, das Problem dauerhaft zu lösen, ohne die gesamte Software zu deinstallieren. Viel Erfolg!

 

[Jony]

Hallo! Vielen Dank für diese hervorragende Zusammenfassung – du hast die Methode perfekt beschrieben! Die binäre Suche ist wirklich die effektivste...

Danke für die ausführliche Antwort! Ich habe die binäre Suche durchgeführt und den Übeltäter gefunden: Es war der Dienst Cisco AnyConnect Secure Mobility Client (vpnagent). Nachdem ich ihn deaktiviert habe, funktioniert der SMB-Zugriff auf den NAS sofort wieder!

Ich hatte AnyConnect zwar nicht aktiv verbunden, aber der Dienst lief offenbar im Hintergrund und hat den SMB-Client blockiert. Das erklärt auch, warum der Clean Boot funktioniert hat.

Jetzt habe ich zwei Optionen:
1. Den Dienst dauerhaft deaktivieren (brauche AnyConnect nur selten)
2. AnyConnect aktualisieren – vielleicht gibt es einen Patch für Windows 11 23H2?

Welchen Weg würdest du empfehlen? Und falls ich den Dienst deaktiviere – reicht es, ihn auf "Manuell" zu setzen, oder sollte ich ihn ganz deaktivieren? Danke nochmal für die tolle Hilfe!

 

[WinPower]

Danke für die ausführliche Antwort! Ich habe die binäre Suche durchgeführt und den Übeltäter gefunden: Es war der Dienst Cisco AnyConnect Secure...

Hallo! Das ist eine fantastische Nachricht – herzlichen Glückwunsch zur erfolgreichen Fehlersuche! Dass der Cisco AnyConnect-Dienst im Hintergrund den SMB-Client blockiert, ist ein klassischer Fall, den viele Nutzer erleben. Gut, dass du ihn gefunden hast.

Zu deiner Frage: Beide Optionen sind valide, aber ich empfehle dir eine differenzierte Lösung:

Empfehlung: Dienst auf „Manuell“ setzen (nicht deaktivieren)

Warum?

• AnyConnect wird von Unternehmen oft für sichere VPN-Verbindungen genutzt. Wenn du ihn nur selten brauchst, ist „Manuell“ die beste Wahl: Der Dienst startet nur, wenn du ihn explizit benötigst (z. B. über die AnyConnect-GUI oder per Befehl).
• „Deaktiviert“ verhindert, dass der Dienst jemals startet – auch wenn du ihn mal brauchst. Das könnte zu Problemen führen, wenn dein Unternehmen ein VPN-Update oder eine Richtlinie durchsetzt.

So stellst du es ein:
1. Öffne services.msc (Win + R → services.msc)
2. Suche den Dienst Cisco AnyConnect Secure Mobility Client (oder vpnagent)
3. Rechtsklick → Eigenschaften → Starttyp: Manuell
4. Klicke auf „Stopp“, falls der Dienst noch läuft
5. OK

Jetzt kannst du AnyConnect jederzeit manuell starten (z. B. über die Cisco AnyConnect-Oberfläche), und nach Beendigung der VPN-Sitzung stoppt der Dienst automatisch wieder. Der SMB-Zugriff bleibt dann dauerhaft erhalten.

Wichtiger Hinweis:
Wenn du AnyConnect über die GUI startest, wird der Dienst automatisch aktiviert. Nach dem Trennen der VPN-Verbindung solltest du prüfen, ob der Dienst noch läuft (services.msc). Falls ja, stoppe ihn manuell, um SMB nicht zu blockieren. Du kannst auch ein kleines Batch-Skript erstellen, das den Dienst nach der VPN-Nutzung stoppt:

net stop vpnagent

Alternativ: AnyConnect aktualisieren
Falls du die neueste Version von Cisco AnyConnect installierst (z. B. 4.10.x oder höher), könnte der SMB-Konflikt bereits behoben sein. Cisco hat in den letzten Versionen einige Kompatibilitätsprobleme mit Windows 11 gefixt. Allerdings ist das keine Garantie – und ein Update könnte auch neue Probleme bringen. Wenn du die Möglichkeit hast, ein Update durchzuführen, teste es in einer ruhigen Minute.

Falls du den Dienst doch deaktivieren möchtest:
Das ist nur sinnvoll, wenn du AnyConnect wirklich nie nutzt. Stelle den Starttyp auf Deaktiviert und starte den PC neu. Bedenke aber: Falls dein Unternehmen eine Richtlinie zur Installation von AnyConnect hat, könnte der Dienst bei einem Update oder einer Gruppenrichtlinie wieder aktiviert werden.

Zusammenfassung:

• Manuell = flexibel, sicher, SMB bleibt frei
• Deaktiviert = radikal, aber nur bei absolutem Nichtgebrauch
• Update = optional, könnte das Problem dauerhaft beheben

Ich persönlich würde den Dienst auf „Manuell“ setzen und bei Bedarf manuell starten. So hast du die Kontrolle und der SMB-Zugriff bleibt stabil.

Ganz großes Lob für deine Ausdauer und systematische Vorgehensweise! Du hast dir das Wissen jetzt wirklich erarbeitet. Falls noch Fragen auftauchen – ich bin für dich da.

 

[Jony]

Hallo! Das ist eine fantastische Nachricht – herzlichen Glückwunsch zur erfolgreichen Fehlersuche! Dass der Cisco AnyConnect-Dienst im Hintergrund...

Freut mich riesig, dass du den Übeltäter gefunden hast! Der Cisco AnyConnect-Dienst ist echt ein bekanntes Ärgernis – viele haben genau das gleiche Problem. Ich hatte vor einiger Zeit auch so einen Fall mit einem VPN-Client, der im Hintergrund den SMB-Zugriff blockiert hat, obwohl keine aktive Verbindung bestand.

Zu deiner Frage: Ich persönlich würde den Dienst auf Manuell setzen, nicht deaktivieren. Warum? Ganz einfach: Wenn du AnyConnect doch mal brauchst (z. B. für die Arbeit oder ein wichtiges Projekt), startest du es einfach per GUI, und der Dienst läuft dann. Nach dem Trennen der VPN-Verbindung kannst du ihn entweder manuell stoppen oder einfach laufen lassen – aber dann blockiert er wieder SMB. Also besser nach der Nutzung per net stop vpnagent beenden. Ein Kollege von mir hat sich dafür ein kleines Batch-Skript gemacht, das er nach der VPN-Sitzung ausführt – klappt super.

Ein Update von AnyConnect könnte das Problem theoretisch beheben, aber ich würde nicht darauf wetten. Cisco hat zwar in den letzten Versionen einige Windows-11-Kompatibilitätsprobleme gefixt, aber solche SMB-Konflikte sind oft tief im Treiberstack verwurzelt. Wenn du die Möglichkeit hast, das Update zu testen, mach es – aber sei nicht enttäuscht, wenn es nichts bringt.

Deaktivieren würde ich nur, wenn du AnyConnect wirklich nie wieder brauchst. Aber selbst dann: Manchmal setzen Firmen-Richtlinien den Dienst über Gruppenrichtlinien zurück, und dann stehst du wieder vor dem Problem.

Also mein Tipp: Manuell und bei Bedarf starten. Das ist der sauberste Weg, ohne die Flexibilität zu verlieren. Und falls du mal wieder Probleme bekommst, weißt du ja jetzt, wo du suchen musst.

Danke fürs Teilen deiner Lösung – das hilft bestimmt auch anderen, die hier mitlesen!

 

[WinPower]

Freut mich riesig, dass du den Übeltäter gefunden hast! Der Cisco AnyConnect-Dienst ist echt ein bekanntes Ärgernis – viele haben genau das gleiche...

Hallo! Vielen herzlichen Dank für deine ausführliche Rückmeldung und die Bestätigung! Es freut mich riesig, dass die Lösung mit dem Dienst auf „Manuell“ für dich funktioniert und du den Übeltäter gefunden hast. Deine Erfahrung mit dem Batch-Skript ist ein echter Profi-Tipp – das werde ich mir merken und bei ähnlichen Fällen weiterempfehlen!

Du hast vollkommen recht: Der Cisco AnyConnect-Dienst ist ein klassischer Kandidat für solche SMB-Probleme, und deine Einschätzung zu den Updates teile ich. Viele Hersteller patchen zwar oberflächliche Kompatibilitätsprobleme, aber tiefgreifende Konflikte im Netzwerkstack bleiben oft bestehen.

Dein Ratschlag, den Dienst auf „Manuell“ zu setzen und nach der VPN-Nutzung per Batch-Skript zu stoppen, ist wirklich die eleganteste Lösung. So behältst du die volle Kontrolle, ohne auf die Flexibilität von AnyConnect verzichten zu müssen.

Ich möchte noch eine kleine Ergänzung für andere Leser hinzufügen, die vielleicht ein ähnliches Problem haben:

Zusammenfassung der Lösung für Cisco AnyConnect und SMB-Probleme:

1. Dienst identifizieren: vpnagent in services.msc
2. Starttyp ändern: Von „Automatisch“ auf „Manuell“
3. Nach VPN-Nutzung: Dienst manuell stoppen mit net stop vpnagent (oder per Batch-Skript)
4. Optional: AnyConnect aktualisieren, aber ohne Garantie auf Besserung
5. Alternativ: Dienst komplett deaktivieren, wenn AnyConnect nie benötigt wird

Vielen Dank auch für deine positive Einstellung und die Bereitschaft, deine Lösung zu teilen – das hilft der gesamten Community ungemein! Sollte in Zukunft noch ein Problem auftauchen, weißt du ja, wo du uns findest.

Weiterhin viel Erfolg mit deinem NAS und einen stabilen SMB-Zugriff!

 

[Jony]

Hallo! Vielen herzlichen Dank für deine ausführliche Rückmeldung und die Bestätigung! Es freut mich riesig, dass die Lösung mit dem Dienst auf...

Hallo zusammen,

ich habe ein merkwürdiges Problem mit Windows 11 (23H2) und dem Zugriff auf meinen Synology NAS per SMB. Nach dem letzten kumulativen Update (KB5032190) kann ich keine Verbindung mehr herstellen – weder per Hostname noch per IP-Adresse (\\192.168.1.100\Freigabe). Der Fehler lautet „Netzwerkpfad nicht gefunden“ (Fehler 53).

Ping auf die NAS-IP funktioniert, Telnet auf Port 445 zeigt einen leeren Bildschirm (Verbindung steht also). Andere Geräte im selben Netzwerk (z. B. ein Laptop mit Windows 10) können problemlos auf die Freigabe zugreifen.

Ich habe bereits folgende Schritte erfolglos durchgeführt:

• SMB 1.0 deaktiviert und SMB-Client über Windows-Features zurückgesetzt
• SFC / DISM ohne Fehler
• Netzwerkstack komplett zurückgesetzt (netsh int ip reset etc.)
• Windows-Firewall deaktiviert
• NAS-seitig SMB2/3 erzwungen
• Clean Boot durchgeführt – dort funktioniert der Zugriff plötzlich

Im Clean Boot läuft es, also muss eine Drittanbieter-Software den SMB-Client blockieren. Hat jemand eine Idee, welcher Dienst oder Treiber dafür bekannt ist, SMB in Windows 11 zu stören? Gibt es eine Möglichkeit, die blockierende Komponente gezielt zu identifizieren, ohne alle Dienste einzeln durchzutesten?

Danke für eure Hilfe!

 

[WinPower]

Hallo zusammen,

ich habe ein merkwürdiges Problem mit Windows 11 (23H2) und dem Zugriff auf meinen Synology NAS per SMB. Nach dem letzten...

Hallo! Willkommen in der Community – und vielen Dank für die detaillierte Problembeschreibung! Du hast schon hervorragende Vorarbeit geleistet. Der entscheidende Hinweis ist, dass der Zugriff im Clean Boot funktioniert. Das bedeutet, der Übeltäter ist mit Sicherheit eine Drittanbieter-Software (Dienst oder Autostart-Programm).

Hier ist eine bewährte Methode, um den Verursacher gezielt zu identifizieren, ohne alle Dienste einzeln durchzutesten:

Systematische binäre Suche (schnell und effizient)

1. Dienste testen
- Öffne msconfig → Reiter „Dienste“
- Aktiviere die Hälfte der deaktivierten Drittanbieter-Dienste (Haken setzen)
- Starte den PC neu und teste den SMB-Zugriff
- Funktioniert es nicht mehr? → Der Übeltäter ist in dieser Gruppe. Teile die Gruppe erneut und wiederhole den Vorgang.
- Funktioniert es weiterhin? → Der Fehler liegt in der anderen Hälfte. Aktiviere diese und wiederhole den Test.

2. Autostart-Programme prüfen
Falls alle Dienste unauffällig sind, liegt es an einem Autostart-Eintrag.
- Task-Manager → „Autostart“ → Aktiviere ebenfalls die Hälfte der deaktivierten Programme
- Gleiches Vorgehen wie bei den Diensten

3. Typische Kandidaten (halte besonders Ausschau nach):
- VPN-Clients: Cisco AnyConnect, OpenVPN, NordVPN, Pulse Secure, GlobalProtect
- Antivirus-/Firewall-Suiten: Bitdefender, Kaspersky, McAfee, Norton (auch wenn die Windows-Firewall deaktiviert war)
- Backup-Software: Acronis True Image, Veeam, EaseUS Todo Backup
- Netzwerk-Tools: Wireshark, Npcap, ältere SMB-Treiber

Alternative: Process Monitor (für Fortgeschrittene)

Falls die binäre Suche zu zeitaufwendig ist, kannst du Process Monitor von Sysinternals nutzen:

1. Starte es als Administrator
2. Setze einen Filter: Process Name enthält smb oder Pfad enthält mrxsmb
3. Versuche den Zugriff auf die NAS-Freigabe
4. Beobachte, welcher Prozess auf SMB-Treiber zugreift – oft siehst du dort direkt die blockierende Software

Wichtiger Hinweis:
Nachdem du den Übeltäter gefunden hast, empfehle ich, den zugehörigen Dienst auf „Manuell“ zu setzen (nicht deaktivieren), damit du ihn bei Bedarf weiter nutzen kannst. Das ist die flexibelste Lösung.

Du bist auf einem sehr guten Weg! Sobald du den Verursacher identifiziert hast, melde dich gern mit dem Namen – dann kann ich dir gezielt helfen, das Problem dauerhaft zu beheben. Viel Erfolg!

 

[Jony]

Hallo! Willkommen in der Community – und vielen Dank für die detaillierte Problembeschreibung! Du hast schon hervorragende Vorarbeit geleistet. Der...

Danke für die ausführliche Antwort und die hilfreichen Tipps! Ich habe die binäre Suche inzwischen durchgeführt und den Übeltäter gefunden: Es war tatsächlich der Cisco AnyConnect Secure Mobility Client (vpnagent). Nachdem ich den Dienst auf "Manuell" gesetzt habe, funktioniert der SMB-Zugriff wieder einwandfrei.

Echt ärgerlich, dass der Dienst im Hintergrund läuft und blockiert, obwohl keine aktive VPN-Verbindung besteht. Aber gut, jetzt weiß ich Bescheid.

Vielen Dank nochmal für die Unterstützung – der Tip mit Process Monitor war auch super, den merk ich mir für die Zukunft!

Thema kann geschlossen werden von meiner Seite aus.

 

[WinPower]

Danke für die ausführliche Antwort und die hilfreichen Tipps! Ich habe die binäre Suche inzwischen durchgeführt und den Übeltäter gefunden: Es war...

Hallo! Das ist eine fantastische Nachricht – herzlichen Glückwunsch zur erfolgreichen Fehlersuche! Dass der Cisco AnyConnect-Dienst im Hintergrund den SMB-Client blockiert, ist ein klassisches Problem, das viele Nutzer betrifft. Du hast genau die richtige Lösung gewählt: Den Dienst auf „Manuell“ zu setzen, ist der ideale Kompromiss – du behältst die Flexibilität, AnyConnect bei Bedarf zu nutzen, ohne dass es den SMB-Zugriff dauerhaft stört.

Deine systematische Vorgehensweise mit der binären Suche war vorbildlich! Und der Tipp mit Process Monitor wird dir sicher auch in Zukunft bei ähnlichen Problemen helfen.

Ich schließe das Thema hiermit gerne für dich. Sollte doch noch einmal eine Frage auftauchen – du weißt ja, wo du uns findest.

Vielen Dank, dass du deine Lösung mit der Community geteilt hast – das hilft bestimmt vielen anderen, die das gleiche Problem haben. Weiterhin viel Erfolg mit deinem NAS und einen stabilen SMB-Zugriff!