Udostępnij za pośrednictwem

Rozwiązywanie problemów z łącznością i dostępem do usługi Azure Files (SMB)

  • Artykuł

W tym artykule wymieniono typowe problemy, które mogą wystąpić podczas próby nawiązania połączenia i uzyskania dostępu do udziałów plików platformy Azure bloku komunikatów serwera (SMB) z klientów systemu Windows lub Linux. Zapewnia również możliwe przyczyny i rozwiązania tych problemów.

Uwaga 16.

Czy ten artykuł był pomocny? Twoje dane wejściowe są dla nas ważne. Użyj przycisku Opinie na tej stronie, aby poinformować nas, jak dobrze działa ten artykuł lub jak możemy go ulepszyć.

Ważne

Ten artykuł dotyczy tylko udziałów SMB. Aby uzyskać szczegółowe informacje o udziałach systemu plików sieciowych (NFS), zobacz Rozwiązywanie problemów z udziałami plików NFS platformy Azure.

Dotyczy

Typ udziału plików SMB NFS
Udziały plików w warstwie Standardowa (GPv2), LRS/ZRS
Udziały plików w warstwie Standardowa (GPv2), GRS/GZRS
Udziały plików w warstwie Premium (FileStorage), LRS/ZRS

Nie można nawiązać połączenia lub zainstalować udziału plików platformy Azure

Wybierz kartę Windows lub Linux w zależności od systemu operacyjnego klienta używanego do uzyskiwania dostępu do udziałów plików platformy Azure.

Podczas próby nawiązania połączenia z udziałem plików platformy Azure w systemie Windows mogą zostać wyświetlone następujące komunikaty o błędach.

Błąd 5 podczas instalowania udziału plików platformy Azure

  • Wystąpił błąd systemowy 5. Odmowa dostępu.

Przyczyna 1. Nieszyfrowany kanał komunikacyjny

Ze względów bezpieczeństwa połączenia z udziałami plików platformy Azure są blokowane, jeśli kanał komunikacyjny nie jest szyfrowany i jeśli próba połączenia nie pochodzi z tego samego centrum danych, w którym znajdują się udziały plików platformy Azure. W przypadku włączenia ustawienia Wymagany bezpieczny transfer na koncie magazynu, nieszyfrowane połączenia w tym samym centrum danych są również blokowane. Szyfrowany kanał komunikacyjny jest udostępniany tylko wtedy, gdy system operacyjny klienta użytkownika końcowego obsługuje szyfrowanie protokołu SMB.

Windows 8, Windows Server 2012 i nowsze wersje każdego systemu negocjują żądania, które obejmują protokół SMB 3.x, który obsługuje szyfrowanie.

Rozwiązanie dla przyczyny 1

  1. Połączenie od klienta obsługującego szyfrowanie SMB (Windows 8/Windows Server 2012 lub nowszy).
  2. Połącz się z maszyny wirtualnej (VM) w tym samym centrum danych co konto usługi Azure Storage, które jest używane dla udziału plików platformy Azure.
  3. Sprawdź, czy ustawienie Wymagany bezpieczny transfer jest wyłączone na koncie magazynu, jeśli klient nie obsługuje szyfrowania protokołu SMB.

Przyczyna 2. Reguły sieci wirtualnej lub zapory są włączone na koncie magazynu

Będzie następować odmowa dostępu dla ruchu sieciowego, jeśli reguły sieci wirtualnej i zapory są skonfigurowane na koncie magazynu, chyba że dostęp będzie dozwolony dla adresu IP klienta lub sieci wirtualnej.

Rozwiązanie dla przyczyny 2

Sprawdź, czy reguły sieci wirtualnej i zapory są skonfigurowane poprawnie na koncie magazynu. W celu przetestowania, czy reguły sieci wirtualnej lub zapory są przyczyną problemu, tymczasowo zmień ustawienie na koncie magazynu, aby zezwolić na dostęp ze wszystkich sieci. Aby dowiedzieć się więcej, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.

Przyczyna 3: Sprawdź, czy uprawnienia na poziomie udziału są niepoprawne w przypadku korzystania z uwierzytelniania opartego na tożsamościach

Jeśli użytkownicy uzyskują dostęp do udziału plików platformy Azure przy użyciu uwierzytelniania opartego na tożsamościach, dostęp do udziału plików kończy się niepowodzeniem z powodu błędu "Odmowa dostępu", jeśli uprawnienia na poziomie udziału są nieprawidłowe.

