Azure File Storage Authentifizierungsfehler beheben — NetDrive

Ein IT-Administrator verwaltet fünf Azure File Storage-Freigaben, die als Laufwerksbuchstaben auf einem Windows Server RDS-Host eingebunden sind — eine pro Abteilung, jede von einem alten On-Premise-Dateiserver übernommen. Am Montagmorgen wirft die Finance-Freigabe einen Authentifizierungsfehler in NetDrive, während sich die anderen vier normal wieder verbinden. Da sich seit Freitag nichts an der Mount-Konfiguration geändert hat, bedeutet das meist, dass sich die Anmeldedaten oder die Freigabe selbst geändert haben — nicht NetDrive.

Azure File Storage als dauerhaften Laufwerksbuchstaben einbinden

Mit NetDrive erscheinen Google Drive, OneDrive, S3, SFTP, WebDAV und mehr als native Laufwerke unter Windows und macOS — ohne Synchronisation, ohne vollständige Downloads.

• Verbindung mit einem Kontoschlüssel oder einem eingeschränkten SAS-Token
• Auto-Mount beim Systemstart hält die Freigabe vor dem Login bereit
• Team-Lizenz erlaubt Admins, Anmeldedaten auf jeden Rechner zu verteilen

WindowsmacOS

NetDrive herunterladen →

Kostenlose Testversion. Lifetime- und Abo-Pläne verfügbar.

Azure File Storage vs. Azure Blob — Gleicher Fehler, andere Ursache

NetDrive behandelt Azure File Storage und Azure Blob Storage als getrennte Verbindungstypen, und ihre Authentifizierungsfehler entstehen an leicht unterschiedlichen Stellen. Blob Storage zeigt auf einen Container; File Storage zeigt auf eine benannte SMB-artige Dateifreigabe unterhalb eines Speicherkontos. Ein auf File Storage aufgebautes Laufwerk braucht drei Werte, um sich korrekt neu zu verbinden — Speicherkontoname, Anmeldedaten (Kontoschlüssel oder SAS-Token) und den exakten Freigabenamen — es gibt also drei Stellen, an denen ein “hat letzte Woche funktioniert, heute nicht mehr”-Fehler entstehen kann.

Prüfung 1: SAS-Token-Ablauf oder ein rotierter Kontoschlüssel

Das ist die häufigste Ursache und lässt sich am schnellsten ausschließen.

1. Öffnen Sie im Azure Portal das Speicherkonto hinter dem fehlerhaften Laufwerk und prüfen Sie, mit welchem Anmeldedatentyp es konfiguriert ist.
2. SAS-Token: Gehen Sie zu Security + networking → Shared access signature und prüfen Sie, ob das Expiry date noch nicht überschritten ist. Ein bei der Einrichtung mit 90 Tagen Gültigkeit erzeugtes Token hört drei Monate später ohne Vorwarnung einfach auf zu funktionieren.
3. Kontoschlüssel: Gehen Sie zu Security + networking → Access keys und prüfen Sie, ob key1 oder key2 kürzlich neu erzeugt wurde — oft von einem anderen Admin im Rahmen der routinemäßigen Schlüsselrotation, ohne zu wissen, dass vier weitere Dienste noch den alten Wert referenzieren.
4. Erzeugen Sie ein neues, auf den File-Dienst beschränktes SAS-Token (mindestens mit den Rechten Read, Write, List, Create, Delete) oder kopieren Sie den aktuellen Kontoschlüssel.
5. Öffnen Sie NetDrive → klicken Sie im Drive Manager auf das Zahnrad-Symbol des betroffenen Laufwerks, um die Verbindungseinstellungen zu öffnen, fügen Sie die neuen Anmeldedaten ein und klicken Sie auf Save.

Prüfung 2: Firewall-Regeln des Speicherkontos

Stimmen die Anmeldedaten und das Laufwerk authentifiziert sich trotzdem nicht, sind als Nächstes die Netzwerkregeln des Speicherkontos dran.

1. Öffnen Sie im Azure Portal Networking → Firewalls and virtual networks für das Speicherkonto.
2. Ist es auf Enabled from selected virtual networks and IP addresses statt All networks eingestellt, weist Azure den Verbindungsversuch ab, bevor es die Anmeldedaten überhaupt prüft — das sieht von NetDrive aus identisch zu einem falschen Schlüssel aus.
3. Prüfen Sie die aktuelle öffentliche IP des Rechners und fügen Sie sie zum erlaubten Bereich hinzu, oder lockern Sie die Regel, falls eine IP-Beschränkung für diese Freigabe nicht nötig ist.

Ein Rechner an einem privaten oder Zweigstellen-Anschluss mit dynamischer IP ist hier ein Wiederholungstäter: Die Regel war korrekt, als sie eingerichtet wurde, und der Provider hat inzwischen eine andere Adresse vergeben.

Prüfung 3: Die Freigabe wurde umbenannt oder entfernt

Anders als ein Blob-Container kann eine File Storage-Freigabe unter demselben Speicherkonto umbenannt, gelöscht und neu angelegt werden, ohne dass sich die Anmeldedaten des Speicherkontos selbst ändern — das bedeutet, Kontoschlüssel oder SAS-Token authentifizieren weiterhin problemlos, aber NetDrive findet die ursprünglich angegebene Freigabe nicht mehr. Gehen Sie im Azure Portal zu Data storage → File shares des Speicherkontos und prüfen Sie, ob der Freigabename bis auf Groß-/Kleinschreibung exakt dem entspricht, was in NetDrives Verbindungseinstellungen eingetragen ist. Wurde die Freigabe nach dem Löschen neu angelegt, aktualisieren Sie das Freigabenamen-Feld in NetDrive, auch wenn sich sonst keine Anmeldedaten geändert haben.

Die Korrektur bestätigen

Nach der Aktualisierung von Anmeldedaten, Firewall-Regel oder Freigabename verbinden Sie das Laufwerk erneut und prüfen, ob es tatsächlich Dateien liefert und nicht nur “Connected” in der Laufwerksliste anzeigt.

Öffnen Sie das Laufwerk im Explorer und listen Sie einen Ordner mit bekannten Dateien auf. Füllt sich die Liste und öffnet sich eine Datei ohne Fehler, sind Anmeldedaten, Netzwerkpfad und Freigabename allesamt korrekt.

Fazit

Authentifizierungsfehler bei Azure File Storage in NetDrive gehen weit häufiger auf ein abgelaufenes SAS-Token, einen rotierten Kontoschlüssel, eine Firewall-Regel des Speicherkontos oder eine umbenannte Freigabe zurück als auf einen Tippfehler in der ursprünglichen Einrichtung — prüfen Sie zuerst die Anmeldedaten, da sie sich schneller ausschließen lassen, dann das Netzwerk. Die anfängliche Verbindungsanleitung finden Sie unter Azure File Storage unter Windows mit NetDrive einbinden; nutzt das betreffende Laufwerk tatsächlich Blob-Container statt einer Dateifreigabe, behandelt Azure Blob-Authentifizierungsfehler beheben den entsprechenden Fall.

— Casey, NetDrive