Behandeln von Konnektivitäts- und Zugriffsproblemen in Azure Files (SMB)

Wenn Sie versuchen, eine Verbindung zu einer Azure-Dateifreigabe in Windows herzustellen, erhalten Sie möglicherweise die folgenden Fehlermeldungen.

Fehler 5 beim Bereitstellen einer Azure-Dateifreigabe

• „Systemfehler 5 ist aufgetreten. Zugriff verweigert.“

Ursache 1: Unverschlüsselter Kommunikationskanal

Aus Sicherheitsgründen werden Verbindungen mit Azure-Dateifreigaben blockiert, wenn der Kommunikationskanal nicht verschlüsselt ist und der Verbindungsversuch nicht von dem gleichen Datencenter aus erfolgt, in dem sich die Azure-Dateifreigaben befinden. Wenn die Einstellung Sichere Übertragung erforderlich für das Speicherkonto aktiviert ist, werden auch unverschlüsselte Verbindungen innerhalb des gleichen Rechenzentrums blockiert. Ein verschlüsselter Kommunikationskanal wird nur dann bereitgestellt, wenn das Clientbetriebssystem des Endbenutzers SMB-Verschlüsselung unterstützt.

Windows 8, Windows Server 2012 und höhere Versionen jedes Systems verhandeln Anforderungen, die SMB 3 enthalten.x, das Verschlüsselung unterstützt.

Lösung für Ursache 1

1. Stellen Sie eine Verbindung von einem Client aus her, der SMB-Verschlüsselung unterstützt (Windows 8/Windows Server 2012 oder höher).
2. Stellen Sie eine Verbindung von einer virtuellen Maschine (VM) aus her, der sich im gleichen Rechenzentrum befindet wie das für die Azure-Dateifreigabe verwendete Azure-Speicherkonto.
3. Vergewissern Sie sich, dass die Einstellung Sichere Übertragung erforderlich im Speicherkonto deaktiviert ist, wenn der Client keine SMB-Verschlüsselung unterstützt.

Ursache 2: Virtuelle Netzwerk- oder Firewallregeln sind für das Speicherkonto aktiviert.

Netzwerkdatenverkehr wird abgelehnt, wenn für das Speicherkonto VNet- und Firewallregeln konfiguriert sind, es sei denn, die Client-IP-Adresse oder das virtuelle Netzwerk befinden sich auf einer Positivliste.

Lösung für Ursache 2

Vergewissern Sie sich, dass VNet- und Firewallregeln für das Speicherkonto ordnungsgemäß konfiguriert sind. Um zu testen, ob virtuelle Netzwerk- oder Firewallregeln das Problem verursachen, ändern Sie vorübergehend die Einstellung für das Speicherkonto in Zugriff aus allen Netzwerken zulassen. Weitere Informationen finden Sie unter Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.

Ursache 3: Berechtigungen auf Freigabeebene sind bei Verwendung der identitätsbasierten Authentifizierung falsch

Wenn Nutzer auf die Azure-Dateifreigabe über Active Directory (AD) oder Microsoft Entra Domain Services-Authentifizierung zugreifen, schlägt der Zugriff auf die Dateifreigabe mit dem Fehler „Access is denied“ fehl, wenn die Berechtigungen auf Freigabeebene nicht korrekt sind.

Lösung für Ursache 3

Überprüfen, ob Berechtigungen ordnungsgemäß konfiguriert sind:

• Active Directory Domain Services (AD DS) – siehe Zuweisen von Berechtigungen auf Freigabeebene

  Berechtigungszuweisungen auf Freigabeebene werden für Gruppen und Benutzer unterstützt, die von AD DS mit Microsoft Entra ID mit Microsoft Entra Connect Sync oder Microsoft Entra Connect Cloud sync synchronisiert wurden. Vergewissern Sie sich, dass Gruppen und Benutzer, denen Berechtigungen auf Freigabeebene zugewiesen wurden, keine nicht unterstützten "nur cloudbasierten" Gruppen sind.

• Microsoft Entra Domain Services siehe Berechtigungen auf Freigabeebene zuweisen.

„Fehler 53“, „Fehler 67“ oder „Fehler 87“ beim Versuch, eine Azure-Dateifreigabe einzubinden oder die Einbindung aufzuheben

Wenn Sie versuchen, eine Dateifreigabe aus einem lokalen oder einem anderen Rechenzentrum zu mounten, erhalten Sie möglicherweise die folgenden Fehler:

• „Systemfehler 53 ist aufgetreten. Der Netzwerkpfad wurde nicht gefunden.“
• „Systemfehler 67 ist aufgetreten. „Der Netzwerkname wurde nicht gefunden.“
• „Systemfehler 87 ist aufgetreten. „Der Parameter ist falsch.“

Ursache 1: Port 445 ist blockiert

Systemfehler 53 und Systemfehler 67 können auftreten, wenn die von Port 445 ausgehende Kommunikation zu einem Azure Files-Rechenzentrum blockiert wird. Um eine Zusammenfassung der ISPs anzuzeigen, die den Zugang von Port 445 aus zulassen oder verweigern, gehen Sie auf TechNet.

Um festzustellen, ob der Port 445 durch Ihre Firewall oder Ihren Internetdienstanbieter blockiert wird, können Sie das Tool AzFileDiagnostics oder das Test-NetConnection Cmdlet verwenden.

Um das Test-NetConnection-Cmdlet verwenden zu können, muss das Azure PowerShell-Modul installiert sein. Weitere Informationen finden Sie unter Installieren des Azure PowerShell-Moduls. Denken Sie daran, <your-storage-account-name> und <your-resource-group-name> durch die entsprechenden Namen für Ihr Speicherkonto zu ersetzen.

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

Wenn das Verbinden erfolgreich war, wird die folgende Ausgabe angezeigt:

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

Lösungen für Ursache 1

Lösung 1: Verwenden der Azure-Dateisynchronisierung als QUIC-Endpunkt Sie können die Azure-Dateisynchronisierung als Problemumgehung verwenden, um von Clients aus auf Azure Files zuzugreifen, für die Port 445 blockiert ist. Obwohl Azure Files SMB über QUIC nicht direkt unterstützt, unterstützt Windows Server 2022 Azure Edition das QUIC-Protokoll. Sie können einen einfachen Cache Ihrer Azure-Dateifreigaben auf einer Windows Server 2022 Azure Edition-VM mit der Azure-Dateisynchronisierung erstellen. Diese Konfiguration verwendet Port 443, der weit geöffnet ist, um HTTPS zu unterstützen, statt Port 445. Weitere Informationen zu dieser Option finden Sie unter Azure-Dateisynchronisierung bereitstellen und SMB über QUIC.

Lösung 2 – Verwenden Sie VPN oder ExpressRoute , indem Sie ein virtuelles privates Netzwerk (VPN) oder ExpressRoute von der lokalen zu Ihrem Azure-Speicherkonto einrichten, wobei Azure-Dateien in Ihrem internen Netzwerk mithilfe privater Endpunkte verfügbar gemacht werden, der Datenverkehr durchläuft einen sicheren Tunnel im Gegensatz zu über das Internet. Befolgen Sie die Anweisungen zum Einrichten eines VPN für den Zugriff auf Azure Files von Windows.

Lösung 3: Aufheben der Blockierung von Port 445 mit Unterstützung Ihres ISP/IT-Administrators Öffnen Sie mit Unterstützung Ihrer IT-Abteilung oder Ihres ISP Port 445 ausgehend für Azure-IP-Bereiche.

Lösung 4 – Verwenden Sie REST-API-basierte Tools wie Storage-Explorer oder PowerShell Azure Files unterstützt zusätzlich zu SMB auch REST. Der REST-Zugriff erfolgt über Port 443 (Standard: TCP). Es gibt verschiedene Tools, die mit der REST-API geschrieben wurden und eine vielseitige Benutzeroberfläche bieten. Storage-Explorer ist eines davon. Laden Sie Storage-Explorer herunter, installieren Sie ihn, und stellen eine Verbindung mit Ihrer Dateifreigabe in Azure Files her. Sie können auch PowerShell verwenden, die auch REST-API verwendet.

Ursache 2: NTLMv1 ist aktiviert

„Systemfehler 53“ oder „Systemfehler 87“ können auftreten, wenn die NTLMv1-Kommunikation auf dem Client aktiviert ist. Azure Files unterstützt nur die NTLMv2-Authentifizierung. Wenn NTLMv1 aktiviert ist, ist der Client weniger sicher. Aus diesem Grund wird die Kommunikation für Azure Files blockiert.

Um zu bestimmen, ob dies die Ursache des Fehlers ist, überprüfen Sie, ob der folgende Registrierungsunterschlüssel auf einen Wert unter 3 festgelegt ist:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Weitere Informationen finden Sie im Thema LmCompatibilityLevel im TechNet.