Rozwiązanie dla przyczyny 3

Sprawdź, czy uprawnienia na poziomie udziału są poprawnie skonfigurowane. Zobacz Przypisywanie uprawnień na poziomie udziału. Przypisania uprawnień na poziomie udziału są obsługiwane w przypadku grup i użytkowników, którzy zostali zsynchronizowani z usług AD DS do usługi Microsoft Entra ID przy użyciu programu Microsoft Entra Connect Sync lub synchronizacji z chmurą microsoft Entra Connect. Upewnij się, że grupy i użytkownicy, którym przypisano uprawnienia na poziomie udziału, nie są nieobsługiwane "tylko w chmurze".

Błąd 53, Błąd 67 lub Błąd 87 podczas instalowania lub odinstalowania udziału plików platformy Azure

Podczas próby zainstalowania udziału plików ze środowiska lokalnego lub innego centrum danych mogą wystąpić następujące błędy:

  • Wystąpił błąd systemowy 53. Nie można znaleźć ścieżki sieciowej.
  • Wystąpił błąd systemowy 67. Nie można znaleźć nazwy sieciowej.
  • Wystąpił błąd systemowy 87. Parametr jest nieprawidłowy.

Przyczyna 1: Port 445 jest zablokowany

Błąd 53 lub błąd systemowy 67 może wystąpić, jeśli port 445 komunikacji wychodzącej do centrum danych usługi Azure Files jest zablokowany. Aby zobaczyć podsumowanie usługodawców internetowych, którzy nie zezwalają na dostęp z portu 445, przejdź do witryny TechNet.

Aby sprawdzić, czy zapora lub usługodawca internetowy blokuje port 445, użyj narzędzia AzFileDiagnostics lub polecenia cmdlet Test-NetConnection.

Aby użyć polecenia Test-NetConnection cmdlet, należy zainstalować moduł Azure PowerShell. Zobacz Instalowanie modułu Azure PowerShell, aby uzyskać więcej informacji. Pamiętaj, aby zastąpić wyrażenia <your-storage-account-name> i <your-resource-group-name> nazwami odpowiednimi dla konta magazynu.

$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

Jeśli połączenie zostało pomyślnie nawiązane, powinny pojawić się następujące dane wyjściowe:

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

Uwaga 16.

To polecenie zwraca bieżący adres IP konta magazynu. Nie ma żadnej gwarancji, że ten adres IP pozostanie niezmieniony. Może on ulec zmianie w dowolnym momencie. Nie umieszczaj tego adresu IP w żadnym kodzie skryptu ani konfiguracji zapory.

Rozwiązania przyczyny 1

Rozwiązanie 1 — użyj usługi Azure File Sync jako punktu końcowego QUIC. Aby uzyskać dostęp do usługi Azure Files od klientów, którzy mają zablokowany port 445, możesz użyć usługi Azure File Sync jako obejścia. Mimo że usługa Azure Files nie obsługuje bezpośrednio protokołu SMB over QUIC, Windows Server 2022 Azure Edition obsługuje protokół QUIC. Można utworzyć uproszczoną pamięć podręczną udziałów plików platformy Azure na maszynie wirtualnej Windows Server 2022 Azure Edition przy użyciu funkcji Azure File Sync. Ta konfiguracja używa portu 443, który jest szeroko otwarty dla ruchu wychodzącego do obsługi protokołu HTTPS zamiast portu 445. Aby dowiedzieć się więcej na temat tej opcji, zobacz Protokół SMB over QUIC z usługą Azure File Sync.

Rozwiązanie 2 — użyj sieci VPN lub usługi ExpressRoute , konfigurując wirtualną sieć prywatną (VPN) lub usługę ExpressRoute ze środowiska lokalnego do konta magazynu platformy Azure, a usługa Azure Files uwidoczniona w sieci wewnętrznej przy użyciu prywatnych punktów końcowych ruch przechodzi przez bezpieczny tunel, a nie przez Internet. Postępuj zgodnie z instrukcjami, aby skonfigurować sieć VPN w celu uzyskania dostępu do usługi Azure Files z systemu Windows.

Rozwiązanie 3 — odblokuj port 445, aby uzyskać pomoc od usługodawcy isp/administratora IT Work with your IT department or ISP to open port 445 outbound to Azure IP ranges (Odblokowywanie portu 445 wychodzącego do zakresów adresów IP platformy Azure).

