Synology SMB Zugriff verweigert? So beheben Sie das Problem!

Ein verweigerter SMB-Zugriff auf einer Synology ist selten ein einzelner Defekt. In der Praxis treffen oft Freigaberechte, gespeicherte Windows-Anmeldedaten, SMB-Einstellungen und manchmal auch ein Domänenkonto oder ein degradiertes Volume zusammen. Ich gehe deshalb genau so vor, wie ich es bei einer echten Fehlersuche tun würde: erst die blockierende Ebene finden, dann gezielt korrigieren.

Was die Meldung wirklich bedeutet

„Zugriff verweigert“ klingt nach einem simplen Rechteproblem, ist technisch aber nur die Oberfläche. Der SMB-Dienst auf der Synology hat deine Anfrage bereits angenommen, lehnt den Zugriff aber auf einer späteren Ebene ab. Genau deshalb ist der Unterschied zwischen „Server nicht erreichbar“ und „Freigabe verweigert“ so wichtig.

Wenn ich einen Ordner im Explorer sehen kann, ihn aber nicht öffnen darf, ist die Verbindung grundsätzlich da. Dann suche ich fast immer bei Benutzerrechten, Gruppenrechten, gespeicherten Anmeldedaten oder bei einer Ordner-ACL, die strenger ist als die Freigaberechte. Wenn ein Ordner in DSM-Files oder File Station erreichbar ist, per SMB aber nicht, spricht das ebenfalls eher für ein Protokoll- oder Clientproblem als für einen Defekt der Daten.

Für mich ist die entscheidende Frage immer: Tritt der Fehler auf allen Geräten auf oder nur auf einem? Wenn nur ein Client betroffen ist, suche ich zuerst in Windows. Wenn mehrere Clients scheitern, liegt die Ursache meist direkt auf der NAS-Seite oder in der Freigabestruktur. Genau diese Trennung spart später viel Zeit.

Die häufigsten Ursachen auf einer Synology

Bei einem verweigerten SMB-Zugriff gibt es eine Handvoll Ursachen, die ich in fast jeder zweiten oder dritten Fehlersuche wiedersehe. Die Reihenfolge ist dabei nicht zufällig: Manche Fehler sehen dramatisch aus, sind aber nur ein Nebenprodukt alter Anmeldedaten oder einer strengen Gruppenregel.

• Falscher Benutzer oder gespeicherte Alt-Anmeldedaten. Windows hält alte SMB-Sitzungen oft länger fest, als einem lieb ist.
• Ein explizites „No access“ auf Gruppen- oder Freigabeebene. In DSM kann eine einzige strenge Regel alles andere aushebeln.
• Domänenkonto ohne neu eingelesene Gruppenrechte. Nach Gruppenänderungen braucht der SMB-Cache manchmal einen Neustart oder eine Bereinigung.
• Gastzugriff oder anonyme Anmeldung. Das passt in modernen Setups meist nicht mehr zu den Sicherheitsvorgaben.
• Veraltete Protokolle auf alten Clients. SMB1 und NTLMv1 sind in aktuellen DSM-Setups kein Standard mehr.
• Verschlüsselter Ordner oder Problem im Storage-Stack. Wenn das Volume nicht sauber gemountet ist, wirkt es schnell wie ein Rechtefehler.

Wenn ich den Fehler auf einen Satz reduzieren müsste, dann so: Die meisten SMB-Probleme sind keine Netzprobleme, sondern Authentifizierungs- oder Berechtigungsprobleme mit einer schlechten Fehlermeldung. Genau deshalb lohnt sich ein systematisches Vorgehen statt wildem Klicken.

Rechte auf der Synology sauber prüfen

Freigaberechte zuerst

Die Grundregel ist klar: No access schlägt Read/Write, und Read/Write schlägt Read only. Wenn ein Benutzer also gleichzeitig über eine Gruppe Zugriff hätte, aber irgendwo ein explizites „No access“ steht, bleibt der Ordner gesperrt. Ich prüfe deshalb nicht nur den einzelnen Benutzer, sondern immer auch seine Gruppen.

Erweiterte Berechtigungen und ACL

ACL steht für Access Control List, also eine feinere Zugriffssteuerung auf Ordner- und Dateiebene. Wenn die erweiterten Freigaberechte aktiv sind, reicht die einfache Übersicht oft nicht mehr als Erklärung. Dann kann ein Unterordner oder eine Vererbungsregel den Zugriff blockieren, obwohl die Freigabe selbst offen aussieht.

Gerade hier sehe ich viele Fehler, die sich wie ein SMB-Problem anfühlen, aber eigentlich ein Dateirechteproblem sind. Mein pragmatischer Rat: Nicht in allen Ordnern gleichzeitig herumstellen. Erst den betroffenen Freigabeordner prüfen, dann die Unterstruktur.

Lesen Sie auch: NAS RAID Level - Welches ist das richtige für Sie?

Domänenkonten neu einlesen

Wenn die Synology in einer Windows-Domäne hängt oder LDAP nutzt, wird es noch etwas sensibler. Nach einer Gruppenänderung auf dem Domain Controller kann die NAS alte Informationen aus dem SMB-Cache verwenden. In solchen Fällen hilft das Leeren des SMB-Caches oft schneller als jede weitere Rechteänderung.

Wichtig ist auch der Grundsatz, den viele übersehen: Domänenbenutzer und -gruppen haben auf bereits bestehenden Freigaben nicht automatisch Zugriff. Diese Rechte muss ich bewusst setzen, sonst sieht die Anmeldung korrekt aus, der Zugriff bleibt aber trotzdem blockiert.

Wenn die Rechte auf der Synology sauber sind, prüfe ich als Nächstes den Client. Dort steckt erstaunlich oft die eigentliche Ursache.

