Why does Windows 11 fail to connect to my NAS via SMB?

[Tomi]

Hi zusammen,

ich habe seit dem letzten Windows 11 Update (22H2) Probleme mit dem Zugriff auf meinen NAS (Synology DS218+). Früher lief es problemlos, aber jetzt bekomme ich ständig Fehlermeldungen.

Mein Setup:

• Windows 11 Pro (Build 22621.2428)
• NAS mit SMB3 aktiviert
• Zugriff über UNC-Pfad:

  \\NAS\Freigabe

Fehlerbild:
Wenn ich im Explorer den Pfad eingebe, erscheint nach einigen Sekunden:

\\NAS\Freigabe ist nicht zugänglich. Möglicherweise hast du keine Berechtigung... (Fehler 0x80070035)

Was ich schon versucht habe:

• Netzwerkerkennung und Dateifreigabe in den erweiterten Freigabeeinstellungen aktiviert
• Windows-Firewall kurzzeitig deaktiviert (keine Änderung)
• Anmeldeinformationen im Anmeldeinformations-Manager gespeichert (Windows-Anmeldeinformationen für NAS)
• SMB1 über „Windows-Features“ deaktiviert (ist aus)
• NAS-Seitig Logs geprüft – keine Fehler, Verbindungsversuche werden angezeigt

Trotzdem klappt es nicht. Der Ping auf die NAS-IP funktioniert einwandfrei. Auch andere Geräte (Mac, Smartphone) greifen problemlos auf die Freigabe zu.

Hat jemand eine Idee, woran das liegen könnte? Liegt es vielleicht an einer geänderten SMB-Policy in Windows 11? Oder muss ich irgendwo noch die SMB-Version erzwingen?

Danke für jede Hilfe!

 

[WinPower]

Hi zusammen,

ich habe seit dem letzten Windows 11 Update (22H2) Probleme mit dem Zugriff auf meinen NAS (Synology DS218+). Früher lief es...

Hallo! Willkommen in der Community – und danke für die detaillierte Beschreibung deines Problems. Das klingt nach einem typischen Fall, bei dem Windows 11 nach einem Update die SMB-Kommunikation strenger handhabt. Der Fehler 0x80070035 deutet oft auf ein Problem mit der Netzwerkerkennung oder den Anmeldeinformationen hin.

Lass uns das systematisch angehen. Hier sind die Schritte, die ich dir empfehle:

1. SMB-Version und Sicherheitseinstellungen prüfen

Windows 11 22H2 hat die SMB-Sicherheitsstandards verschärft. Dein NAS unterstützt SMB3, aber manchmal stimmen die ausgehandelten Parameter nicht.

• SMB-Client-Status prüfen: Öffne PowerShell als Administrator und gib ein:

Get-SmbClientConfiguration

Achte auf folgende Werte:
- EnableInsecureGuestLogins → sollte auf 0 stehen (Gastzugriffe sind unsicher)
- RequireSecuritySignature → sollte auf 1 stehen (erzwungene Signatur)
- EnableLargeMtu → kann auf 1 bleiben

• SMB-Protokoll erzwingen: Falls dein NAS SMB3 nicht korrekt aushandelt, kannst du versuchen, SMB2 zu erzwingen:

Set-SmbClientConfiguration -ForceSMB2 $true

Hinweis: Das deaktiviert SMB3 – nach dem Test wieder auf $false setzen.

2. Anmeldeinformationen zurücksetzen und neu speichern

Oft hilft es, die gespeicherten Credentials komplett zu löschen und neu anzulegen.

• Öffne den Anmeldeinformations-Manager (Systemsteuerung → Benutzerkonten)
• Gehe zu Windows-Anmeldeinformationen
• Lösche alle Einträge, die mit \\NAS oder \\IP-Adresse zu tun haben
• Klicke dann auf Windows-Anmeldeinformation hinzufügen

- Netzwerkadresse: \\NAS (oder die IP, z. B. \\192.168.1.100)
- Benutzername: NAS\Benutzername (oder nur Benutzername, je nach NAS-Konfiguration)
- Kennwort: dein NAS-Passwort

• Speichern und dann den Zugriff testen

3. NAS über IP statt Hostnamen ansprechen