Rozwiązanie 4 — używaj narzędzi opartych na interfejsie API REST, takich jak Eksplorator usługi Storage lub PowerShell, usługa Azure Files obsługuje również interfejs REST oprócz protokołu SMB. Dostęp do funkcji REST działa przez port 443 (standardowy protokół TCP). Istnieją różne narzędzia napisane przy użyciu interfejsu API REST, które umożliwiają korzystanie z bogatego środowiska interfejsu użytkownika. Eksplorator usługi Storage jest jednym z nich. Pobierz i zainstaluj Eksplorator usługi Storage i połącz się ze swoim udziałem plików obsługiwanym przez usługę Azure Files. Możesz również użyć programu PowerShell , który również używa interfejsu API REST.

Przyczyna 2. Włączono NTLMv1

Błąd systemu 53 lub 87 może wystąpić, jeśli na komputerze klienckim jest włączona komunikacja NTLMv1. Usługa Azure Files obsługuje tylko uwierzytelnianie NTLMv2. Włączenie komunikacji NTLMv1 powoduje, że klient jest mniej bezpieczny. Dlatego komunikacja jest blokowana dla usługi Azure Files.

Aby ustalić, czy jest to przyczyna błędu, sprawdź, czy następujący podklucz rejestru nie jest ustawiony na wartość mniejszą niż 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Aby uzyskać więcej informacji, zobacz temat LmCompatibilityLevel w witrynie TechNet.

Rozwiązanie dla przyczyny 2

Przywróć wartość LmCompatibilityLevel do wartości domyślnej równej 3 w następującym podkluczu rejestru:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Niepowodzenie z kodem błędu 0x800704b3

Podczas próby zainstalowania udziału plików platformy Azure zostanie wyświetlony następujący błąd:

Kod błędu: 0x800704b3
Nazwa symboliczna: ERROR_NO_NET_OR_BAD_PATH
Opis błędu: Ścieżka sieciowa została wpisana niepoprawnie, nie istnieje lub dostawca sieci nie jest obecnie dostępny. Spróbuj ponownie wytypować ścieżkę lub skontaktuj się z administratorem sieci.

Przyczyna

Ten błąd może wystąpić, jeśli jakiekolwiek podstawowe usługi związane z siecią systemu Windows są wyłączone jako każda usługa, która jawnie zależy od tych usług sieciowych, nie będzie można uruchomić.

Rozwiązanie

Sprawdź, czy którakolwiek z następujących usług jest w stanie Zatrzymano na maszynie wirtualnej z systemem Windows:

  • Połączenia sieciowe
  • Usługa listy sieci
  • Rozpoznawanie lokalizacji sieciowej
  • Usługa interfejsu magazynu sieciowego
  • Klient DHCP
  • Pomocnik NetBIOS tcp/IP
  • Stacja robocza

Jeśli znajdziesz jakiekolwiek, uruchom usługi i ponów próbę zainstalowania udziału plików platformy Azure.

Aplikacja lub usługa nie może uzyskać dostępu do zainstalowanego dysku usługi Azure Files

Przyczyna

Dyski są instalowane dla każdego użytkownika. Jeśli aplikacja lub usługa jest uruchomiona na innym koncie użytkownika niż ta, na której zainstalowano dysk, aplikacja nie będzie widzieć dysku.

Rozwiązanie

Zastosuj jedno z następujących rozwiązań:

  • Zainstaluj dysk z tego samego konta użytkownika, które zawiera aplikację. Możesz użyć narzędzia takiego jak PsExec.

  • Przekaż nazwę i klucz konta magazynu w parametrach net use nazwy użytkownika i hasła polecenia.

  • cmdkey Użyj polecenia , aby dodać poświadczenia do Menedżera poświadczeń. Wykonaj tę akcję z wiersza polecenia w kontekście konta usługi za pośrednictwem logowania interakcyjnego lub przy użyciu polecenia runas.

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

  • Mapuj udział bezpośrednio bez użycia zamapowanej litery dysku. Niektóre aplikacje mogą nie łączyć się poprawnie z literą dysku, więc użycie pełnej ścieżki UNC może być bardziej niezawodne:

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

Po wykonaniu tych instrukcji podczas uruchamiania net use dla konta usługi systemowej/sieciowej może zostać wyświetlony następujący komunikat o błędzie: "Wystąpił błąd systemu 1312. Określona sesja logowania nie istnieje. Być może został już zakończony". Jeśli zostanie wyświetlony ten błąd, upewnij się, że przekazana net use nazwa użytkownika zawiera informacje o domenie (na przykład: [storage account name].file.core.windows.net).

