Freigeben über

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

  • Artikel

In diesem Artikel werden häufig auftretende Probleme aufgeführt, die auftreten können, wenn Sie versuchen, eine Verbindung mit Azure-Dateifreigaben (SMB) von Windows- oder Linux-Clients herzustellen und darauf zuzugreifen. Darüber hinaus werden die möglichen Ursachen und Lösungen für diese Probleme bereitgestellt.

Notiz

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
Standard-Dateifreigaben (GPv2), LRS/ZRS
Standard-Dateifreigaben (GPv2), GRS/GZRS
Premium-Dateifreigaben (FileStorage), LRS/ZRS

Verbindungsherstellung mit oder Einbindung von Azure-Dateifreigabe nicht möglich

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

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

Notiz

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

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.

Zugriff auf die Azure-Dateifreigabe (oder Freigabemomentaufnahme) sowie deren Änderung oder Löschung ist nicht möglich

Fehler "Der Benutzername oder das 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“ beim Versuch, auf eine Azure-Dateifreigabe zuzugreifen oder sie zu löschen

Wenn Sie im Azure-Portal versuchen, auf eine Azure-Dateifreigabe zuzugreifen oder sie zu löschen, wird möglicherweise 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

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 2: Ihr Benutzerkonto besitzt 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 access control (IAM) aus, und stellen Sie sicher, dass Ihr Benutzerkonto Zugriff auf das Speicherkonto hat. Weitere Informationen finden Sie unter Schützen Ihres Speicherkontos mit rollenbasierter Zugriffssteuerung (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 ein versehentliches Ändern oder Löschen von Azure-Dateifreigaben und -Freigabemomentaufnahmen zu verhindern:

  • Speicherkonto-Ressourcensperren: Alle Azure-Ressourcen, einschließlich des Speicherkontos, unterstützen Ressourcensperren. Sperren werden möglicherweise von einem Administrator oder von Diensten wie Azure Backup auf das Speicherkonto gesetzt. Es gibt zwei Variationen von Ressourcensperren: Ändern, wodurch alle Änderungen am Speicherkonto und den zugehörigen Ressourcen verhindert und gelöscht werden, wodurch nur Löschungen des Speicherkontos und der zugehörigen Ressourcen verhindert werden. Beim Ändern oder Löschen von Freigaben über den Ressourcenanbieter Microsoft.Storage werden Ressourcensperren für Azure-Dateifreigaben und -Freigabemomentaufnahmen erzwungen. Die meisten Portalvorgänge, Azure PowerShell-Cmdlets für Azure Files mit Rm dem Namen (z Get-AzRmStorageShare. B. ) und Azure CLI-Befehlen in der share-rm Befehlsgruppe (z az storage share-rm list. B. ) verwenden den Microsoft.Storage Ressourcenanbieter. Einige Tools und Hilfsprogramme wie Storage-Explorer, ältere Azure Files PowerShell-Verwaltungs-Cmdlets ohne Rm Namen (zGet-AzStorageShare. B. ) und ältere Azure Files CLI-Befehle unter der share Befehlsgruppe (zaz storage share list. B. ) verwenden legacy-APIs in der FileREST-API, die den Microsoft.Storage Ressourcenanbieter und Ressourcensperren umgehen. Weitere Informationen zu älteren Verwaltungs-APIs, die in der FileREST-API verfügbar gemacht werden, finden Sie unter Steuerungsebene in Azure Files.

  • Freigabe-/Freigabemomentaufnahme-Leases: Freigabeleases sind eine Art proprietäre Sperre für Azure-Dateifreigaben und -Dateifreigabemomentaufnahmen. Leases können von Administratoren einzelne Azure-Dateifreigaben oder Momentaufnahmen zur Dateifreigabe hinzugefügt werden, indem sie die API über ein Skript oder durch Mehrwertdienste wie Azure Backup aufrufen. Wenn eine Lease für eine Azure-Dateifreigabe oder eine -Dateifreigabemomentaufnahme erstellt wurde, ist das Ändern oder Löschen der Dateifreigabe/Freigabemomentaufnahme mit der Lease-ID möglich. Administratoren können die Lease auch vor Änderungsvorgängen freigeben, was die Lease-ID erfordert, oder die Lease unterbrechen, was die Lease-ID nicht erfordert. Weitere Informationen zu Freigabeleases finden Sie unter Leasefreigabe.

Da Ressourcensperren und -leases beabsichtigte Administratorvorgänge für Ihr Speicherkonto bzw. für Ihre Azure-Dateifreigaben beeinträchtigen können, sollten Sie ggf. alle Ressourcensperren bzw. -leases entfernen, die manuell oder automatisch von Mehrwertdiensten wie Azure Backup für Ihre Ressourcen eingerichtet wurden. Mit dem folgenden Skript werden alle Ressourcensperren und -leases entfernt. Denken Sie daran, <resource-group> und <storage-account> durch die entsprechenden Werte für Ihre Umgebung zu ersetzen.

Bevor Sie das folgende Skript auszuführen, müssen Sie die aktuelle Version des Azure Storage PowerShell-Moduls installieren.

Wichtig

Mehrwertdienste, die Ressourcensperren und Freigabe-/Freigabemomentaufnahmeleases für Ihre Azure Files-Ressourcen verwenden, können Sperren und Leases zeitweise 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 { }
    }

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

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

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.