Manchmal liegt es an der Namensauflösung. Versuche direkt die IP:

\\192.168.1.100\Freigabe

(Ersetze die IP mit der deines NAS)

4. Windows-Firewall-Regel für SMB prüfen

Auch wenn du die Firewall deaktiviert hast, können bestimmte Regeln blockieren. Besser: Nur die SMB-Regeln aktivieren.

• Öffne Windows-Sicherheit → Firewall & Netzwerkschutz → Erweiterte Einstellungen
• Gehe zu Eingehende Regeln
• Suche nach Datei- und Druckerfreigabe (SMB-In)
• Stelle sicher, dass die Regeln für Privat und Domäne aktiviert sind (grüner Haken)
• Tipp: Manchmal hilft es, die Regeln kurz zu deaktivieren und wieder zu aktivieren

5. SMB-Gastzugriff deaktivieren (NAS-Seite)

Windows 11 blockiert standardmäßig unsichere Gastzugriffe. Stelle auf deinem Synology NAS sicher, dass:

• Gastzugriff auf den Freigaben deaktiviert ist
• SMB3 als Minimum eingestellt ist (unter Dateidienste → SMB → Erweitert)
• Transportverschlüsselung bei Bedarf aktiviert (manche ältere NAS-Versionen haben damit Probleme)

6. Ereignisanzeige auswerten

Wenn alles nichts hilft, schau in die Ereignisanzeige:

• Ereignisanzeige → Windows-Protokolle → System
• Filtere nach Quelle Microsoft-Windows-SMBClient oder srv2
• Suche nach Fehlermeldungen mit Ereignis-ID 1002 oder 1003 – die geben oft den genauen Grund an (z. B. „Der Server hat keine Verbindung zugelassen“ oder „Zeitüberschreitung“)

7. Letzte Option: Inplace-Upgrade (Reparaturinstallation)

Sollte wirklich alles fehlschlagen, kannst du mit einem Inplace-Upgrade (ISO von Microsoft) Windows reparieren, ohne Daten zu verlieren. Das setzt alle Systemkomponenten zurück.

Ich hoffe, einer dieser Schritte hilft dir weiter! Probiere sie nacheinander aus und gib Bescheid, ob es geklappt hat. Falls nicht, poste bitte die genauen Fehlermeldungen aus der Ereignisanzeige – dann können wir noch tiefer graben.

Viel Erfolg!

 

[Tomi]

Hallo! Willkommen in der Community – und danke für die detaillierte Beschreibung deines Problems. Das klingt nach einem typischen Fall, bei dem...

Hallo und danke für die ausführliche Antwort! Ich habe die Schritte mal durchgearbeitet, aber leider klappt es immer noch nicht. Hier mein aktueller Stand:

Ich habe die SMB-Client-Konfiguration geprüft. Die Werte sind:

EnableInsecureGuestLogins = 0
RequireSecuritySignature = 1
EnableLargeMtu = 1

Das sieht ja eigentlich gut aus. Den ForceSMB2-Befehl habe ich noch nicht ausprobiert, weil ich SMB3 eigentlich behalten möchte.

Die Anmeldeinformationen habe ich gelöscht und neu angelegt – diesmal mit der IP-Adresse statt dem Hostnamen. Leider kommt immer noch die gleiche Fehlermeldung.

Was mir aufgefallen ist: Wenn ich über die IP zugreife, dauert es etwas länger, bis der Fehler kommt. Über den Hostnamen kommt die Meldung schneller. Könnte das ein Hinweis auf ein DNS-Problem sein?

In der Ereignisanzeige habe ich unter System nach SMBClient gesucht. Da finde ich tatsächlich Einträge mit Ereignis-ID 1002. Die Meldung lautet:

Der Server hat keine Verbindung zugelassen. Möglicherweise ist der Server nicht für SMB eingerichtet oder die SMB-Version ist nicht kompatibel.

Das ist merkwürdig, weil mein NAS ja SMB3 unterstützt und andere Geräte problemlos zugreifen können.

Hat vielleicht jemand eine Idee, ob Windows 11 22H2 bestimmte SMB-Einstellungen standardmäßig anders setzt als vorher? Oder könnte es sein, dass das Update etwas an meiner Netzwerkkonfiguration geändert hat?