Brak folderu z literą dysku w "Mój komputer" lub "Ten komputer"

Jeśli zamapujesz udział plików platformy Azure jako administrator przy użyciu net use polecenia , udział wydaje się brakować.

Przyczyna

Domyślnie Eksplorator plików systemu Windows nie działa jako administrator. Jeśli uruchomisz polecenie net use z poziomu wiersza polecenia administracyjnego, zamapujesz dysk sieciowy jako administrator. Ponieważ zamapowane dyski są skoncentrowane na użytkowniku, konto użytkownika, które jest rejestrowane, nie wyświetla dysków, jeśli są zainstalowane na innym koncie użytkownika.

Rozwiązanie

Zainstaluj udział z poziomu wiersza polecenia innego niż administrator. Alternatywnie możesz wykonać czynności opisane w tym temacie TechNet, aby skonfigurować EnableLinkedConnections wartość rejestru.

Polecenie net use kończy się niepowodzeniem, jeśli konto magazynu zawiera ukośnik

Przyczyna

Polecenie net use interpretuje ukośnik do przodu (/) jako opcję wiersza polecenia. Jeśli nazwa konta użytkownika rozpoczyna się od ukośnika do przodu, mapowanie dysku kończy się niepowodzeniem.

Rozwiązanie

Aby obejść ten problem, możesz użyć jednej z następujących czynności:

  • Uruchom następujące polecenie programu PowerShell:

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

    Z pliku wsadowego możesz uruchomić polecenie w następujący sposób:

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

  • Umieść znaki podwójnego cudzysłowu wokół klucza, aby obejść ten problem — chyba że ukośnik do przodu jest pierwszym znakiem. Jeśli tak jest, użyj trybu interaktywnego i wprowadź hasło oddzielnie lub ponownie wygeneruj klucze, aby uzyskać klucz, który nie zaczyna się od ukośnika.

Polecenie New-PSDrive kończy się niepowodzeniem z powodu błędu "typ zasobu sieciowego jest niepoprawny"

Przyczyna

Jeśli udział plików nie jest dostępny, może zostać wyświetlony ten komunikat o błędzie. Na przykład port 445 jest zablokowany lub występuje problem z rozpoznawaniem nazw DNS.

Rozwiązanie

Upewnij się, że port 445 jest otwarty i sprawdź rozpoznawanie nazw DNS i łączność z udziałem plików.

Nie można uzyskać dostępu, zmodyfikować ani usunąć udziału plików platformy Azure (lub migawki udziału)

Błąd "Nazwa użytkownika lub hasło jest niepoprawny" po przejściu w tryb failover zainicjowanym przez klienta

W scenariuszu trybu failover zainicjowanym przez klienta z kontami magazynu geograficznie nadmiarowego obsługa plików i dzierżawy nie są zachowywane w trybie failover. Klienci muszą odinstalować i ponownie zainstalować udziały plików.

Błąd "Brak dostępu" podczas próby uzyskania dostępu lub usunięcia udziału plików platformy Azure

Podczas próby uzyskania dostępu do udziału plików platformy Azure lub usunięcia go przy użyciu witryny Azure Portal może zostać wyświetlony następujący błąd:

Brak kodu błędu dostępu: 403

Przyczyna 1. Reguły sieci wirtualnej lub zapory są włączone na koncie magazynu

Rozwiązanie przyczyny 1

Sprawdź, czy reguły sieci wirtualnej i zapory są skonfigurowane poprawnie na koncie magazynu. Aby sprawdzić, czy przyczyną problemu jest sieć wirtualna lub reguły zapory, tymczasowo zmień ustawienie na koncie magazynu na zezwalanie na dostęp ze wszystkich sieci. Aby dowiedzieć się więcej, zobacz Konfigurowanie zapór i sieci wirtualnych usługi Azure Storage.

Przyczyna 2: Twoje konto użytkownika nie ma dostępu do konta magazynu

Rozwiązanie dla przyczyny 2

Przejdź do konta magazynu, na którym znajduje się udział plików platformy Azure, wybierz pozycję Kontrola dostępu (IAM) i sprawdź, czy konto użytkownika ma dostęp do konta magazynu. Aby dowiedzieć się więcej, zobacz Jak zabezpieczyć konto magazynu przy użyciu kontroli dostępu na podstawie ról (RBAC) platformy Azure.

Blokady plików i dzierżawy