Lösung für Ursache 2

Setzen Sie den Wert LmCompatibilityLevel auf den Standardwert 3 im folgenden Registrierungsunterschlüssel zurück:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Fehler beim Fehlercode 0x800704b3

Wenn Sie versuchen, eine Azure-Dateifreigabe zu mounten, erhalten Sie die folgende Fehlermeldung:

Fehlercode: 0x800704b3
Symbolischer Name: ERROR_NO_NET_OR_BAD_PATH
Fehlerbeschreibung: Der Netzwerkpfad wurde entweder falsch eingegeben, ist nicht vorhanden, oder der Netzwerkanbieter ist derzeit nicht verfügbar. Versuchen Sie, den Pfad neu einzuweisen, oder wenden Sie sich an den Netzwerkadministrator.

Ursache

Dieser Fehler kann auftreten, wenn alle kernbezogenen Windows-Netzwerkdienste deaktiviert sind, da alle Dienste, die explizit von diesen Netzwerkdiensten abhängen, nicht gestartet werden.

Lösung

Überprüfen Sie, ob sich einer der folgenden Dienste im Windows-virtuellen Computer im Status "Beendet " befindet:

• Netzwerkverbindungen
• Netzwerklistendienst
• NLA (Network Location Awareness)
• Netzwerkspeicher-Schnittstellendienst
• DHCP-Client
• TCP/IP-NetBIOS-Hilfsdienst
• Arbeitsstation

Wenn sie gefunden werden, starten Sie die Dienste, und versuchen Sie erneut, die Azure-Dateifreigabe zu installieren.

Anwendung oder Dienst kann nicht auf ein bereitgestelltes Azure Files-Laufwerk zugreifen

Ursache

Laufwerke werden pro Benutzer eingebunden. Wenn Ihre Anwendung oder der Dienst unter einem anderen Benutzerkonto als dem ausgeführt wird, welches das Laufwerk bereitgestellt hat, wird das Laufwerk für die Anwendung nicht angezeigt.

Lösung

Verwenden Sie eine der folgenden Lösungen:

• Binden Sie das Laufwerk vom selben Benutzerkonto ein, das auch die Anwendung enthält. Sie können ein Tool wie z.B. PsExec verwenden.

• Übergeben Sie den Speicherkontonamen und -schlüssel an die Benutzernamen- und Kennwortparameter des Befehls net use.

• Verwenden Sie den Befehl cmdkey, um die Anmeldeinformationen der Anmeldeinformationsverwaltung hinzuzufügen. Führen Sie diese Aktion über eine Befehlszeile im Kontext des Dienstkontos aus. Verwenden Sie dazu entweder eine interaktive Anmeldung oder runas.

  cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>
  

• Ordnen Sie die Freigabe direkt zu, ohne einen zugeordneten Laufwerkbuchstaben zu verwenden. Einige Anwendungen stellen möglicherweise keine ordnungsgemäße Verbindung mit dem Laufwerkbuchstaben her, daher ist die Verwendung des vollständigen UNC-Pfads möglicherweise zuverlässiger:

  net use * \\storage-account-name.file.core.windows.net\share

Nachdem Sie die erforderlichen Schritte der Anleitung durchgeführt haben, erhalten Sie womöglich die folgende Fehlermeldung, wenn Sie „net use“ für das System- bzw. Netzwerkdienstkonto ausführen:„Systemfehler 1312 ist aufgetreten. „Systemfehler 1312 ist aufgetreten. Eine angegebene Anmeldesitzung ist nicht vorhanden. Es wurde möglicherweise bereits beendet." Wenn dieser Fehler angezeigt wird, stellen Sie sicher, dass der benutzername, der an Domäneninformationen übergeben net use wird (z. B.: [storage account name].file.core.windows.net).

Kein Ordner mit einem Laufwerkbuchstaben in „Arbeitsplatz“ oder „Dieser PC“

Wenn Sie eine Azure-Dateifreigabe als Administrator mithilfe des Befehls net use zuordnen, scheint es so, als würde die Freigabe fehlen.

Ursache

Standardmäßig wird der Windows Datei-Explorer nicht als Administrator ausgeführt. Wenn Sie net use von einer administrativen Eingabeaufforderung aus ausführen, ordnen Sie das Netzlaufwerk als Administrator zu. Da zugeordnete Laufwerke benutzerzentriert sind, zeigt das angemeldete Benutzerkonto die Laufwerke nicht an, wenn sie unter einem anderen Benutzerkonto eingebunden wurden.

