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

  • Artikel

In diesem Artikel werden häufige Probleme aufgeführt, die auftreten können, wenn Sie versuchen, eine Verbindung mit SMB-Azure-Dateifreigaben (Server Message Block) herzustellen und von Windows- oder Linux-Clients darauf zuzugreifen. Außerdem werden mögliche Ursachen und Lösungen für diese Probleme bereitgestellt.

Hinweis

Waren diese Informationen hilfreich? Wir schätzen Ihr Feedback. Bitte verwenden Sie die Schaltfläche Feedback auf dieser Seite, um uns mitzuteilen, wie gut Ihnen dieser Artikel gefallen hat oder wie wir ihn verbessern können.

Wichtig

Dieser Artikel gilt nur für SMB-Freigaben. Ausführliche Informationen zu NFS-Freigaben (Network File System) finden Sie unter Problembehandlung für Azure NFS-Dateifreigaben.

Gilt für

Dateifreigabetyp SMB NFS
Standarddateifreigaben (GPv2), LRS/ZRS
Standarddateifreigaben (GPv2), GRS/GZRS
Premium-Dateifreigaben (FileStorage), LRS/ZRS

Es kann keine Verbindung mit einer Azure-Dateifreigabe hergestellt oder eingebunden werden.

Wählen Sie je nach Clientbetriebssystem, das Sie für den Zugriff auf Azure-Dateifreigaben verwenden, die Registerkarte Windows oder Linux aus.

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

Fehler 5 beim Einbinden einer Azure-Dateifreigabe

  • Systemfehler 5 ist aufgetreten. Der Zugriff wurde 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 aus demselben Rechenzentrum 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 desselben Rechenzentrums blockiert. Ein verschlüsselter Kommunikationskanal wird nur bereitgestellt, wenn das Clientbetriebssystem des Endbenutzers die SMB-Verschlüsselung unterstützt.

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

Lösung für Ursache 1

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

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

Netzwerkdatenverkehr wird verweigert, wenn das virtuelle Netzwerk (VNET) und Firewallregeln für das Speicherkonto konfiguriert sind, es sei denn, die Client-IP-Adresse oder das virtuelle Netzwerk ist zugelassen.

Lösung für Ursache 2

Stellen Sie sicher, dass virtuelle Netzwerk- und Firewallregeln für das Speicherkonto ordnungsgemäß konfiguriert sind. Um zu testen, ob das Problem durch das virtuelle Netzwerk oder die Firewallregeln verursacht wird, ä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 Benutzer mithilfe von Active Directory (AD) oder Microsoft Entra Domain Services-Authentifizierung auf die Azure-Dateifreigabe zugreifen, tritt beim Zugriff auf die Dateifreigabe der Fehler "Zugriff verweigert" auf, wenn Berechtigungen auf Freigabeebene falsch sind.

Lösung für Ursache 3

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

  • Active Directory Domain Services (AD DS) finden Sie unter Zuweisen von Berechtigungen auf Freigabeebene.

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

  • Microsoft Entra Domain Services finden Sie unter Zuweisen von Berechtigungen auf Freigabeebene.

Fehler 53, Fehler 67 oder Fehler 87 beim Einbinden oder Aufheben der Bereitstellung einer Azure-Dateifreigabe

Wenn Sie versuchen, eine Dateifreigabe aus einer lokalen Umgebung oder einem anderen Rechenzentrum einzubinden, 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. Falscher Parameter.

Ursache 1: Port 445 ist blockiert

Systemfehler 53 oder Systemfehler 67 können auftreten, wenn die ausgehende Kommunikation von Port 445 mit einem Azure Files Rechenzentrum blockiert wird. Eine Zusammenfassung der ISPs, die den Zugriff über Port 445 zulassen oder verweigern, finden Sie unter TechNet.

Um zu überprüfen, ob Ihre Firewall oder Ihr ISP Port 445 blockiert, verwenden Sie das Tool AzFileDiagnostics oder das Test-NetConnection Cmdlet.

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

$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 die Verbindung erfolgreich war, sollte die folgende Ausgabe angezeigt werden:

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