Jeśli nie możesz zmodyfikować ani usunąć udziału plików lub migawki platformy Azure, może to być spowodowane blokadami plików lub dzierżawami. Usługa Azure Files udostępnia dwa sposoby zapobiegania przypadkowemu modyfikacji lub usunięciu udziałów plików platformy Azure i migawek udziałów:

  • Blokady zasobów konta magazynu: wszystkie zasoby platformy Azure, w tym konto magazynu, obsługują blokady zasobów. Blokady mogą być umieszczane na koncie magazynu przez administratora lub przez usługi, takie jak Azure Backup. Istnieją dwie odmiany blokad zasobów: modyfikowanie, co uniemożliwia wszystkie modyfikacje konta magazynu i jego zasobów oraz usuwanie, co uniemożliwia tylko usunięcie konta magazynu i jego zasobów. Podczas modyfikowania lub usuwania udziałów za pośrednictwem Microsoft.Storage dostawcy zasobów blokady zasobów są wymuszane w udziałach plików platformy Azure i migawkach udziałów. Większość operacji portalu, polecenia cmdlet programu Azure PowerShell dla usługi Azure Files z Rm nazwą (na przykład Get-AzRmStorageShare) i polecenia interfejsu wiersza polecenia platformy Azure w share-rm grupie poleceń (na przykład az storage share-rm list) używają Microsoft.Storage dostawcy zasobów. Niektóre narzędzia i narzędzia, takie jak Eksplorator usługi Storage, starsze polecenia cmdlet zarządzania programu PowerShell usługi Azure Files bez Rm nazwy (na przykład ), i starsze polecenia interfejsu wiersza polecenia usługi Azure Files w share grupie poleceń (na przykład Get-AzStorageShareaz storage share list) używają starszych interfejsów API w interfejsie API FileREST, które pomijają Microsoft.Storage dostawcę zasobów i blokady zasobów. Aby uzyskać więcej informacji na temat starszych interfejsów API zarządzania uwidocznionych w interfejsie API FileREST, zobacz Płaszczyzna sterowania w usłudze Azure Files.

  • Dzierżawy migawek udziałów/udziałów: dzierżawy udziałów są rodzajem zastrzeżonej blokady udziałów plików platformy Azure i migawek udziałów plików. Dzierżawy mogą być umieszczane w poszczególnych udziałach plików platformy Azure lub migawkach udziałów plików przez administratorów przez wywołanie interfejsu API za pośrednictwem skryptu lub usług dodanych przez wartość, takich jak Azure Backup. Gdy dzierżawa zostanie umieszczona w udziale plików platformy Azure lub migawki udziału plików, można zmodyfikować lub usunąć migawkę udziału plików/udziału za pomocą identyfikatora dzierżawy. Administratorzy mogą również zwolnić dzierżawę przed operacjami modyfikacji, co wymaga identyfikatora dzierżawy lub przerwać dzierżawę, która nie wymaga identyfikatora dzierżawy. Aby uzyskać więcej informacji na temat dzierżaw udziałów, zobacz udział dzierżawy.

Ponieważ blokady zasobów i dzierżawy mogą zakłócać zamierzone operacje administratora na koncie magazynu/udziałach plików platformy Azure, możesz usunąć wszelkie blokady/dzierżawy zasobów, które zostały umieszczone na zasobach ręcznie lub automatycznie przez usługi dodane do wartości, takie jak Azure Backup. Poniższy skrypt usuwa wszystkie blokady zasobów i dzierżawy. Pamiętaj, aby zastąpić <resource-group> wartości i <storage-account> odpowiednimi wartościami dla danego środowiska.

Przed uruchomieniem następującego skryptu należy zainstalować najnowszą wersję modułu Programu PowerShell usługi Azure Storage.

Ważne

Usługi dodane do wartości, które przyjmują blokady zasobów i dzierżawy migawek udziałów/udziałów w zasobach usługi Azure Files, mogą okresowo ponownie stosować blokady i dzierżawy. Modyfikowanie lub usuwanie zablokowanych zasobów przez usługi dodane wartości może mieć wpływ na regularną operację tych usług, takich jak usuwanie migawek udziałów zarządzanych przez usługę Azure Backup.

# 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 { }
    }

Nie można zmodyfikować, przenieść/zmienić nazwy lub usunąć pliku lub katalogu

Wybierz kartę Windows lub Linux w zależności od systemu operacyjnego klienta używanego do uzyskiwania dostępu do udziałów plików platformy Azure.