Lösung

Binden Sie die Freigabe von einer Befehlszeile für Benutzer ohne Administratorrechte aus ein. Alternativ können Sie diesem TechNet-Thema folgen, um den EnableLinkedConnections Registrierungswert zu konfigurieren.

Der Befehl „net use“ schlägt fehl, wenn das Speicherkonto einen Schrägstrich enthält

Ursache

Der Befehl net use interpretiert einen Schrägstrich (/) als Befehlszeilenoption. Wenn der Name Ihres Benutzerkontos mit einem Schrägstrich beginnt, schlägt die Zuordnung des Laufwerks fehl.

Lösung

Sie können eine der folgenden Methoden verwenden, um dieses Problem zu umgehen:

• Führen Sie den folgenden PowerShell-Befehl aus:

  New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"
  

  Von einer Batchdatei aus können Sie wie unten angegeben den Befehl ausführen:

  Echo new-smbMapping ... | powershell -command –

• Setzen Sie den Schlüssel in doppelte Anführungszeichen, um dieses Problem zu umgehen, es sei denn, der Schrägstich ist das erste Zeichen. Wenn dies der Fall ist, verwenden Sie den interaktiven Modus, und geben Sie Ihr Kennwort separat ein, oder generieren Sie Ihre Schlüssel neu, um einen Schlüssel zu erhalten, der nicht mit einem Schrägstrich beginnt.

Der Befehl "New-PSDrive" schlägt mit dem Fehler "Der Netzwerkressourcentyp ist nicht korrekt" fehl.

Ursache

Möglicherweise wird diese Fehlermeldung angezeigt, wenn auf die Dateifreigabe nicht zugegriffen werden kann. Port 445 ist beispielsweise blockiert oder es gibt ein DNS-Lösungsproblem.

Lösung

Stellen Sie sicher, dass Port 445 geöffnet ist, und überprüfen Sie die DNS-Auflösung und Konnektivität mit Ihrer Dateifreigabe.

Häufige Ursachen für dieses Problem:

• Sie verwenden eine Linux-Distribution mit einem veralteten SMB-Client. Weitere Informationen zu allgemeinen Linux-Distributionen, die in Azure verfügbar sind und kompatible Clients haben, finden Sie unter Verwenden von Azure Files mit Linux.
• Auf dem Client sind keine SMB-Hilfsprogramme (cifs-utils) installiert.
• Die SMB-Mindestversion (Version 2.1) steht auf dem Client nicht zur Verfügung.
• Die SMB 3.x-Verschlüsselung wird auf dem Client nicht unterstützt. Die oben aufgeführte Tabelle enthält eine Liste der Linux-Distributionen, die die lokale und regionsübergreifende Bereitstellung unter Verwendung der Verschlüsselung unterstützen. Bei anderen Distributionen wird mindestens die Kernel-Version 4.11 vorausgesetzt.
• Sie versuchen, auf einem virtuellen Azure-Computer eine Verbindung mit einer Azure-Dateifreigabe herzustellen, und der virtuelle Computer befindet sich nicht in derselben Region wie das Speicherkonto.
• Wenn beim Speicherkonto die Einstellung Sichere Übertragung erforderlich aktiviert wurde, lässt Azure Files nur Verbindungen über SMB 3.x mit Verschlüsselung zu.

Lösung

Verwenden Sie das Problembehandlungstool für Azure Files-Bereitstellungsfehlern unter Linux, um das Problem zu beheben. Dieses Tool ermöglicht Folgendes:

• Überprüfen der Clientausführungsumgebung
• Erkennen der nicht kompatiblen Clientkonfiguration, die zu einem Zugriffsfehler für Azure Files führen würde
• Bereitstellen einer Anleitung zur Selbsthilfe
• Erfassen der Diagnoseablaufverfolgungen

„Bereitstellungsfehler (13): Zugriff verweigert“ beim Bereitstellen einer Azure-Dateifreigabe

Ursache 1: Unverschlüsselter Kommunikationskanal

Aus Sicherheitsgründen werden Verbindungen mit Azure-Dateifreigaben blockiert, wenn der Kommunikationskanal nicht verschlüsselt ist und der Verbindungsversuch nicht aus demselben Rechenzentrum hergestellt wird, in dem sich die Azure-Dateifreigaben befinden. Unverschlüsselte Verbindungen innerhalb desselben Datencenters können auch blockiert werden, wenn die Einstellung Sichere Übertragung erforderlich für das Speicherkonto aktiviert ist. Ein verschlüsselter Kommunikationskanal wird nur bereitgestellt, wenn das Clientbetriebssystem des Benutzers die SMB-Verschlüsselung unterstützt.