Hinweis

Dieser Befehl gibt die aktuelle IP-Adresse des Speicherkontos zurück. Diese IP-Adresse bleibt nicht garantiert gleich und kann sich jederzeit ändern. Diese IP-Adresse darf nicht in Skripts oder in eine Firewallkonfiguration hartcodiert werden.

Lösungen für Ursache 1

Lösung 1 – Verwenden von Azure-Dateisynchronisierung als QUIC-Endpunkt Sie können Azure-Dateisynchronisierung als Problemumgehung verwenden, um von Clients mit blockiertem Port 445 auf Azure Files zuzugreifen. 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 Azure-Dateisynchronisierung erstellen. Diese Konfiguration verwendet Den Port 443, der für ausgehenden Datenverkehr weit geöffnet ist, um HTTPS zu unterstützen, anstelle von Port 445. Weitere Informationen zu dieser Option finden Sie unter SMB über QUIC mit Azure-Dateisynchronisierung.

Lösung 2– Verwenden von VPN oder ExpressRoute Wenn Sie ein virtuelles privates Netzwerk (VPN) oder ExpressRoute von der lokalen Umgebung zu Ihrem Azure-Speicherkonto einrichten und Azure Files in Ihrem internen Netzwerk über private Endpunkte verfügbar gemacht werden, durchläuft der Datenverkehr einen sicheren Tunnel und nicht über das Internet. Befolgen Sie die Anweisungen zum Einrichten eines VPN, um über Windows auf Azure Files zuzugreifen.

Lösung 3 – Aufheben der Blockierung von Port 445 mit Hilfe Ihres ISP-/IT-Administrators Arbeiten Sie mit Ihrer IT-Abteilung oder Ihrem ISP zusammen, um Port 445 für ausgehende Azure-IP-Bereiche zu öffnen.

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 funktioniert über Port 443 (Standard-TCP). Es gibt verschiedene Tools, die mithilfe der REST-API geschrieben wurden und eine umfassende Benutzeroberfläche ermöglichen. Storage-Explorer ist eine davon. Laden Sie Storage-Explorer herunter, installieren Sie sie, und stellen Sie eine Verbindung mit Ihrer Dateifreigabe her, die von Azure Files unterstützt wird. Sie können auch PowerShell verwenden, die auch die 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, wird ein weniger sicherer Client erstellt. Daher wird die Kommunikation für Azure Files blockiert.

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

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Weitere Informationen finden Sie im Thema LmCompatibilityLevel auf TechNet.

Lösung für Ursache 2

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

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Fehler mit fehlercode 0x800704b3

Wenn Sie versuchen, eine Azure-Dateifreigabe einzubinden, 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. Geben Sie den Pfad erneut ein, oder wenden Sie sich an Den Netzwerkadministrator.

Ursache

Dieser Fehler kann auftreten, wenn alle wichtigsten Windows-Netzwerkdienste deaktiviert sind, da alle Dienste, die explizit von diesen Netzwerkdiensten abhängig sind, nicht gestartet werden können.

Lösung

Überprüfen Sie, ob sich einer der folgenden Dienste auf der Windows-VM im Status Beendet befindet:

  • Netzwerkverbindungen
  • Netzwerklistendienst
  • Netzwerkstandorterkennung
  • Netzwerkspeicherschnittstellendienst
  • DHCP-Client
  • TCP/IP NetBIOS-Hilfsprogramm
  • Arbeitsstation

Wenn Sie einen finden, starten Sie die Dienste, und versuchen Sie erneut, die Azure-Dateifreigabe einzubinden.

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

Ursache

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

Lösung

Verwenden Sie eine der folgenden Lösungen:

  • Binden Sie das Laufwerk aus demselben Benutzerkonto ein, das die Anwendung enthält. Sie können ein Tool wie PsExec verwenden.

  • Übergeben Sie den Namen und schlüssel des Speicherkontos in den Parametern Benutzername und Kennwort des net use Befehls.

  • Verwenden Sie den cmdkey Befehl , um die Anmeldeinformationen dem Anmeldeinformations-Manager hinzuzufügen. Führen Sie diese Aktion über eine Befehlszeile im Dienstkontokontext aus, entweder über eine interaktive Anmeldung oder mithilfe runasvon .

    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 nicht ordnungsgemäß eine Verbindung mit dem Laufwerkbuchstaben her, sodass die Verwendung des vollständigen UNC-Pfads zuverlässiger ist:

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