W systemie Windows mogą wystąpić następujące błędy.

Oddzielone dojścia lub dzierżawy plików

Jednym z kluczowych celów udziału plików jest to, że wielu użytkowników i aplikacji może jednocześnie wchodzić korzystać z plików i katalogów w udziale. Aby ułatwić to korzystanie, udziały plików oferują kilka metod zarządzania dostępem do plików i katalogów.

Po otwarciu pliku z zainstalowanego udziału plików platformy Azure za pomocą protokołu SMB aplikacja lub system operacyjny żąda dojścia do pliku, który jest odwołaniem do pliku. Między innymi aplikacja określa tryb udostępniania plików, gdy żąda dojścia do pliku, który określa poziom wyłączności dostępu do pliku wymuszanego przez usługę Azure Files:

  • None: masz wyłączny dostęp.
  • Read: inne osoby mogą odczytywać plik podczas jego otwierania.
  • Write: inne osoby mogą zapisywać w pliku, gdy plik jest otwarty.
  • ReadWrite: kombinacja zarówno trybów udostępniania, jak Read i Write .
  • Delete: inne osoby mogą usunąć plik podczas otwierania.

Mimo że jako protokół bezstanowy protokół FileREST nie ma pojęcia dojścia do plików, zapewnia podobny mechanizm, aby pośrednicować w plikach i folderach, których może używać skrypt, aplikacja lub usługa: dzierżawy plików. Gdy plik jest dzierżawiony, jest traktowany jako odpowiednik dojścia do pliku z trybem Noneudostępniania plików .

Mimo że dojścia plików i dzierżawy służą do ważnego celu, czasami dojścia plików i dzierżawy mogą być oddzielone. Może to powodować problemy z modyfikowaniem lub usuwaniem plików. Mogą występować komunikaty o błędach, takie jak:

  • Proces nie może uzyskać dostępu do pliku, ponieważ jest on używany przez inny proces.
  • Nie można ukończyć akcji, ponieważ plik jest otwarty w innym programie.
  • Dokument jest zablokowany do edycji przez innego użytkownika.
  • Określony zasób jest oznaczony do usunięcia przez klienta SMB.

Rozwiązanie tego problemu zależy od tego, czy jest to spowodowane przez oddzielone dojście do pliku, czy dzierżawę.

Uwaga 16.

Dzierżawy REST są używane przez aplikacje, aby zapobiec usuwaniu lub modyfikowaniu plików. Przed zerwaniem dzierżaw należy określić, która aplikacja je nabywa. W przeciwnym razie może to spowodować przerwanie działania aplikacji.

Przyczyna 1

Dojście do plików uniemożliwia modyfikowanie lub usuwanie pliku/katalogu. Aby wyświetlić otwarte dojścia, możesz użyć polecenia cmdlet Get-AzStorageFileHandle programu PowerShell.

Jeśli wszystkie klienty protokołu SMB zamknęły otwarte dojścia do pliku lub katalogu, a problem nadal występuje, możesz wymusić zamknięcie dojścia do pliku.

Rozwiązanie 1

Aby wymusić zamknięcie dojścia do pliku, użyj polecenia cmdlet Close-AzStorageFileHandle programu PowerShell.

Uwaga 16.

Polecenia Get-AzStorageFileHandle cmdlet i Close-AzStorageFileHandle są zawarte w module Az programu PowerShell w wersji 2.4 lub nowszej. Aby zainstalować najnowszy moduł Az programu PowerShell, zobacz Instalowanie modułu programu Azure PowerShell.

Przyczyna 2

Dzierżawa pliku uniemożliwia zmodyfikowanie lub usunięcie pliku. Możesz sprawdzić, czy plik ma dzierżawę plików za pomocą następujących poleceń programu PowerShell. Zastąp <resource-group>wartości , <storage-account>, <file-share>i <path-to-file> odpowiednimi wartościami dla danego środowiska.

# 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

Jeśli plik ma dzierżawę, zwracany obiekt powinien zawierać następujące właściwości:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Rozwiązanie 2

Aby usunąć dzierżawę z pliku, możesz zwolnić dzierżawę lub ją przerwać. Aby zwolnić dzierżawę, potrzebny jest identyfikator LeaseId dzierżawy, który jest ustawiany podczas jej tworzenia. Nie potrzebujesz identyfikatora LeaseId, aby przerwać dzierżawę.