Windows und gespeicherte Zugangsdaten bereinigen

Auf der Client-Seite arbeite ich möglichst nüchtern. Windows merkt sich SMB-Verbindungen, Kennwörter und Servernamen sehr hartnäckig. Genau das führt dazu, dass ein später richtiges Passwort trotzdem nicht akzeptiert wird.

1. Alte Laufwerksbindungen trennen. Mit net use * /delete lassen sich gemappte Verbindungen schnell aufräumen.
2. Gespeicherte Anmeldedaten löschen. In der Windows-Anmeldeinformationsverwaltung entferne ich alte Einträge für die Synology.
3. Mit einem klaren NAS-Benutzer neu verbinden. Ich teste mit einem expliziten Synology-Konto, nicht mit Gast und nicht mit einem alten Windows-Profil.
4. Nach Möglichkeit per IP statt per Name testen. Wenn \\192.168.x.x\Freigabe funktioniert, der NAS-Name aber nicht, liegt die Ursache eher bei DNS oder NetBIOS als bei den Rechten.
5. Nur eine aktive SMB-Sitzung pro Ziel verwenden. Windows mag keine wechselnden Kombinationen aus Gast, lokalem Konto und Domänenkonto für denselben Server.

Ein guter Schnelltest ist auch ein zweiter Rechner. Wenn PC A scheitert und PC B problemlos zugreift, kann ich die NAS als Speicherort meist entlasten. Dann suche ich konsequent auf dem Client oder in dessen Credentials weiter.

SMB-Version, Gastzugriff und Verschlüsselung richtig einordnen

Bei Synology spielt die Protokollseite eine größere Rolle, als viele erwarten. Seit DSM 7 ist NTLMv1 aus Sicherheitsgründen deaktiviert; moderne Windows-Clients sollten mit NTLMv2 sowie SMB2 oder SMB3 arbeiten. Alte Geräte, die nur SMB1 oder NTLMv1 beherrschen, kann man zwar manchmal noch anbinden, aber ich würde das nur als Übergangslösung sehen.

• SMB2 und SMB3 sind der Normalfall. Sie passen zu aktuellen Windows-Versionen und sind deutlich robuster als SMB1.
• Gastzugriff ist keine saubere Dauerlösung. Wenn der Gastaccount aktiv ist, versucht Windows teils automatisch diesen Weg, was dann in einer Verweigerung endet.
• Transportverschlüsselung und anonymer Zugriff passen nicht zusammen. Wer Verschlüsselung erzwingt, braucht echte Zugangsdaten.
• Legacy-Geräte gehören in ein eigenes Sicherheitskonzept. Ein alter Scanner oder Mediaplayer sollte nicht die gesamte Dateiablage auf schwache Protokolle runterziehen.

Für eine moderne Heimumgebung oder ein kleines Büro ist der Kompromiss meist klar: lieber ein altes Gerät modernisieren oder isolieren, statt SMB1 wieder breit zu öffnen. Das ist nicht nur sicherer, sondern verhindert auch merkwürdige Nebeneffekte bei der Anmeldung.

Wenn RAID, Volume oder Verschlüsselung die eigentliche Ursache sind

Wenn Rechte und Anmeldedaten stimmen, schaue ich auf den Speicher selbst. Ein RAID schützt vor dem Ausfall einzelner Laufwerke, aber nicht vor fehlerhaften Freigaberechten, einem gesperrten verschlüsselten Ordner oder einem Volume, das nach einem Fehler nur noch im read-only-Modus läuft.

• Storage Pool und Volume sollten im grünen Bereich sein, nicht degraded, repairing oder read-only.
• Verschlüsselte Freigaben müssen entsperrt sein. Sonst wirkt der Ordner aus SMB-Sicht schnell wie blockiert, obwohl die Daten physisch noch vorhanden sind.
• Nach einem Rebuild oder Laufwerkswechsel prüfe ich die Freigaben noch einmal. Lange Reparaturphasen können Nebeneffekte sichtbar machen, die vorher untergingen.
• RAID ist kein Backup. Das erwähne ich bewusst in einem Artikel über Zugriffsstörungen, weil viele erst bei Problemen merken, wie eng Verfügbarkeit und Datensicherheit zusammenhängen.

Wenn das Volume fehlerfrei ist, bleibt die Ursache fast immer in der Freigabe-, Konto- oder SMB-Schicht. Ist der Storage aber angegriffen, bringt Feinjustierung an Rechten wenig, solange die Basis selbst nicht stabil ist.

So gehe ich in der Praxis als Nächstes vor

Wenn der Zugriff nach den Standardprüfungen immer noch scheitert, arbeite ich noch enger ein. Ich reduziere die Variablen, bis nur noch eine Ursache übrig bleibt. Das ist in der Regel schneller als jede breite Rundumdiagnose.

• Ich teste einen einzigen lokalen NAS-Benutzer an einer einzigen Freigabe.
• Ich entferne alte Windows-Anmeldedaten und verbinde die Freigabe neu.
• Ich leere bei Domänenkonten den SMB-Cache und prüfe die Gruppenmitgliedschaft erneut.
• Ich kontrolliere, ob der Ordner verschlüsselt, gesperrt oder nur read-only gemountet ist.
• Ich behandle alte SMB1- oder NTLMv1-Geräte nur noch als Sonderfall, nicht als Normalzustand.

Wenn du diese Reihenfolge einhältst, trennst du den Fehler sauber in drei Ebenen: Rechtesystem, Authentifizierung und Speicherzustand. Genau das macht die Fehlersuche auf einer Synology mit SMB und RAID deutlich schneller und am Ende auch sicherer.