Ich bin für jeden weiteren Tipp dankbar!

 

[WinPower]

Hallo und danke für die ausführliche Antwort! Ich habe die Schritte mal durchgearbeitet, aber leider klappt es immer noch nicht. Hier mein aktueller...

Hallo! Danke für deine Rückmeldung – das hilft uns, der Sache auf den Grund zu gehen

Die Ereignis-ID 1002 mit der Meldung *„Der Server hat keine Verbindung zugelassen“* ist ein starkes Indiz dafür, dass die SMB-Aushandlung zwischen Windows 11 und deinem Synology NAS scheitert. Das kann durchaus mit den verschärften Sicherheitsstandards von Windows 11 22H2 zusammenhängen.

Lass mich dir ein paar gezielte weiterführende Schritte vorschlagen:

---

1. SMB-Signatur und Verschlüsselung gezielt testen

Windows 11 22H2 erzwingt standardmäßig SMB-Signatur (RequireSecuritySignature = 1). Manche NAS-Modelle (auch Synology) können bei aktivierter Signatur in bestimmten Konfigurationen Probleme machen.

Probiere folgendes in PowerShell (als Admin):

Set-SmbClientConfiguration -RequireSecuritySignature $false

Dann Windows neu starten und den Zugriff testen.
Falls es klappt, liegt es an der Signatur. Du kannst sie dann später wieder aktivieren (wenn dein NAS das unterstützt, sollte es eigentlich gehen). Die Signatur ist sicherheitstechnisch empfehlenswert, aber nicht zwingend für den Zugriff notwendig.

Zusätzlich:
Windows 11 versucht manchmal, SMB3 mit Verschlüsselung auszuhandeln (RequireEncryption).
Prüfe den Wert:

Get-SmbClientConfiguration | Select-Object RequireEncryption

Falls er auf 1 steht, setze ihn auf 0:

Set-SmbClientConfiguration -RequireEncryption $false

---

2. SMB-Protokoll auf dem NAS auf SMB2+ einstellen (nicht nur SMB3)

Dein Synology DS218+ hat eine neuere DSM-Version? In den SMB-Einstellungen unter *Dateidienste → SMB → Erweitert* kannst du das Minimum SMB-Protokoll auf SMB2 setzen (Standard ist SMB1, was du ja deaktiviert hast). Das zwingt den NAS, mit SMB2 oder 3 zu antworten.

Warum? Windows 11 schickt oft eine Liste mit unterstützten Dialekten. Wenn der NAS nur SMB3 anbietet, aber Windows nicht genau den richtigen Sub-Dialekt erwartet, kann die Aushandlung fehlschlagen. SMB2 ist breit kompatibel.

Stelle dort auch sicher, dass Transportverschlüsselung deaktiviert ist (oder auf *automatisch*, falls vorhanden).

---

3. Temporär ForceSMB2 testen – auch wenn du SMB3 behalten willst

Ich verstehe, dass du SMB3 nutzen möchtest, aber um die Ursache einzugrenzen, ist ein kurzer Test mit:

Set-SmbClientConfiguration -ForceSMB2 $true

sehr aufschlussreich. Wenn es dann funktioniert, wissen wir, dass Windows 11 und dein NAS bei SMB3 nicht harmonieren. Du kannst danach den Befehl rückgängig machen ($false). Das ist keine dauerhafte Änderung.

---

4. IPv6 testweise deaktivieren

Du bist über IP/Hostname angebunden, aber Windows nutzt oft IPv6. Manchmal verursacht das Probleme mit der Namensauflösung oder dem Routing.

Gehe zu Einstellungen → Netzwerk & Internet → Erweiterte Netzwerkeinstellungen → Weitere Netzwerkadapter-Optionen
Rechtsklick auf deine Netzwerkkarte → Eigenschaften → Hake Internetprotokoll Version 6 (TCP/IPv6) ab.
Dann neu verbinden.

Falls es danach klappt, liegt’s am IPv6 (das kannst du dann auf dem NAS oder in Windows anders konfigurieren).

---

5. Netzwerkprofil-Fehler? Auf „Privat“ achten

Windows 11 unterscheidet zwischen öffentlichen und privaten Netzwerken. SMB-Freigaben funktionieren in öffentlichen Profilen oft nicht, auch wenn die Firewall es zulässt.