W poniższym przykładzie pokazano, jak przerwać dzierżawę dla pliku wskazanego w przyczynie 2 (w tym przykładzie są kontynuowane zmienne programu PowerShell z przyczyny 2):

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

Nie można zainstalować migawki udziału plików platformy Azure w systemie Linux

"Błąd instalacji(22): Nieprawidłowy argument" podczas próby zainstalowania migawki udziału plików platformy Azure w systemie Linux

Przyczyna

snapshot Jeśli opcja mount polecenia nie jest przekazywana w rozpoznanym formacie, mount polecenie może zakończyć się niepowodzeniem z powodu tego błędu. Aby to potwierdzić, sprawdź komunikaty dziennika jądra (dmesg) i dmesg wyświetli wpis dziennika, taki jak cifs: Bad value for 'snapshot'.

Rozwiązanie

Upewnij się, że przekazujesz snapshot opcję dla mount polecenia w poprawnym formacie. Zapoznaj się ze stroną ręczną mount.cifs (np. man mount.cifs). Typowy błąd polega na przekazaniu znacznika czasu GMT w niewłaściwym formacie, na przykład przy użyciu łączników lub dwukropków zamiast kropek. Aby uzyskać więcej informacji, zobacz Instalowanie migawki udziału plików.

"Nieprawidłowy token migawki" podczas próby zainstalowania migawki udziału plików platformy Azure w systemie Linux

Przyczyna

Jeśli opcja migawki mount jest przekazywana począwszy od @GMT, ale format jest nadal nieprawidłowy (na przykład przy użyciu łączników i dwukropków zamiast kropek), mount polecenie może zakończyć się niepowodzeniem z powodu tego błędu.

Rozwiązanie

Upewnij się, że przekazujesz znacznik czasu GMT w poprawnym formacie, czyli @GMT-year.month.day-hour.minutes.seconds. Aby uzyskać więcej informacji, zobacz Instalowanie migawki udziału plików.

"Błąd instalacji(2): Brak takiego pliku lub katalogu" podczas próby zainstalowania migawki udziału plików platformy Azure

Przyczyna

Jeśli migawka, którą próbujesz zainstalować, nie istnieje, mount polecenie może zakończyć się niepowodzeniem z powodu tego błędu. Aby to potwierdzić, sprawdź komunikaty dziennika jądra (dmesg) i dmesg wyświetli wpis dziennika, taki jak:

[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

Rozwiązanie

Upewnij się, że migawka, którą próbujesz zainstalować, istnieje. Aby uzyskać więcej informacji na temat wyświetlania listy dostępnych migawek dla danego udziału plików platformy Azure, zobacz Instalowanie migawki udziału plików.

Limit przydziału dysku lub błędy sieci z zbyt wielu otwartych dojść

Wybierz kartę Windows lub Linux w zależności od systemu operacyjnego klienta używanego do uzyskiwania dostępu do udziałów plików platformy Azure.

Błąd 1816 — Brak wystarczającego limitu przydziału do przetworzenia tego polecenia

Przyczyna

Błąd 1816 występuje, gdy osiągniesz górny limit współbieżnych otwartych dojść dozwolonych dla pliku lub katalogu w udziale plików platformy Azure. Aby uzyskać więcej informacji, zobacz Azure Files scale targets (Cele skalowania usługi Azure Files).

Rozwiązanie

Zmniejsz liczbę współbieżnych otwartych dojść, zamykając niektóre uchwyty, a następnie ponów próbę. Aby uzyskać więcej informacji, zobacz Lista kontrolna wydajności i skalowalności usługi Microsoft Azure Storage.

Użyj polecenia cmdlet Get-AzStorageFileHandle programu PowerShell, aby wyświetlić otwarte dojścia do udziałów plików.

Użyj polecenia cmdlet Close-AzStorageFileHandle programu PowerShell, aby zamknąć otwarte dojścia do udziałów plików.

Uwaga 16.

Polecenia Get-AzStorageFileHandle cmdlet i Close-AzStorageFileHandle są zawarte w module Az programu PowerShell w wersji 2.4 lub nowszej. Aby zainstalować najnowszy moduł Az programu PowerShell, zobacz Instalowanie modułu programu Azure PowerShell.

ERROR_UNEXP_NET_ERR (59) podczas wykonywania jakichkolwiek operacji na dojściu

Przyczyna

Jeśli buforujesz/przechowujesz dużą liczbę otwartych dojść przez długi czas, może zostać wyświetlona awaria po stronie serwera z powodu ograniczania przepustowości. Gdy duża liczba dojść jest buforowana przez klienta, wiele z tych dojść może przejść do fazy ponownego łączenia w tym samym czasie, tworząc kolejkę na serwerze, który musi zostać ograniczony. Logika ponawiania i ograniczanie przepustowości zaplecza na potrzeby ponownego nawiązywania połączenia trwa dłużej niż limit czasu klienta. Ta sytuacja manifestuje się jako klient, który nie może użyć istniejącego uchwytu dla żadnej operacji, a wszystkie operacje kończą się niepowodzeniem z ERROR_UNEXP_NET_ERR (59).

Istnieją również przypadki brzegowe, w których dojście klienta zostanie odłączone od serwera (na przykład awaria sieci trwa kilka minut), co może spowodować ten błąd.

Rozwiązanie

Nie należy przechowywać dużej liczby dojść buforowanych. Zamknij uchwyty, a następnie ponów próbę. Użyj Get-AzStorageFileHandle poleceń Close-AzStorageFileHandle cmdlet programu PowerShell, aby wyświetlić/zamknąć otwarte dojścia.

Jeśli używasz udziałów plików platformy Azure do przechowywania kontenerów profilów lub obrazów dysków dla wdrożenia pulpitu wirtualnego na dużą skalę lub innych obciążeń, które otwierają dojścia do plików, katalogów i/lub katalogu głównego, możesz osiągnąć górne limity skalowania dla współbieżnych otwartych dojść. W takim przypadku należy użyć dodatkowego udziału plików platformy Azure i rozpowszechnić kontenery lub obrazy między udziałami.

Błąd "Kopiujesz plik do miejsca docelowego, który nie obsługuje szyfrowania"

Po skopiowaniu pliku za pośrednictwem sieci plik jest odszyfrowywane na komputerze źródłowym, przesyłane w postaci zwykłego tekstu i ponownie szyfrowane w miejscu docelowym. Podczas próby skopiowania zaszyfrowanego pliku może wystąpić następujący błąd: "Kopiujesz plik do miejsca docelowego, który nie obsługuje szyfrowania".

Przyczyna

Ten problem może wystąpić, jeśli używasz systemu szyfrowania plików (EFS). Pliki zaszyfrowane za pomocą funkcji BitLocker można skopiować do usługi Azure Files. Jednak usługa Azure Files nie obsługuje systemu plików NTFS EFS.

Rozwiązanie

Aby skopiować plik za pośrednictwem sieci, należy go najpierw odszyfrować. Użyj jednej z poniższych metod:

  • Użyj polecenia copy /d. Umożliwia zapisanie zaszyfrowanych plików jako odszyfrowanych plików w miejscu docelowym.
  • Ustaw następujący klucz rejestru:
    • Ścieżka = HKLM\Software\Policies\Microsoft\Windows\System
    • Typ wartości = DWORD
    • Nazwa: CopyFileAllowDecryptedRemoteDestination
    • Wartość: 1

Należy pamiętać, że ustawienie klucza rejestru ma wpływ na wszystkie operacje kopiowania wykonywane w udziałach sieciowych.

Błąd ConditionHeadersNotSupported z aplikacji internetowej przy użyciu usługi Azure Files z przeglądarki

Błąd ConditionHeadersNotSupported występuje podczas uzyskiwania dostępu do zawartości hostowanej w usłudze Azure Files za pośrednictwem aplikacji, która korzysta z nagłówków warunkowych, takich jak przeglądarka internetowa, kończy się niepowodzeniem. Błąd wskazuje, że nagłówki warunku nie są obsługiwane.

Zrzut ekranu przedstawiający komunikat o błędzie ConditionHeadersNotSupported.

Przyczyna

Nagłówki warunkowe nie są jeszcze obsługiwane. Aplikacje implementowane przez nie muszą żądać pełnego pliku za każdym razem, gdy plik jest uzyskiwany.

Rozwiązanie

Po przekazaniu nowego pliku właściwość CacheControl domyślnie nie jest pamięcią podręczną. Aby wymusić, aby aplikacja żądała pliku za każdym razem, właściwość CacheControl pliku musi zostać zaktualizowana z braku pamięci podręcznej do no-cache, no-store, must-revalidate. Można to osiągnąć przy użyciu Eksplorator usługi Azure Storage.

Screeshot, który pokazuje właściwość pliku CacheControl.

Zobacz też

Skontaktuj się z nami, aby uzyskać pomoc

Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.