Nachdem Sie diese Anweisungen befolgt haben, erhalten Sie möglicherweise die folgende Fehlermeldung, wenn Sie net use für das System-/Netzwerkdienstkonto ausführen: "Systemfehler 1312 ist aufgetreten. Eine angegebene Anmeldesitzung ist nicht vorhanden. Es kann sein, dass es bereits beendet wurde." Wenn dieser Fehler angezeigt wird, stellen Sie sicher, dass der Benutzername, der an net use übergeben wird, Domäneninformationen enthält (z. B. ). [storage account name].file.core.windows.net

Kein Ordner mit einem Laufwerkbuchstaben in "Mein Computer" oder "Dieser PC"

Wenn Sie eine Azure-Dateifreigabe mit dem net use Befehl als Administrator zuordnen, scheint die Freigabe zu fehlen.

Ursache

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

Lösung

Binden Sie die Freigabe über eine Nicht-Administrator-Befehlszeile ein. Alternativ können Sie dieses TechNet-Thema befolgen, um den EnableLinkedConnections Registrierungswert zu konfigurieren.

Net Use-Befehl schlägt fehl, wenn das Speicherkonto einen Schrägstrich enthält

Ursache

Der net use Befehl interpretiert einen Schrägstrich (/) als Befehlszeilenoption. Wenn ihr Benutzerkontoname mit einem Schrägstrich beginnt, schlägt die Laufwerkzuordnung fehl.

Lösung

Sie können einen der folgenden Schritte verwenden, um das 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"

    In einer Batchdatei können Sie den Befehl auf folgende Weise ausführen:

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

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

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

Ursache

Diese Fehlermeldung wird möglicherweise angezeigt, wenn auf die Dateifreigabe nicht zugegriffen werden kann. Beispielsweise ist Port 445 blockiert , oder es liegt ein Problem mit der DNS-Auflösung vor.

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.

Zugriff, Änderung oder Löschen einer Azure-Dateifreigabe (oder freigabe Momentaufnahme) nicht möglich

Fehler "Benutzername oder Kennwort ist falsch" nach einem vom Kunden initiierten Failover

In einem vom Kunden initiierten Failoverszenario mit georedundanten Speicherkonten werden Dateihandles und Leases beim Failover nicht beibehalten. Clients müssen die Bereitstellung aufheben und die Dateifreigaben erneut bereitstellen.

Fehler "Kein Zugriff", wenn Sie versuchen, auf eine Azure-Dateifreigabe zuzugreifen oder diese zu löschen

Wenn Sie versuchen, mithilfe des Azure-Portal auf eine Azure-Dateifreigabe zuzugreifen oder diese zu löschen, wird möglicherweise die folgende Fehlermeldung angezeigt:

Kein Zugriff Fehlercode: 403

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

Lösung für Ursache 1

Stellen Sie sicher, dass virtuelle Netzwerk- 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 2: Ihr Benutzerkonto hat keinen Zugriff auf das Speicherkonto.

Lösung für Ursache 2

Navigieren Sie zu dem Speicherkonto, in dem sich die Azure-Dateifreigabe befindet, wählen Sie Zugriffssteuerung (IAM) aus, und überprüfen Sie, ob Ihr Benutzerkonto Zugriff auf das Speicherkonto hat. Weitere Informationen finden Sie unter Schützen Ihres Speicherkontos mit der rollenbasierten Zugriffssteuerung in Azure (Azure RBAC).

Dateisperren und Leases