Weitere Informationen finden Sie unter Voraussetzungen für das Einbinden einer Azure-Dateifreigabe in Linux und das Paket „cifs-utils“.

Lösung für Ursache 1

1. Stellen Sie eine Verbindung von einem Client her, der die SMB-Verschlüsselung unterstützt oder eine Verbindung von einem virtuellen Computer im selben Rechenzentrum wie das Azure-Speicherkonto, das für die Azure-Dateifreigabe verwendet wird.
2. Vergewissern Sie sich, dass die Einstellung Sichere Übertragung erforderlich im Speicherkonto deaktiviert ist, wenn der Client keine SMB-Verschlüsselung unterstützt.

Ursache 2: Virtuelle Netzwerk- oder Firewallregeln sind für das Speicherkonto aktiviert.

Wenn für das Speicherkonto Regeln für das virtuelle Netzwerk (VNET) und die Firewall konfiguriert sind, wird dem Netzwerkverkehr der Zugriff verweigert, es sei denn, der Client-IP-Adresse oder dem virtuellen Netzwerk wird der Zugriff gestattet.

Lösung für Ursache 2

Stellen Sie sicher, dass die VNET- und Firewallregeln für das Speicherkonto ordnungsgemäß konfiguriert sind und der Port 445 zugelassen ist. Um zu testen, ob virtuelle Netzwerke oder Firewallregeln das Problem verursachen, können Sie die Einstellung für das Speicherkonto vorübergehend ändern, um den Zugriff von allen Netzwerken zuzulassen. Weitere Informationen finden Sie unter Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.

Ursache 3: SMB-Client ist für die Verwendung von NTLMv1 konfiguriert.

Azure Files unterstützt nur NTLMv2 und Kerberos für SMB-Dateifreigaben. Kernel 4.4 und höhere Versionen aktivieren STANDARDMÄßIG NTLMv2 und deaktivieren LANMAN. Bei Standardkonfigurationen wird NTLMv1 nur als Aushandlungsoption beibehalten. Weitere Informationen finden Sie in ihrer Betriebssystemdokumentation.

Lösung für Ursache 3

Stellen Sie sicher, dass SMB-Bereitstellungsbefehle die standardmäßige NTLMv2-Authentifizierung nicht über die sec Option außer Kraft setzen. Die sec Option sollte niemals oder beim Herstellen einer Verbindung mit SMB Azure-Dateifreigaben verwendet ntlm ntlmi werden. Wenn Sie globale Optionen in /etc/samba/smb.conf festlegen, stellen Sie sicher, dass Sie NTLMv2 nicht deaktivieren.

Ursache 4: Zugriff auf Speicherkontoschlüssel ist über eine Richtlinie deaktiviert oder unzulässig.

Wenn der Zugriff auf den Speicherkontoschlüssel für ein Speicherkonto deaktiviert oder nicht zulässig ist, funktionieren SAS-Token und Zugriffstasten nicht.

Lösung für Ursache 4

Verwenden Sie die identitätsbasierte Authentifizierung. Die Dateifreigabe muss einer lokales Active Directory Domain Servies (AD DS)- oder Microsoft Entra Domain Services-Domäne beigetreten sein, und der Linux-Client muss für die Verwendung der Kerberos-Authentifizierung konfiguriert werden.

„Bereitstellungsfehler (115): Vorgang wird ausgeführt“ beim Bereitstellen von Azure Files über SMB 3.x

Ursache

Einige Linux-Distributionen unterstützen noch nicht die Verschlüsselungsfeatures in SMB 3.x. Aufgrund eines fehlenden Features erhalten Benutzer möglicherweise eine Fehlermeldung vom Typ „115“, wenn sie versuchen, Azure Files über SMB 3.x einzubinden. SMB 3.x mit vollständiger Verschlüsselung wird nur für die neueste Version einer Linux-Distro unterstützt.

Lösung

Das Verschlüsselungsfeature für SMB 3.x für Linux wurde im Kernel 4.11 eingeführt. Dieses Feature ermöglicht die Bereitstellung einer Azure-Dateifreigabe aus einer lokalen oder einer anderen Azure-Region. Einige Linux-Distributionen verfügen möglicherweise über zurückportierte Änderungen vom 4.11-Kernel zu älteren Versionen des Linux-Kernels, die von ihnen verwaltet werden. Überprüfen Sie unter Verwenden von Azure Files mit Linux, ob Ihre Linux-Version SMB 3.x mit Verschlüsselung unterstützt.