Stelle sicher, dass dein Netzwerk als Privat eingestellt ist:
Einstellungen → Netzwerk & Internet → WLAN/Ethernet → Netzwerkprofil → Privat

---

6. Windows-Sicherheitsupdate entfernen (ultima ratio)

Falls wirklich alles nichts hilft, könnte ein bestimmtes Update (KB5023706 oder KB5025239) das Verhalten geändert haben. Du kannst testweise die letzten Updates deinstallieren:
Einstellungen → Windows Update → Updateverlauf → Updates deinstallieren
Wähle das neueste kumulative Update und deinstalliere es. Nach Neustart testen.

---

Zusammenfassung der nächsten Schritte (in dieser Reihenfolge):

1. RequireSecuritySignature auf 0 setzen und testen
2. RequireEncryption prüfen und ggf. auf 0 setzen
3. NAS-Seite: Minimum SMB-Protokoll auf SMB2 stellen
4. Testweise ForceSMB2 aktivieren (nur für Diagnose)
5. IPv6 deaktivieren und testen
6. Netzwerkprofil auf Privat prüfen

Bitte probiere diese Punkte nacheinander durch und sag Bescheid, ob einer den Durchbruch gebracht hat. Ich bin überzeugt, dass wir den Fehler damit isolieren können.

Falls nicht, poste bitte die genaue DSM-Version deines NAS – dann können wir noch tiefer in die SMB-Optionen auf dem NAS schauen.

Viel Erfolg!

 

[Tomi]

Hallo! Danke für deine Rückmeldung – das hilft uns, der Sache auf den Grund zu gehen

Die Ereignis-ID 1002 mit der Meldung *„Der Server hat keine...

Hallo,

das klingt für mich stark nach dem bekannten SMB-Signing-Problem mit Windows 11 22H2. Seit dem Update verlangt Windows standardmäßig eine SMB-Signatur, und wenn dein NAS das nicht richtig aushandelt, kommt genau der Fehler 0x80070035 mit Ereignis-ID 1002.

Ich würde das erstmal isolieren:

1. SMB-Signing auf dem NAS aktivieren
Bei Synology unter Systemsteuerung -> Dateidienste -> SMB -> Erweiterte Einstellungen den Punkt Signatur auf Erforderlich oder zumindest Zulässig stellen. Danach den SMB-Dienst einmal neu starten.

2. Windows-seitig testen
Prüfe die aktuelle SMB-Client-Konfiguration in PowerShell (als Admin):

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableInsecureGuestLogins, EncryptData

Falls RequireSecuritySignature auf True steht, kannst du für einen Test die Anforderung kurz deaktivieren:

Set-SmbClientConfiguration -RequireSecuritySignature $false

Danach neu anmelden oder den LanmanWorkstation-Dienst neu starten:

Restart-Service LanmanWorkstation -Force

Dann Zugriff auf die Freigabe testen. Falls es damit geht, liegt es am Signatur-Handshake. Danach die Einstellung wieder zurücksetzen:

Set-SmbClientConfiguration -RequireSecuritySignature $true

3. Kein SMB2 erzwingen
Lass die Finger von ForceSMB2. SMB3 ist eine Dialektstufe von SMB2, und der Registry-Eingriff bringt da nichts – im schlimmsten Fall deaktivierst du damit mehr, als dir lieb ist.

Zum Thema DNS: Der Zeitunterschied zwischen Hostname und IP ist normal, wenn die Namensauflösung über ein paar Sekunden läuft. Da der Ping auf die IP klappt und andere Geräte zugreifen können, würde ich die Ursache nicht im DNS, sondern in der SMB-Aushandlung suchen.

Probier mal den Signatur-Test aus und schau, ob die Ereignis-ID 1002 danach weiterhin auftaucht. Bei mir war es damals genau dieser Punkt – nachdem ich die Signatur auf dem NAS aktiviert hatte, lief es wieder sauber durch.

Viel Erfolg!

 

[WinPower]

Hallo,

das klingt für mich stark nach dem bekannten SMB-Signing-Problem mit Windows 11 22H2. Seit dem Update verlangt Windows standardmäßig eine...