Wenn Sie eine Azure-Dateifreigabe oder Momentaufnahme nicht ändern oder löschen können, kann dies auf Dateisperren oder Leases zurückzuführen sein. Azure Files bietet zwei Möglichkeiten, um versehentliche Änderungen oder Löschungen von Azure-Dateifreigaben und Freigabemomentaufnahmen zu verhindern:

  • Ressourcensperren für Speicherkonten: Alle Azure-Ressourcen, einschließlich des Speicherkontos, unterstützen Ressourcensperren. Sperren können für das Speicherkonto von einem Administrator oder von Diensten wie Azure Backup eingerichtet werden. Es gibt zwei Varianten von Ressourcensperren: modify, das alle Änderungen am Speicherkonto und seinen Ressourcen verhindert, und Löschen, das nur das Löschen des Speicherkontos und seiner Ressourcen verhindert. Beim Ändern oder Löschen von Freigaben über den Microsoft.Storage Ressourcenanbieter werden Ressourcensperren für Azure-Dateifreigaben und Freigabemomentaufnahmen erzwungen. Die meisten Portalvorgänge, Azure PowerShell Cmdlets für Azure Files mit Rm im Namen (z. BGet-AzRmStorageShare. ) und Azure CLI-Befehle in der share-rm Befehlsgruppe (z. Baz storage share-rm list. ) verwenden den Microsoft.Storage Ressourcenanbieter. Einige Tools und Hilfsprogramme wie Storage-Explorer, Legacy-Azure Files PowerShell-Verwaltungs-Cmdlets ohne Rm den Namen (z. Get-AzStorageShareB. ) und Ältere Azure Files CLI-Befehle unter der share Befehlsgruppe (z. B. ) verwenden Legacy-APIs in der FileREST-API, az storage share listdie den Microsoft.Storage Ressourcenanbieter und Ressourcensperren umgehen. Weitere Informationen zu Legacyverwaltungs-APIs, die in der FileREST-API verfügbar gemacht werden, finden Sie unter Steuerungsebene in Azure Files.

  • Freigabe-/Freigabe-Momentaufnahme-Leases: Freigabeleases sind eine Art proprietäre Sperre für Azure-Dateifreigaben und Dateifreigabemomentaufnahmen. Leases können für einzelne Azure-Dateifreigaben oder Dateifreigabemomentaufnahmen von Administratoren platziert werden, indem die API über ein Skript oder durch Mehrwertdienste wie Azure Backup aufgerufen wird. Wenn eine Lease für eine Azure-Dateifreigabe oder eine Dateifreigabe Momentaufnahme platziert wird, können Sie die Dateifreigabe bzw. -freigabe Momentaufnahme mit der Lease-ID ändern oder löschen. Administratoren können die Lease auch vor Änderungsvorgängen freigeben, die die Lease-ID erfordern, oder die Lease unterbrechen, für die die Lease-ID nicht erforderlich ist. Weitere Informationen zu Freigabeleases finden Sie unter Leasefreigabe.

Da Ressourcensperren und Leases beabsichtigte Administratorvorgänge für Ihr Speicherkonto/Ihre Azure-Dateifreigaben beeinträchtigen können, können Sie alle Ressourcensperren/Leases entfernen, die manuell oder automatisch durch Mehrwertdienste wie Azure Backup für Ihre Ressourcen eingerichtet wurden. Das folgende Skript entfernt alle Ressourcensperren und Leases. Denken Sie daran, und <storage-account> durch die entsprechenden Werte für Ihre Umgebung zu ersetzen<resource-group>.

Bevor Sie das folgende Skript ausführen, sollten Sie die neueste Version des Azure Storage PowerShell-Moduls installieren.

Wichtig

Mehrwertdienste, die Ressourcensperren und Freigabe-/Freigabe-Momentaufnahme Leases für Ihre Azure Files Ressourcen übernehmen, können Sperren und Leases in regelmäßigen Abständen erneut anwenden. Das Ändern oder Löschen gesperrter Ressourcen durch Mehrwertdienste kann sich auf den regulären Betrieb dieser Dienste auswirken, z. B. das Löschen von Freigabemomentaufnahmen, die von Azure Backup verwaltet wurden.

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

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

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

Eine Datei oder ein Verzeichnis kann nicht geändert, verschoben/umbenannt oder gelöscht werden.