Falls Ihr Linux-SMB-Client die Verschlüsselung nicht unterstützt, binden Sie Azure Files mithilfe von SMB 2.1 von einem virtuellen Linux-Computer aus ein, der sich im gleichen Azure-Rechenzentrum befindet wie die Dateifreigabe. Vergewissern Sie sich, dass die Einstellung Sichere Übertragung erforderlich für das Speicherkonto deaktiviert ist.

„Bereitstellungsfehler (112): Host ist ausgefallen“ aufgrund eines Timeouts bei der Herstellung einer erneuten Verbindung

Ein „112“-Bereitstellungsfehler tritt auf dem Linux-Client auf, wenn sich der Client für eine längere Zeit im Leerlauf befand. Nach einer erweiterten Leerlaufzeit wird der Client getrennt, und das Zeitlimit für die Verbindung ist unterbrochen.

Ursache

Die Verbindung kann aus den folgenden Gründen im Leerlauf sein:

• Netzwerkkommunikationsfehler, die die erneute Einrichtung einer TCP-Verbindung mit dem Server verhindern, wenn die Standardoption "soft" mount verwendet wird.
• Neuere Korrekturen für die erneute Verbindung, die in älteren Kerneln nicht vorhanden sind.

Lösung

Dieses Verbindungswiederherstellungs-Problem im Linux-Kernel wurde jetzt im Rahmen der folgenden Änderungen behoben:

• Fix reconnect to not defer smb3 session reconnect long after socket reconnect (Stellen Sie die Verbindung wieder her, um die Verbindungswiederherstellung der smb3-Sitzung lange nach der Socket-Verbindungswiederherstellung rückzustellen)
• Call echo service immediately after socket reconnect (Sofortiges Aufrufen des Echo-Diensts nach der Socket-Verbindungswiederherstellung)
• CIFS: Fix a possible memory corruption during reconnect (Beheben einer Arbeitsspeicherbeschädigung während der Verbindungswiederherstellung)
• CIFS: Fix a possible double locking of mutex during reconnect (Beheben einer möglichen doppelten Sperre des Mutex während der Verbindungswiederherstellung, für Kernel v4.9 und spätere Versionen)

Diese Änderungen werden jedoch möglicherweise noch nicht zu allen Linux-Distributionen portiert. Wenn Sie eine beliebte Linux-Verteilung verwenden, können Sie die Verwendung von Azure Files mit Linux überprüfen, um festzustellen, welche Version Ihrer Verteilung über die erforderlichen Kerneländerungen verfügt.

Problemumgehung

Sie können dieses Problem umgehen, indem Sie eine ständige Bereitstellung festlegen. Bei einer ständigen Bereitstellung muss der Client auf eine Verbindungsherstellung oder auf eine explizite Unterbrechung warten. Dadurch lassen sich durch Netzwerktimeouts bedingte Fehler verhindern. Diese Problemumgehung kann jedoch endlose Wartevorgänge verursachen. Seien Sie darauf vorbereitet, Verbindungen nach Bedarf zu beenden.

Wenn Sie nicht auf die neuesten Kernelversionen upgraden können, können Sie dieses Problem umgehen, indem Sie eine Datei in der Azure-Dateifreigabe speichern und mindestens alle 30 Sekunden in diese Datei schreiben. Dabei muss es sich um einen Schreibvorgang handeln, wie z.B. die Umschreibung des Erstellungs- oder Änderungsdatums in der Datei. Andernfalls erhalten Sie möglicherweise zwischengespeicherte Ergebnisse, und Ihr Vorgang kann die Verbindungswiederherstellung möglicherweise nicht auslösen.

In Windows werden möglicherweise die folgenden Fehler angezeigt.

Verwaiste Dateihandles oder Leases

Einer der Hauptzwecke einer Dateifreigabe ist, dass mehrere Benutzer und Anwendungen gleichzeitig mit Dateien und Verzeichnissen in der Freigabe interagieren können. Um diese Interaktion zu unterstützen, bieten Dateifreigaben verschiedene Methoden zur Vermittlung des Zugriffs auf Dateien und Verzeichnisse.