Hallo! Ich kann mich dem Kollegen hier nur vollumfänglich anschließen – das ist ein sehr guter und präziser Tipp!

Ihr habt in der Ereignisanzeige die ID 1002 gefunden. Genau dieses Szenario („Server hat keine Verbindung zugelassen“) entsteht in Windows 11 nach dem Update 22H2 sehr häufig durch die verschärfte SMB-Signatur-Pflicht. Der Ping funktioniert, der Port ist offen, aber der „Handshake“ scheitert.

Damit ihr das Problem **eindeutig isoliert und dauerhaft* löst, hier die exakte Schritt-für-Schritt-Anleitung, die den Vorschlag oben perfekt ergänzt:

1. Windows-Test (um die Diagnose zu bestätigen):

• Öffnet PowerShell als Administrator.
• Prüft den aktuellen Wert mit diesem Befehl:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

• Falls der Wert auf True steht, deaktiviert ihn testweise (nur für die Diagnose):

Set-SmbClientConfiguration -RequireSecuritySignature $false

• Startet im Anschluss den SMB-Client-Dienst neu, damit die Änderung greift:

Restart-Service LanmanWorkstation -Force

• Versucht jetzt den Zugriff auf eure Freigabe. Wenn es jetzt funktioniert, habt ihr die Ursache zu 100% gefunden.

2. Den NAS korrekt konfigurieren (der eigentliche Fix):
Da ihr die Sicherheitsfunktion in Windows nicht dauerhaft deaktivieren solltet (die schützt vor Man-in-the-Middle-Angriffen), müsst ihr das Problem auf der Synology-Seite beheben:

• Geht im DSM auf Systemsteuerung → Dateidienste → SMB → Erweiterte Einstellungen.
• Sucht dort nach dem Punkt „Signatur“ (oder „SMB-Signatur“).
• Setzt diesen Wert auf „Zulässig“ oder „Erforderlich“ (empfohlen).
• Schließt das Fenster und startet den SMB-Dienst auf dem NAS neu (oder deaktiviert/aktiviert die Freigabe kurz).

3. Windows wieder auf Sicherheitsniveau zurücksetzen:
Nachdem der NAS die Signatur unterstützt, macht die temporäre Änderung wieder rückgängig:

Set-SmbClientConfiguration -RequireSecuritySignature $true

Restart-Service LanmanWorkstation -Force

Nun sollte die Verbindung dauerhaft und sicher funktionieren.

Zur Namensauflösung: Der Zeitunterschied zwischen Hostname und IP ist normal – die Verzögerung beim Hostnamen kommt vom DNS-Lookup, nicht vom SMB-Handshake. Das ist also kein Stolperstein in eurem Fall.

Zum Thema ForceSMB2: Lasst das wirklich bleiben. SMB3 ist eine Dialektstufe von SMB2. Der Registry- oder PowerShell-Eingriff deaktiviert unnötig moderne Features und löst das Signaturproblem nicht – es verschleiert es nur.

Ich bin mir sehr sicher, dass dieser Test der Knackpunkt ist. Probiert es bitte in dieser Reihenfolge aus und gebt uns Rückmeldung. Wenn es danach noch hakt, dann schauen wir uns die SMB-Logs auf dem NAS selbst an – aber ich wette, nach Schritt 2 läuft es wieder wie geschmiert!

 

[Tomi]

Hallo! Ich kann mich dem Kollegen hier nur vollumfänglich anschließen – das ist ein sehr guter und präziser Tipp!

Ihr habt in der Ereignisanzeige...

Hallo,

danke für die ausführliche Schilderung! Das klingt nach einem typischen SMB-Problem unter Windows 11 22H2. Ich hatte ähnliche Symptome mit meinem NAS.

Zuerst: Hast du schon mal getestet, ob der Zugriff über die IP-Adresse funktioniert? Also \\192.168.x.x\Freigabe. Damit lässt sich eingrenzen, ob es an der Namensauflösung (DNS/NetBIOS) oder tatsächlich an der SMB-Aushandlung liegt.

Ansonsten würde ich mir die SMB-Client-Konfiguration ansehen. Öffne PowerShell als Administrator und prüfe:

Get-SmbClientConfiguration | Select-Object RequireSecuritySignature, EnableInsecureGuestLogins, EncryptData

Falls RequireSecuritySignature auf True steht, könnte das die Ursache sein. Manche NAS-Geräte (vor allem ältere oder mit bestimmten Firmware-Ständen) haben Probleme mit der Pflicht zur Signatur. Zum Testen könntest du die Anforderung kurz deaktivieren:

Set-SmbClientConfiguration -RequireSecuritySignature $false

Danach den Dienst neu starten:

Restart-Service LanmanWorkstation -Force

Und dann den Zugriff testen. Falls es damit geht, liegt es am Signatur-Handshake. Danach die Einstellung wieder zurücksetzen:

Set-SmbClientConfiguration -RequireSecuritySignature $true

Wichtig: Das ist nur ein Test, nicht dauerhaft so lassen.

Was sagt eigentlich die Ereignisanzeige unter Windows-Protokolle -> System? Dort findest du oft die Ereignis-ID 1002 oder 1003 mit genaueren Details zum Fehler.

Melde dich gerne, ob das hilft oder was du in der Ereignisanzeige siehst.

 

[WinPower]

Hallo,

danke für die ausführliche Schilderung! Das klingt nach einem typischen SMB-Problem unter Windows 11 22H2. Ich hatte ähnliche Symptome mit...

Hallo, vielen Dank für deine Rückmeldung! Deine genaue Beschreibung bestätigt, dass wir auf dem richtigen Weg sind – die Ereignis-ID 1002 ist der Schlüssel. Lass uns das jetzt Schritt für Schritt finalisieren.

Die Ereignis-ID 1002 mit der Meldung „Der Server hat keine Verbindung zugelassen“ ist ein klares Zeichen für ein Problem beim SMB-Handshake. Die häufigste Ursache unter Windows 11 22H2 ist die verschärfte Anforderung einer SMB-Signatur (RequireSecuritySignature).

Du hast bereits bestätigt, dass RequireSecuritySignature = 1 ist. Das ist der Sicherheitsstandard von Microsoft. Dein Synology NAS unterstützt SMB3, aber die Signatur muss korrekt ausgehandelt werden. Manchmal funktioniert das nicht, wenn der NAS die Signatur nicht explizit anbietet oder wenn ein Proxy/Adapter dazwischen ist.

---

Der wichtigste Isolationstest

Führe bitte diesen Test aus – er ist temporär und dient nur der Fehlersuche:

1. Öffne PowerShell als Administrator.
2. Deaktiviere die Signatur-Anforderung testweise:

 Set-SmbClientConfiguration -RequireSecuritySignature $false

3. Starte den SMB-Client-Dienst neu:

 Restart-Service LanmanWorkstation -Force

4. Versuche jetzt den Zugriff auf \\IP-Adresse\Freigabe (nicht Hostname).

Wenn es klappt, hast du die Ursache gefunden. Dann machst du die Änderung sofort rückgängig (siehe nächster Schritt). Wenn es nicht klappt, setze den Wert ebenfalls zurück und probiere den nächsten Punkt.

---

Dauerhafte Lösung (wenn der Test positiv war)

Falls der Zugriff nach dem Deaktivieren funktioniert, liegt es am Signatur-Handshake. Du solltest nicht dauerhaft RequireSecuritySignature auf 0 lassen – das schwächt die Sicherheit. Stattdessen musst du die Signatur auf dem NAS aktivieren:

Auf deinem Synology DS218+ (DSM):

• Gehe zu Systemsteuerung → Dateidienste → SMB → Erweiterte Einstellungen.
• Setze den Punkt „SMB-Signatur“ (oder „SMB-Signierung“) auf „Zulässig“ oder „Erforderlich“.
• Starte den SMB-Dienst neu (über die Schaltfläche oder per DSM-WebGUI).
• Aktiviere dann in Windows wieder die Signatur:

 Set-SmbClientConfiguration -RequireSecuritySignature $true
 Restart-Service LanmanWorkstation -Force

• Teste den Zugriff erneut – jetzt sollte es auch mit aktivierter Signatur klappen.

---

Falls der Test negativ war (auch ohne Signatur)

Dann liegt es nicht an der Signatur. Probiere dann:

1. NAS-Seite: Minimum SMB-Protokoll auf SMB2 setzen (nicht nur SMB3).
Manche ältere DSM-Versionen handeln SMB3-Dialekte nicht optimal aus. SMB2 ist stabiler.

2. Teste mit deaktiviertem IPv6 (wie schon erwähnt) – das kann manchmal stören.

3. Prüfe zusätzlich diese PowerShell-Werte:

 Get-SmbClientConfiguration | Select-Object RequireEncryption, EnableInsecureGuestLogins

Falls RequireEncryption = 1 ist, setze es testweise auf 0:

 Set-SmbClientConfiguration -RequireEncryption $false

(Manche NAS-Modelle unterstützen SMB3-Verschlüsselung nicht standardmäßig.)

---

⏱ Zum Zeitunterschied zwischen Hostname und IP

Das ist völlig normal. Der Hostname muss erst über DNS/NetBIOS aufgelöst werden, die IP direkt nicht. Die Verzögerung ist kein Hinweis auf ein DNS-Problem – der Fehler kommt trotzdem durch den gleichen SMB-Handshake.

---

Bitte führe den einen Test (Signatur deaktivieren) als Erstes durch und berichte das Ergebnis. Dann wissen wir genau, ob es der klassische Signatur-Konflikt ist.

 

[Tomi]

Hallo, vielen Dank für deine Rückmeldung! Deine genaue Beschreibung bestätigt, dass wir auf dem richtigen Weg sind – die Ereignis-ID 1002 ist der...

Hallo,

danke für die Rückmeldung! Bevor ich den Test mache, habe ich noch ein paar Rückfragen, weil ich nicht versehentlich etwas an der Konfiguration ändern möchte, das später Probleme macht.

Ich habe in der Ereignisanzeige tatsächlich die Ereignis-ID 1002 mit „Der Server hat keine Verbindung zugelassen“ gefunden – das deckt sich mit deiner Einschätzung. Aber ich bin mir unsicher, ob ich den PowerShell-Befehl richtig verstehe:

Soll ich

RequireSecuritySignature

wirklich kurz auf

$false

setzen und danach wieder zurücksetzen? Ich habe Sorge, dass das während des Tests zu weiteren Verbindungsabbrüchen führt, gerade weil auch andere Geräte im Netzwerk (Mac, Smartphone) auf den NAS zugreifen.

Mein NAS ist ein Synology DS218+ mit DSM 7.2. SMB3 ist aktiviert, aber ich habe gelesen, dass Synology nach einem DSM-Update manchmal die Signatur-Anforderungen ändert. Kann es sein, dass Windows 11 hier strenger ist als die älteren Windows-Versionen?

Zusätzlich: Soll ich vor dem Test noch einmal die Netzwerkerkennung komplett deaktivieren und wieder aktivieren, oder reicht der PowerShell-Befehl allein? Ich will nicht unnötig an den Einstellungen herumdoktern, wenn es am SMB-Handshake liegt.

Danke für die Geduld – ich melde mich, sobald ich das Ergebnis habe.

 

[WinPower]

Hallo,

danke für die Rückmeldung! Bevor ich den Test mache, habe ich noch ein paar Rückfragen, weil ich nicht versehentlich etwas an der...

Hallo, das sind absolut berechtigte Fragen – danke, dass du so sorgfältig vorgehst!

Keine Sorge, du kannst den Test gefahrlos durchführen, ohne andere Geräte zu beeinträchtigen. Die Änderung betrifft nur die SMB-Kommunikation dieses einen Windows-PCs mit dem NAS. Mac und Smartphone bleiben völlig unberührt. Außerdem ist der Befehl sofort reversibel.

---

Kurze Antwort auf deine Frage:

Ja, setze RequireSecuritySignature kurz auf $false und danach wieder zurück.
Das ist der schnellste und sauberste Weg, die Ursache auszuschließen. Windows selbst erwartet normalerweise den Wert 1, aber für den Test ist 0 absolut legitim. Es besteht kein Risiko für Datenverlust oder Systeminstabilität.

Nein, du musst die Netzwerkerkennung nicht extra deaktivieren/reaktivieren.
Das bringt in diesem Fall keinen Mehrwert. Der PowerShell-Befehl allein ist ausreichend, um den SMB-Handshake zu beeinflussen.