Wählen Sie je nach Clientbetriebssystem, das Sie für den Zugriff auf Azure-Dateifreigaben verwenden, die Registerkarte Windows oder Linux aus.

Unter Windows werden möglicherweise die folgenden Fehler angezeigt.

Verwaiste Dateihandles oder Leases

Einer der wichtigsten Zwecke einer Dateifreigabe besteht darin, dass mehrere Benutzer und Anwendungen gleichzeitig mit Dateien und Verzeichnissen in der Freigabe interagieren können. Um diese Interaktion zu unterstützen, bieten Dateifreigaben mehrere Möglichkeiten, den Zugriff auf Dateien und Verzeichnisse zu vermitteln.

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

  • None: Sie haben exklusiven Zugriff.
  • Read: Andere können die Datei lesen, während Sie sie geöffnet haben.
  • Write: Andere können in die Datei schreiben, während sie geöffnet ist.
  • ReadWrite: eine Kombination aus dem Read Freigabemodus und Write dem Freigabemodus.
  • Delete: Andere können die Datei löschen, während sie geöffnet ist.

Obwohl das FileREST-Protokoll als zustandsloses Protokoll kein Konzept von Dateihandles hat, bietet es einen ähnlichen Mechanismus zum Vermitteln des Zugriffs auf Dateien und Ordner, die Ihr Skript, Ihre Anwendung oder Ihr Dienst verwenden kann: Dateileases. Wenn eine Datei geleast wird, wird sie als Äquivalent zu einem Dateihandle mit dem Dateifreigabemodus behandelt None.

Obwohl Dateihandles und Leases einen wichtigen Zweck erfüllen, sind Dateihandles und -leases manchmal verwaist. In diesem Fall kann dies 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 die Datei von einem anderen Prozess verwendet wird.
  • Die Aktion kann nicht abgeschlossen werden, da die Datei in einem anderen Programm geöffnet ist.
  • Das Dokument ist für die Bearbeitung durch einen anderen Benutzer gesperrt.
  • Die angegebene Ressource wird von einem SMB-Client zum Löschen markiert.

Die Lösung dieses Problems hängt davon ab, ob dies durch ein verwaistes Dateihandle oder eine verwaiste Lease verursacht wird.

Hinweis

REST-Leases werden von Anwendungen verwendet, um zu verhindern, dass Dateien gelöscht oder geändert werden. Bevor Sie Leases unterbrechen, sollten Sie ermitteln, welche Anwendung sie abruft. Andernfalls können Sie das Anwendungsverhalten unterbrechen.

Ursache 1

Ein Dateihandle verhindert, dass eine Datei/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/ein Verzeichnis geschlossen haben und das Problem weiterhin auftritt, können Sie das Schließen eines Dateihandles erzwingen.

Lösung 1

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

Hinweis

Die Get-AzStorageFileHandle Cmdlets und Close-AzStorageFileHandle sind in Version 2.4 oder höher des Az PowerShell-Moduls enthalten. Informationen zum Installieren des neuesten Az PowerShell-Moduls finden Sie unter Installieren des Azure PowerShell Moduls.

Ursache 2

Eine Dateilease verhindert, dass eine Datei geändert oder gelöscht wird. Mit den folgenden PowerShell-Befehlen können Sie überprüfen, ob eine Datei ü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 aus einer Datei zu entfernen, können Sie die Lease freigeben oder die Lease unterbrechen. Zum Freigeben der Lease benötigen Sie die Lease-ID der Lease, die Sie beim Erstellen der Lease festlegen. Sie benötigen die LeaseId nicht, um die Lease zu unterbrechen.

Das folgende Beispiel zeigt, wie die Lease für die in Ursache 2 angegebene Datei unterbrochen wird (dieses Beispiel wird mit den PowerShell-Variablen aus Ursache 2 fortgesetzt):

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

Einbinden einer Azure-Dateifreigabe Momentaufnahme unter Linux nicht möglich

"Einbindungsfehler(22): Ungültiges Argument" beim Versuch, eine Azure-Dateifreigabe Momentaufnahme unter Linux einzubinden