Wenn Sie eine Datei aus einer bereitgestellten Azure-Dateifreigabe über SMB öffnen, fordert die Anwendung bzw. das Betriebssystem ein Dateihandle an, bei dem es sich um einen Verweis auf die Datei handelt. Ihre Anwendung gibt unter anderem einen Dateifreigabemodus an, wenn er ein Dateihandle anfordert, das die Exklusivität Ihres Zugriffs auf die Datei angibt, die von Azure Files erzwungen wird:

• None: Sie verfügen über exklusiven Zugriff.
• Read: Andere Benutzer können die Datei lesen, während Sie diese geöffnet haben.
• Write: Andere Benutzer können in die Datei schreiben, während Sie diese geöffnet haben.
• ReadWrite: Eine Kombination der Freigabemodi Read und Write.
• Delete: Andere Benutzer können die Datei löschen, während Sie diese geöffnet haben.

Zwar weist das FileREST-Protokoll als zustandsloses Protokoll kein Konzept für Dateihandles auf, doch es bietet einen ähnlichen Mechanismus zum Vermitteln des Zugriffs auf Dateien und Ordner, die Ihr Skript, Ihre Anwendung oder Ihr Dienst verwenden können: Dateileases. Wenn eine Datei geleast wird, wird Sie wie ein Dateihandle mit dem Dateifreigabemodus None behandelt.

Obwohl Dateihandles und Leases einen wichtigen Zweck erfüllen, können sie manchmal verwaist sein. Dies kann dann Probleme beim Ändern oder Löschen von Dateien verursachen. Möglicherweise werden Fehlermeldungen wie die folgenden angezeigt:

• Der Prozess kann nicht auf die Datei zugreifen, da sie bereits von einem anderen Prozess verwendet wird.
• Die Aktion kann nicht ausgeführt werden, weil die Datei in einem anderen Programm geöffnet ist.
• Das Dokument ist für die Bearbeitung durch einen anderen Benutzer gesperrt.
• Die angegebene Ressource ist zum Löschen durch einen SMB-Client markiert.

Die Lösung für dieses Problem hängt davon ab, ob es durch ein verwaistes Dateihandle oder eine verwaiste Lease verursacht wird.

Ursache 1

Ein Dateihandle verhindert, dass eine Datei bzw. ein Verzeichnis geändert oder gelöscht wird. Sie können das PowerShell-Cmdlet Get-AzStorageFileHandle verwenden, um geöffnete Handles anzuzeigen.

Wenn alle SMB-Clients ihre geöffneten Handles für eine Datei oder ein Verzeichnis geschlossen haben und das Problem weiterhin auftritt, können Sie das Schließen eines Dateihandles erzwingen.

Lösung 1

Um das Schließen eines Dateihandles zu erzwingen, verwenden Sie das PowerShell-Cmdlet Close-AzStorageFileHandle.

Ursache 2

Eine Dateilease verhindert, dass eine Datei geändert oder gelöscht wird. Sie können überprüfen, ob eine Datei mit den folgenden PowerShell-Befehlen über eine Dateilease verfügt. Ersetzen Sie <resource-group>, <storage-account>, <file-share> und <path-to-file> durch die entsprechenden Werte für Ihre Umgebung.

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

Wenn eine Datei über eine Lease verfügt, sollte das zurückgegebene Objekt die folgenden Eigenschaften enthalten:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Lösung 2

Um eine Lease für eine Datei zu entfernen, können Sie die Lease freigeben oder die Lease unterbrechen. Zum Freigeben der Lease benötigen Sie die Lease-ID, die Sie beim Erstellen der Lease festgelegt haben. Sie benötigen die Lease-ID nicht, um die Lease zu unterbrechen.

Im folgenden Beispiel wird gezeigt, wie Sie die Lease für die unter Ursache 2 angegebene Datei unterbrechen (dieses Beispiel wird mit den PowerShell-Variablen aus Ursache 2 fortgesetzt):

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

Unter Linux können die folgenden Probleme auftreten.

Geöffnete Handles für Dateien oder Verzeichnisse

Ursache

Dieses Problem tritt in der Regel auf, wenn für die Datei oder das Verzeichnis ein geöffnetes Handle vorhanden ist.

Lösung

Wenn die SMB-Clients alle geöffneten Handles geschlossen haben und das Problem weiterhin auftritt, führen Sie Folgendes aus:

• Verwenden Sie das PowerShell-Cmdlet Get-AzStorageFileHandle, um geöffnete Handles anzuzeigen.