Notiz

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 erwirbt. Andernfalls können Sie das Anwendungsverhalten unterbrechen.

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.

Hinweis

Die Cmdlets Get-AzStorageFileHandle und Close-AzStorageFileHandle sind in der Azure PowerShell-Modulversion 2.4 oder höher 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. 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

Eine Momentaufnahme einer Azure-Dateifreigabe unter Linux kann nicht eingebunden werden

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

Ursache

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

Lösung

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

Fehler „Ungültiges Momentaufnahmetoken“ beim Versuch, eine Momentaufnahme einer Azure-Dateifreigabe unter Linux einzubinden

Ursache

Wenn die Option „snapshot“ für den Befehl mount beginnend mit @GMT übergeben wird, aber das Format trotzdem falsch ist (z. B. Bindestriche und Doppelpunkte anstelle von Punkten verwendet werden), kann die Ausführung des Befehls mount mit diesem Fehler fehlschlagen.

Lösung

Stellen Sie sicher, dass Sie den GMT-Zeitstempel im richtigen Format übergeben, das heißt @GMT-year.month.day-hour.minutes.seconds. Weitere Informationen finden Sie unter Bereitstellen einer Momentaufnahme einer Dateifreigabe.

„Bereitstellungsfehler (2): Datei oder Verzeichnis nicht vorhanden“ beim Versuch, eine Momentaufnahme einer Azure-Dateifreigabe bereitzustellen

Ursache

Wenn die Momentaufnahme, die Sie bereitstellen 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, die Sie bereitstellen möchten, vorhanden ist. Weitere Informationen zum Auflisten der verfügbaren Momentaufnahmen für eine bestimmte Azure-Dateifreigabe finden Sie unter Bereitstellen einer Momentaufnahme einer Dateifreigabe.

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

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

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.

Notiz

Die Cmdlets Get-AzStorageFileHandle und Close-AzStorageFileHandle sind in der Azure PowerShell-Modulversion 2.4 oder höher 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 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.

Fehler „You are copying a file to a destination that does not support encryption“ (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, in Klartext übermittelt und am Ziel erneut verschlüsselt. Möglicherweise wird jedoch der folgende Fehler angezeigt, wenn Sie versuchen, eine verschlüsselte Datei zu kopieren: „You are copying the file to a destination that does not support encryption“ (Sie kopieren die Datei in ein Ziel, das die Verschlüsselung nicht unterstützt).

Ursache

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

Problemumgehung

Um eine Datei über das Netzwerk zu kopieren, müssen Sie sie zunächst entschlüsseln. Verwenden Sie eine der folgenden Methoden:

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

Beachten Sie jedoch, dass sich das Festlegen des Registrierungsschlüssels auf alle Kopiervorgänge von Netzwerkfreigaben auswirkt.

Fehler „ConditionHeadersNotSupported“ bei einer Webanwendung, die Azure Files über Browser verwendet

Der Fehler „ConditionHeadersNotSupported“ wird angezeigt, wenn versucht wird, über eine Anwendung, die bedingte Header verwendet (z.B. ein Webbrowser), auf in Azure Files gehostete Inhalte zuzugreifen und der Zugriff fehlschlägt. Der Fehler gibt an, dass Bedingungsheader nicht unterstützt werden.

Screenshot der Fehlermeldung

Ursache

Bedingte Header werden noch nicht unterstützt. Anwendungen, die diese Header implementieren, müssen die vollständige Datei jedes Mal anfordern, wenn sie darauf zugreifen.

Problemumgehung

Wenn eine neue Datei hochgeladen wird, ist die CacheControl-Eigenschaft standardmäßig kein Cache. Um zu erzwingen, dass die Anwendung die Datei jedes Mal anfordert, muss die CacheControl-Eigenschaft der Datei von no-cache auf no-cache, no-store, must-revalidate aktualisiert werden. Dies kann über Azure Storage-Explorer geschehen.

Screeshot, der die CacheControl-Dateieigenschaft anzeigt.

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.