Ursache

Wenn die snapshot Option für den mount Befehl nicht in einem erkannten Format übergeben wird, kann der mount Befehl mit diesem Fehler fehlschlagen. Um dies zu bestätigen, überprüfen Sie Kernelprotokollmeldungen (dmesg), und dmesg zeigt einen Protokolleintrag wie cifs: Bad value for 'snapshot'an.

Lösung

Stellen Sie sicher, dass Sie die snapshot Option für den mount Befehl im richtigen Format übergeben. Weitere Informationen finden Sie auf der manuellen Seite mount.cifs (z. B. man mount.cifs). Ein häufiger Fehler ist die Übergabe des GMT-Zeitstempels im falschen Format, z. B. die Verwendung von Bindestrichen oder Doppelpunkten anstelle von Punkten. Weitere Informationen finden Sie unter Einbinden einer Dateifreigabe Momentaufnahme.

"Ungültiges Momentaufnahme-Token" beim Versuch, eine Azure-Dateifreigabe Momentaufnahme unter Linux einzubinden

Ursache

Wenn die option Momentaufnahme mount ab @GMTübergeben wird, aber das Format immer noch falsch ist (z. B. die Verwendung von Bindestrichen und Doppelpunkten anstelle von Punkten), kann der mount Befehl mit diesem Fehler fehlschlagen.

Lösung

Stellen Sie sicher, dass Sie den GMT-Zeitstempel im richtigen Format übergeben, nämlich @GMT-year.month.day-hour.minutes.seconds. Weitere Informationen finden Sie unter Einbinden einer Dateifreigabe Momentaufnahme.

"Einbindungsfehler(2): Datei oder Verzeichnis nicht vorhanden" beim Versuch, eine Azure-Dateifreigabe Momentaufnahme

Ursache

Wenn die Momentaufnahme, die Sie einbinden möchten, nicht vorhanden ist, kann der mount Befehl mit diesem Fehler fehlschlagen. Um dies zu bestätigen, überprüfen Sie Kernelprotokollmeldungen (dmesg), und dmesg zeigt einen Protokolleintrag an, z. B.:

[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2

Lösung

Stellen Sie sicher, dass die Momentaufnahme vorhanden ist, die Sie bereitstellen möchten. Weitere Informationen zum Auflisten der verfügbaren Momentaufnahmen für eine bestimmte Azure-Dateifreigabe finden Sie unter Einbinden einer Dateifreigabe Momentaufnahme.

Datenträgerkontingent- oder Netzwerkfehler durch zu viele geöffnete Handles

Wählen Sie je nach Clientbetriebssystem, das Sie für den Zugriff auf Azure-Dateifreigaben verwenden, die Registerkarte Windows oder Linux aus.

Fehler 1816: Es ist nicht genügend Kontingent verfügbar, um diesen Befehl zu verarbeiten.

Ursache

Fehler 1816 tritt auf, wenn Sie die Obergrenze gleichzeitig geöffneter Handles erreichen, die für eine Datei oder ein Verzeichnis auf der Azure-Dateifreigabe zulässig sind. Weitere Informationen finden Sie unter Azure Files Skalierungsziele.

Lösung

Verringern Sie die Anzahl gleichzeitig geöffneter Handles, indem Sie einige Handles schließen und es dann erneut versuchen. Weitere Informationen finden Sie unter Checkliste für Microsoft Azure Storage Leistung und Skalierbarkeit.

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

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

Hinweis

Die Get-AzStorageFileHandle Cmdlets und Close-AzStorageFileHandle sind in Version 2.4 oder höher des Az PowerShell-Moduls enthalten. Informationen zum Installieren des neuesten Az PowerShell-Moduls finden Sie unter Installieren des Azure PowerShell Moduls.

ERROR_UNEXP_NET_ERR (59) beim Ausführen von Vorgängen für ein Handle

Ursache

Wenn Sie eine große Anzahl geöffneter Handles lange zwischenspeichern bzw. speichern, kann dieser serverseitige Fehler aufgrund von Drosselungsgründen auftreten. Wenn eine große Anzahl von Handles vom Client zwischengespeichert wird, können viele dieser Handles gleichzeitig in eine Phase der erneuten Verbindung wechseln, wodurch eine Warteschlange auf dem Server aufgebaut wird, die gedrosselt werden muss. Die Wiederholungslogik und die Drosselung des Back-Ends für die erneute Verbindung dauern länger als das Timeout des Clients. Diese Situation manifestiert sich darin, dass ein Client kein vorhandenes Handle für einen Vorgang verwenden kann, wobei alle Vorgänge mit ERROR_UNEXP_NET_ERR (59) fehlschlagen.

Es gibt auch Edgefälle, in denen das Clienthandle vom Server getrennt wird (z. B. ein mehrere Minuten dauernder Netzwerkausfall), die diesen Fehler verursachen können.

Lösung

Lassen Sie keine große Anzahl von Handles zwischengespeichert. Schließen Sie Handles, und versuchen Sie es dann erneut. Verwenden Sie Get-AzStorageFileHandle und Close-AzStorageFileHandle PowerShell-Cmdlets, 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 Obergrenzen für gleichzeitig geöffnete Handles. Verwenden Sie in diesem Fall eine zusätzliche Azure-Dateifreigabe, und verteilen Sie die Container oder Images auf die Freigaben.

Fehler "Sie kopieren eine Datei in ein Ziel, das die Verschlüsselung nicht unterstützt"

Wenn eine Datei über das Netzwerk kopiert wird, wird die Datei auf dem Quellcomputer entschlüsselt, im Klartext übertragen und am Ziel erneut verschlüsselt. Beim Versuch, eine verschlüsselte Datei zu kopieren, wird jedoch möglicherweise der folgende Fehler angezeigt: "Sie kopieren die Datei an ein Ziel, das die Verschlüsselung nicht unterstützt."

Ursache

Dieses Problem kann auftreten, wenn Sie verschlüsselndes Dateisystem (Encrypting File System, EFS) verwenden. BitLocker-verschlüsselte Dateien können in Azure Files kopiert werden. Allerdings unterstützt Azure Files NTFS EFS nicht.

Problemumgehung

Um eine Datei über das Netzwerk zu kopieren, müssen Sie sie zuerst entschlüsseln. Wenden Sie eine der folgenden Methoden an:

  • Verwenden Sie den Befehl copy /d . Damit können die verschlüsselten Dateien als entschlüsselte Dateien am Ziel gespeichert werden.
  • Legen Sie den folgenden Registrierungsschlüssel fest:
    • Pfad = HKLM\Software\Policies\Microsoft\Windows\System
    • Werttyp = DWORD
    • Name = CopyFileAllowDecryptedRemoteDestination
    • Wert = 1

Beachten Sie, dass sich das Festlegen des Registrierungsschlüssels auf alle Kopiervorgänge auswirkt, die auf Netzwerkfreigaben ausgeführt werden.

Error ConditionHeadersNotSupported from a Web Application using Azure Files from Browser

Der ConditionHeadersNotSupported-Fehler tritt auf, wenn der Zugriff auf in Azure Files gehostete Inhalte über eine Anwendung, die bedingte Header verwendet, z. B. einen Webbrowser, nicht erfolgreich ist. Der Fehler gibt an, dass Bedingungsheader nicht unterstützt werden.

Screenshot: ConditionHeadersNotSupported-Fehlermeldung

Ursache

Bedingte Header werden noch nicht unterstützt. Anwendungen, die sie implementieren, müssen bei jedem Zugriff auf die Datei die vollständige Datei anfordern.

Problemumgehung

Wenn eine neue Datei hochgeladen wird, ist die CacheControl-Eigenschaft standardmäßig kein Cache. Damit die Anwendung die Datei jedes Mal angibt, muss die CacheControl-Eigenschaft der Datei von no-cache in no-cache, no-store, must-revalidate aktualisiert werden. Dies kann mithilfe von Azure Storage-Explorer erreicht werden.

Screenshot, der die CacheControl-Dateieigenschaft zeigt.

Siehe auch

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.