• Verwenden Sie das PowerShell-Cmdlet Close-AzStorageFileHandle, um geöffnete Handles zu schließen.

Fehler 1816: Unzureichendes Kontingent für die Verarbeitung dieses Befehls

Ursache

Der Fehler 1816 tritt auf, wenn Sie die Obergrenze der parallelen offenen Handles erreichen, die für eine Datei oder ein Verzeichnis in der Azure-Dateifreigabe zulässig sind. Weitere Informationen finden Sie unter Skalierbarkeitsziele für Azure Files.

Lösung

Reduzieren Sie die Anzahl der gleichzeitig geöffneten Handles, indem Sie einige Handles schließen und es anschließend erneut versuchen. Weitere Informationen finden Sie unter Checkliste zur Leistung und Skalierbarkeit von Microsoft Azure Storage.

Verwenden Sie das PowerShell-Cmdlet Get-AzStorageFileHandle, um geöffnete Handles für eine Dateifreigabe, ein Verzeichnis oder eine Datei anzuzeigen.

Verwenden Sie das PowerShell-Cmdlet Close-AzStorageFileHandle, um geöffnete Handles für eine Dateifreigabe, ein Verzeichnis oder eine Datei zu schließen.

„ERROR_UNEXP_NET_ERR (59)“ beim Ausführen von Vorgängen auf einem Handle

Ursache

Wenn Sie eine große Anzahl von geöffneten Handles über lange Zeit zwischenspeichern oder beibehalten, tritt dieser serverseitige Fehler eventuell aufgrund von Drosselung auf. Wenn eine große Anzahl von Handles vom Client zwischengespeichert wird, können viele dieser Handles gleichzeitig in eine neue Verbindungsphase wechseln, sodass sich auf dem Server eine Warteschlange bildet, die gedrosselt werden muss. Die Wiederholungslogik und die Drosselung am Back-End zum nochmaligen Herstellen einer Verbindung dauert länger als das Timeout des Clients. Dies führt dazu, dass ein Client keinen vorhandenen Handle für einen Vorgang nutzen kann, und bei allen Vorgängen der Fehler „ERROR_UNEXP_NET_ERR (59)“ auftritt.

Es gibt auch Grenzfälle, bei denen der Clienthandle vom Server getrennt wird, z. B. durch einen Netzwerkausfall, der mehrere Minuten dauert, was zu diesem Fehler führen kann.

Lösung

Behalten Sie keine große Anzahl zwischengespeicherter Handles bei. Schließen Sie Ziehpunkte, und versuchen Sie es dann erneut. Verwenden Sie die PowerShell-Cmdlets Get-AzStorageFileHandle und Close-AzStorageFileHandle, um geöffnete Handles anzuzeigen/zu schließen.

Wenn Sie Azure-Dateifreigaben zum Speichern von Profilcontainern oder Datenträgerimages für eine umfangreiche virtuelle Desktopbereitstellung oder andere Workloads verwenden, die Handles für Dateien, Verzeichnisse und/oder das Stammverzeichnis öffnen, erreichen Sie möglicherweise die oberen Skalierungsgrenzen für gleichzeitige geöffnete Handles. Verwenden Sie in diesem Fall eine zusätzliche Azure-Dateifreigabe, und verteilen Sie die Container oder Bilder zwischen den Freigaben.

„[Zugriff verweigert] Datenträgerkontingent überschritten“, wenn Sie versuchen, eine Datei zu öffnen

Unter Linux erhalten Sie möglicherweise eine Fehlermeldung ähnlich der folgenden:

<Dateiname> [Berechtigung verweigert] Datenträgerkontingent überschritten

Ursache

Sie haben die obere Grenze der gleichzeitig geöffneten Handles erreicht, die für eine Datei oder ein Verzeichnis zulässig sind.

Azure Files unterstützt 10.000 geöffnete Handles im Stammverzeichnis und 2.000 geöffnete Handles pro Datei und Verzeichnis innerhalb der Freigabe.

Lösung

Verringern Sie die Anzahl gleichzeitig geöffneter Handles, indem Sie einige Handles schließen und dann den Vorgang wiederholen.

Verwenden Sie das PowerShell-Cmdlet Get-AzStorageFileHandle, um geöffnete Handles für eine Dateifreigabe, ein Verzeichnis oder eine Datei anzuzeigen.

Verwenden Sie das PowerShell-Cmdlet Close-AzStorageFileHandle, um geöffnete Handles für eine Dateifreigabe, ein Verzeichnis oder eine Datei zu schließen.