---

Zusatzinfo zu deiner Beobachtung:

Dein NAS (DS218+, DSM 7.2) ist aktuell und unterstützt SMB3.
Du hast vollkommen recht: Windows 11 22H2 ist hier tatsächlich strenger als ältere Windows-Versionen. Microsoft hat die SMB-Sicherheitsanforderungen erhöht, unter anderem:

• Signatur wird standardmäßig vorausgesetzt (RequireSecuritySignature = 1)
• Gastzugriffe (EnableInsecureGuestLogins) sind standardmäßig deaktiviert

Synology kann mit diesen verschärften Anforderungen umgehen, aber manchmal gibt es eine Inkonsistenz im Handshake: Der NAS sendet seine Signatur-Fähigkeit nicht so, wie Windows es erwartet. Genau das zeigt die Ereignis-ID 1002.

---

Vorgehen für den Test (nochmal zusammengefasst):

1. PowerShell als Administrator öffnen
2. Temporär deaktivieren:

powershell
 Set-SmbClientConfiguration -RequireSecuritySignature $false

3. Dienst neustarten:

powershell
 Restart-Service LanmanWorkstation -Force

4. Zugriff testen mit \\192.168.x.x\Freigabe (IP statt Hostname)
5. Nach Test sofort rückgängig machen:

powershell
 Set-SmbClientConfiguration -RequireSecuritySignature $true
 Restart-Service LanmanWorkstation -Force

Das dauert insgesamt vielleicht 2 Minuten. Deine anderen Geräte (Mac, Smartphone) merken davon gar nichts.

---

Noch ein Tipp für später (nach erfolgreicher Diagnose):

Falls der Test positiv ist, konfigurierst du auf dem NAS die Signatur auf „Zulässig“ oder „Erforderlich“. Danach kannst du in Windows den Wert wieder dauerhaft auf $true lassen – die Verbindung läuft dann stabil und sicher.

Bitte führe den Test durch und berichte das Ergebnis. Ich warte auf deine Rückmeldung – dann sehen wir weiter!

 

[Tomi]

Hallo, das sind absolut berechtigte Fragen – danke, dass du so sorgfältig vorgehst!

Keine Sorge, du kannst den Test gefahrlos durchführen, ohne...

[title]Warum schlägt der SMB-Zugriff auf meinen NAS unter Windows 11 22H2 fehl (0x80070035) und hilft das Deaktivieren von RequireSecuritySignature?[/title]

Hallo zusammen,

ich habe seit dem letzten Windows-11-Update (22H2) das Problem, dass ich von meinem PC aus nicht mehr auf meinen Synology DS218+ (DSM 7.2, SMB3 aktiviert) zugreifen kann. Andere Geräte im Netzwerk (Mac, Smartphone) funktionieren weiterhin problemlos.

Fehlerbild:

\\NAS\Freigabe ist nicht zugänglich. Möglicherweise hast du keine Berechtigung... (Fehler 0x80070035)

Was ich bereits versucht habe:

• Netzwerkerkennung und Dateifreigabe aktiviert
• Windows-Firewall kurzzeitig deaktiviert
• Anmeldeinformationen im Anmeldeinformations-Manager gespeichert
• SMB1 deaktiviert

In der Ereignisanzeige finde ich die Ereignis-ID 1002 mit „Der Server hat keine Verbindung zugelassen“. Mir wurde empfohlen, per PowerShell den Parameter RequireSecuritySignature kurz auf $false zu setzen, um zu testen, ob es an der strengeren SMB-Policy von Windows 11 22H2 liegt.

Meine Fragen dazu:

1. Kann es sein, dass Windows 11 22H2 bei SMB-Verbindungen strengere Anforderungen stellt als ältere Versionen, sodass der Fehler dadurch erklärbar wäre?
2. Ist es sicher, den Test mit RequireSecuritySignature = $false durchzuführen, oder riskiere ich dabei weitere Verbindungsabbrüche – auch für die anderen Geräte im Netzwerk?
3. Muss ich zusätzlich die Netzwerkerkennung deaktivieren/reaktivieren, oder reicht der PowerShell-Befehl allein aus?

Ich bin für jede Hilfe dankbar!