Řešení Azure Files potíží s Windows (SMB)
Tento článek obsahuje seznam běžných problémů souvisejících s Microsoft Azure Files při připojování z Windows klientů. Poskytuje také možné příčiny a řešení těchto problémů. Kromě kroků pro řešení potíží v tomto článku můžete také pomocí nástroje AzFileDiagnostics zajistit, aby Windows klienta splňuje správné požadavky. AzFileDiagnostics automatizuje detekci většiny příznaků uvedených v tomto článku a pomáhá nastavit prostředí pro zajištění optimálního výkonu.
Důležité
Obsah tohoto článku se týká jenom sdílených složek SMB. Podrobnosti o sdílených složek NFS najdete v tématu Řešení potíží se sdílenými složkymi Systému souborů NFS Azure.
Platí pro
| Typ sdílené složky | SMB | NFS |
|---|---|---|
| Standardní sdílené složky (GPv2), LRS/ZRS | ||
| Standardní sdílené složky (GPv2), GRS/GZRS | ||
| Premium sdílené složky (FileStorage), LRS/ZRS |
Chyba 5 při připojování sdílené složky Azure
Při pokusu o připojení sdílené složky se může zobrazit následující chyba:
- Došlo k systémové chybě 5. Přístup byl zamítnut.
Příčina 1: Nešifrovaný komunikační kanál
Z bezpečnostních důvodů se připojení ke sdíleným složkám Azure blokují, když komunikační kanál není šifrovaný a když k pokusu o připojení nedošlo ze stejného datacentra, ve kterém se sdílená složka Azure nachází. Nešifrovaná připojení ze stejného datacentra se můžou blokovat také v případě, že je pro účet úložiště povolené nastavení Vyžadovat zabezpečený přenos. Šifrovaný komunikační kanál je k dispozici pouze v případě, že klientský operační systém uživatele podporuje šifrování protokolu SMB.
Windows 8, Windows Server 2012 a novější verze každého systému vyjednají požadavky, které zahrnují protokol SMB 3.x, který podporuje šifrování.
Řešení 1. příčiny
- Připojení z klienta, který podporuje šifrování SMB (Windows 8, Windows Server 2012 nebo novější), nebo se připojte z virtuálního počítače ve stejném datacentru jako účet úložiště Azure, který se používá pro sdílené složky Azure.
- Pokud klient nepodporuje šifrování SMB, ověřte, že je v účtu úložiště zakázané nastavení Požadováno zabezpečený přenos.
Příčina 2: Pro účet úložiště jsou povolená pravidla virtuální sítě nebo firewallu
Pokud jsou pro účet úložiště nakonfigurovaná pravidla virtuální sítě nebo brány firewall, síťovému provozu se odepře přístup, dokud se nepovolí přístup z virtuální sítě nebo IP adresy klienta.
Řešení 2. příčiny
Ověřte, že jsou pro účet úložiště správně nakonfigurovaná pravidla brány firewall a virtuální sítě. Pokud chcete otestovat, jestli problém způsobují pravidla brány firewall nebo virtuální sítě, dočasně změňte nastavení pro účet úložiště na Povolit přístup ze všech sítí. Další informace najdete v tématu Konfigurace virtuálních sítí a bran firewall Azure Storage.
Příčina 3: Při použití ověřování na základě identity jsou nesprávná oprávnění na úrovni sdílené složky
Pokud uživatelé přistupují ke sdílené složky Azure pomocí ověřování active directory (AD) nebo Azure Active Directory Domain Services (Azure AD DS), přístup ke sdílené sdílené složky selže s chybou Přístup byl odepřen, pokud jsou oprávnění na úrovni sdílené složky nesprávná.
Řešení 3. příčiny
Ověřte, že jsou oprávnění správně nakonfigurovaná:
Active Directory (AD) najdete v tématu Přiřazení oprávnění na úrovni sdílené složky identitě.
Přiřazení oprávnění na úrovni sdílené složky se podporují pro skupiny a uživatele synchronizované z Active Directory (AD) do Azure Active Directory (Azure AD) pomocí Azure AD Připojení. Ověřte, že skupiny a uživatelé, kteří mají přiřazená oprávnění na úrovni sdílené složky, nejsou nepodporované jenom cloudové skupiny.
Azure Active Directory Domain Services (Azure AD DS) najdete v tématu Přiřazení přístupových oprávnění k identitě.
Chyba 53, chyba 67 nebo chyba 87 při připojování nebo odpojování sdílené složky Azure
Při pokusu o připojení sdílené složky z místního prostředí nebo z jiného datacentra se můžou zobrazit následující chyby:
- Došlo k systémové chybě 53. Síťová cesta se nenašla.
- Došlo k systémové chybě 67. Název sítě se nenašel.
- Došlo k systémové chybě 87. Parametr je nesprávný.
Příčina 1: Port 445 je blokovaný
K systémové chybě 53 nebo 67 může dojít v případě, že je zablokovaný port 445 pro odchozí komunikaci Azure Files datacentru. Souhrn poskytovatelů internetových služeb, kteří umožňují nebo neumožňují přístup z portu 445, najdete na webu TechNet.
Pokud chcete zkontrolovat, jestli brána firewall nebo váš isp neblokuje port 445, použijte nástroj Nebo rutinu AzFileDiagnostics. Test-NetConnection
Pokud chcete použít rutinu , musí být Azure PowerShell nainstalovaný modul . Další informace najdete v tématu Test-NetConnection Instalace Azure PowerShell modulu. Nezapomeňte nahradit <your-storage-account-name> a <your-resource-group-name> odpovídajícími názvy pro váš účet úložiště.
$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"
# This command requires you to be logged into your Azure account, run Login-AzAccount 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
Pokud připojení proběhne úspěšně, měl by se zobrazit následující výstup:
ComputerName : <your-storage-account-name>
RemoteAddress : <storage-account-ip-address>
RemotePort : 445
InterfaceAlias : <your-network-interface>
SourceAddress : <your-ip-address>
TcpTestSucceeded : True
Poznámka
Výše uvedený příkaz vrátí aktuální IP adresu účtu úložiště. Není zaručeno, že tato IP adresa zůstane stejná, a kdykoli se může změnit. Nekódujte pevně tuto IP adresu do skriptů ani do konfigurace brány firewall.
Řešení 1. příčiny
1. řešení – Použití Synchronizace souborů Azure
Synchronizace souborů Azure místní server Windows do rychlé mezipaměti sdílené složky Azure. Pro místní přístup k datům můžete použít jakýkoli protokol dostupný ve Windows Serveru, včetně SMB, NFS a FTPS. Synchronizace souborů Azure funguje na portu 443 a proto ji můžou používat klienti se zablokovaným portem 445 jako alternativní způsob přístupu ke službě Azure Files. Zjistěte, jak nastavit Synchronizace souborů Azure.
2. řešení – Použití sítě VPN
Nastavením sítě VPN pro konkrétní účet Storage bude provoz procházet zabezpečeným tunelem, a ne přes internet. Pokud chcete získat přístup ke službě Azure Files z Windows, postupujte podle pokynů k nastavení sítě VPN.
3. řešení – Odblokování portu 445 s pomocí poskytovatele internetových služeb nebo správce IT
Ve vaší službě IT oddělení nebo poskytovatele služeb internetu otevřete port 445 pro odchozí provoz do rozsahů IP adres Azure.
4. řešení – Použití nástrojů založených na rozhraní REST API, jako jsou Průzkumník služby Storage nebo PowerShell
Azure Files podporuje kromě protokolu SMB také REST. Přístup přes rozhraní REST funguje na portu 443 (standardní port TCP). Rozhraní REST API využívají různé nástroje, které nabízejí bohaté uživatelské rozhraní. Průzkumník služby Storage je jedním z nich. Stáhněte a nainstalujte si Průzkumníka služby Storage a připojte se ke své sdílené složce využívající službu Azure Files. Můžete také použít PowerShell, který také používá REST API.
Příčina 2: Je povolený protokol NTLMv1
K systémové chybě 53 nebo 87 může dojít v případě, že je na klientovi povolená komunikace přes protokol NTLMv1. Služba Azure Files podporuje pouze ověřování pomocí protokolu NTLM v2. Klient s povoleným protokolem NTLM v1 je méně zabezpečený. Proto se blokuje komunikace služby Azure Files.
Pokud chcete zjistit, jestli je příčinou chyby, ověřte, že následující podklíč registru není nastavený na hodnotu menší než 3:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel
Další informace najdete v tématu LmCompatibilityLevel na webu TechNet.
Řešení 2. příčiny
V následujícím podklíči registru vraťte hodnotu LmCompatibilityLevel na výchozí hodnotu 3:
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
Chyba 1816 – Pro zpracování tohoto příkazu není k dispozici dostatečný limit kvóty
Příčina
K chybě 1816 dojde, když dosáhnete horního limitu souběžně otevřených popisovačů, které jsou povolené pro soubor nebo adresář ve sdílené složky Azure. Další informace najdete v článku věnovaném cílům škálování služby Azure Files.
Řešení
Snižte počet souběžně otevřených popisovačů tím, že zavřete některé popisovače a zkuste to znovu. Další informace najdete v kontrolním Microsoft Azure Storage výkonu a škálovatelnosti.
Pokud chcete zobrazit otevřené popisovače sdílené složky, adresáře nebo souboru, použijte rutinu PowerShellu Get-AzStorageFileHandle.
Pokud chcete zavřít otevřené popisovače sdílené složky, adresáře nebo souboru, použijte rutinu PowerShellu Close-AzStorageFileHandle.
Poznámka
Rutiny Get-AzStorageFileHandle a Close-AzStorageFileHandle jsou součástí modulu Az PowerShell verze 2.4 nebo novější. Pokud chcete nainstalovat nejnovější modul Az PowerShellu, podívejte se na Azure PowerShell modulu.
Při pokusu o přístup ke sdílené složky Azure nebo odstranění sdílené složky Azure dojde k chybě Bez přístupu
Při pokusu o přístup ke sdílené složky Azure nebo odstranění sdílené složky Azure na portálu se může zobrazit následující chyba:
Bez přístupu
Kód chyby: 403
Příčina 1: Pro účet úložiště jsou povolená pravidla virtuální sítě nebo brány firewall
Řešení 1. příčiny
Ověřte, že jsou pro účet úložiště správně nakonfigurovaná pravidla brány firewall a virtuální sítě. Pokud chcete otestovat, jestli problém způsobují pravidla brány firewall nebo virtuální sítě, dočasně změňte nastavení pro účet úložiště na Povolit přístup ze všech sítí. Další informace najdete v tématu Konfigurace virtuálních sítí a bran firewall Azure Storage.
Příčina 2: Váš uživatelský účet nemá přístup k účtu úložiště
Řešení 2. příčiny
Přejděte k účtu úložiště, ve kterém se nachází sdílená složky Azure, klikněte na Řízení přístupu (IAM) a ověřte, že váš uživatelský účet má přístup k účtu úložiště. Další informace najdete v tématu Zabezpečení účtu úložiště pomocí řízení přístupu na základě role v Azure (Azure RBAC).
Kvůli zámkům nebo zapůjčením není možné upravit nebo odstranit sdílenou složku Azure (nebo snímky sdílené složky).
Azure Files nabízí dva způsoby, jak zabránit nechtěným úpravám nebo odstranění sdílených složek Azure a snímků sdílených složek:
Storage prostředků účtu: Všechny prostředky Azure, včetně účtu úložiště, podporují zámky prostředků. Zámky může na účet úložiště umístit správce nebo služby s přidanou hodnotou, jako je Azure Backup. Existují dvě varianty zámků prostředků: úprava, která brání všem úpravám účtu úložiště a jeho prostředků, a odstranění, které brání jenom odstranění účtu úložiště a jeho prostředků. Při úpravách nebo odstraňování sdílených složek prostřednictvím poskytovatele prostředků se vynucují zámky prostředků pro sdílené složky Azure a
Microsoft.Storagesnímky sdílených složek. Většina operací portálu, Azure PowerShell rutin pro Azure Files s v názvu (tj. ) a příkazy Azure CLI ve skupině příkazůRmGet-AzRmStorageShare(tj. ) používají poskytovateleshare-rmaz storage share-rm listMicrosoft.Storageprostředků. Některé nástroje, jako je Průzkumník služby Storage, starší verze rutin pro správu Azure Files PowerShellu bez názvu (tj. ) a starší příkazy rozhraní Azure Files CLI ve skupině příkazů (tj. ) používají starší rozhraní API v rozhraní FileREST API, která obcházejí poskytovatele prostředků aRmGet-AzStorageShareshareaz storage share listMicrosoft.Storagezámky prostředků. Další informace o starších rozhraních API pro správu zveřejněných v rozhraní FileREST API najdete v tématu řídicí rovina v Azure Files.Zapůjčení snímků sdílené složky nebo sdílené složky: Zapůjčení sdílených složek jsou druhem proprietárního zámku pro sdílené složky Azure a snímky sdílených složek. Zapůjčení můžou správci na jednotlivé sdílené složky Azure nebo snímky sdílených složek Azure zařa poté, co volají rozhraní API prostřednictvím skriptu nebo služeb s přidanou hodnotou, jako je Azure Backup. Při zapůjčení sdílené složky Nebo snímku sdílené složky Azure je možné upravit nebo odstranit snímek sdílené složky nebo sdílené složky pomocí ID zapůjčení. Uživatelé mohou zapůjčení uvolnit také před úpravami operací, které vyžadují ID zapůjčení, nebo zapůjčení přerušit, což id zapůjčení nevyžaduje. Další informace o zapůjčení sdílené složky najdete v tématu o sdíleném zapůjčení.
Vzhledem k tomu, že zámky a zapůjčení prostředků mohou narušovat zamýšlené operace správce vašeho účtu úložiště nebo sdílených složek Azure, můžete chtít odebrat všechny zámky nebo zapůjčení prostředků, které mohly být ručně nebo automaticky nastaveny službami s přidanou hodnotou, jako je Azure Backup. Následující skript odebere všechny zámky a zapůjčení prostředků. Nezapomeňte nahradit a <resource-group> <storage-account> odpovídajícími hodnotami pro vaše prostředí.
Pokud chcete spustit následující skript, musíte nainstalovat verzi 3.10.1-preview modulu Azure Storage PowerShellu.
Důležité
Služby s přidanou hodnotou, které na vašich prostředcích Azure Files nebo sdílené složky vezměte zámky prostředků a zapůjčení snímků sdílené složky nebo sdílené složky, se mohou pravidelně znovu zamykat a pronajímat. Úprava nebo odstranění uzamčených prostředků službami s přidanou hodnotou může mít vliv na pravidelný provoz těchto služeb, například odstranění snímků sdílené složky spravovaných službou 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 { }
}
Soubor nebo adresář není možné upravit, přesunout nebo přejmenovat nebo odstranit
Jedním z klíčových účelů sdílené složky je, že více uživatelů a aplikací může současně pracovat se soubory a adresáři ve sdíleném adresáři. Sdílené složky pomáhají s touto interakcí několika způsoby zprostředkování přístupu k souborům a adresářům.
Když otevřete soubor z připojené sdílené složky Azure přes protokol SMB, vaše aplikace nebo operační systém si vyžádá popisovač souboru, což je odkaz na soubor. Aplikace mimo jiné určuje režim sdílení souborů, když požaduje popisovač souboru, který určuje úroveň vyloučení přístupu k souboru vynucované Azure Files:
None: Máte výhradní přístup.Read: Ostatní si mohou soubor přečíst, když ho máte otevřený.Write: Ostatní mohou do souboru zapisovat, když ho máte otevřený.ReadWrite: Kombinace režimů sdíleníReadiWrite.Delete: Ostatní mohou soubor odstranit, když ho máte otevřený.
I když protokol FileREST nemá jako bezvýcový protokol koncept popisovačů souborů, poskytuje podobný mechanismus pro zprostředkování přístupu k souborům a složkám, který může váš skript, aplikace nebo služba používat: zapůjčení souborů. Pokud je soubor zapůjčován, je považován za ekvivalent popisovače souboru v režimu sdílení souborů None .
I když popisovače a zapůjčení souborů mají důležitý účel, někdy osamocené popisovače a zapůjčení souborů. Pokud k tomu dojde, může to způsobit problémy s úpravou nebo odstraněním souborů. Vidíte například tyto chybové zprávy:
- Proces nemá přístup k souboru, protože ho používá jiný proces.
- Akci nelze dokončit, protože soubor je otevřen v jiném programu.
- Dokument je uzamčen pro úpravy jiným uživatelem.
- Zadaný prostředek je označený k odstranění klientem SMB.
Řešení tohoto problému závisí na tom, jestli je příčinou osamocené popisovač nebo zapůjčení souboru.
Příčina 1
Popisovač souboru brání úprava nebo odstranění souboru nebo adresáře. K zobrazení otevřených popisovačů můžete použít rutinu PowerShellu Get-AzStorageFileHandle.
Pokud všichni klienti SMB zavřeli otevřené popisovače souboru nebo adresáře a problém přetrvává, můžete vynutit zavření popisovače souboru.
Řešení 1
Pokud chcete vynutit uzavření popisovače souboru, použijte rutinu PowerShellu Close-AzStorageFileHandle.
Poznámka
Rutiny Get-AzStorageFileHandle a Close-AzStorageFileHandle jsou součástí modulu Az PowerShell verze 2.4 nebo novější. Pokud chcete nainstalovat nejnovější modul Az PowerShellu, podívejte se na Azure PowerShell modulu.
Příčina 2
Zapůjčení souboru zajišťuje, aby soubor nebylo možné upravit ani odstranit. Pomocí následujícího PowerShellu můžete zkontrolovat, jestli soubor nemá zapůjčení souboru, a nahradit , , a odpovídajícími hodnotami <resource-group> <storage-account> pro vaše <file-share> <path-to-file> prostředí:
# 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
Pokud je soubor zapůjčený, vrácený objekt by měl obsahovat následující vlastnosti:
LeaseDuration : Infinite
LeaseState : Leased
LeaseStatus : Locked
Řešení 2
Pokud chcete odebrat zapůjčení souboru, můžete zapůjčení uvolnit nebo zrušit. K uvolnění zapůjčení potřebujete ID zapůjčení, které jste nastavili při vytváření zapůjčení. Ke zrušení zapůjčení ID zapůjčení nepotřebujete.
Následující příklad ukazuje, jak přerušit zapůjčení souboru uvedeného ve příčině 2 (tento příklad pokračuje s proměnnými PowerShellu z 2. příčiny):
$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null
Pomalé kopírování souborů do služby Azure Files a z ní ve Windows
Při pokusu o přenos souborů do služby Azure File se může zobrazit nízký výkon.
- Pokud nemáte konkrétní požadavek na minimální velikost V/V, doporučujeme pro optimální výkon použít 1 MiB jako velikost V/V.
- Pokud znáte konečnou velikost souboru, který rozšiřujete pomocí zápisů, a váš software nemá problémy s kompatibilitou, pokud nepsané chvost souboru obsahuje nuly, nastavte velikost souboru předem místo toho, aby každý zápis rozšířil zápis.
- Použijte správnou metodu kopírování:
Důležité informace o Windows 8.1 nebo Windows Server 2012 R2
U klientů se systémem Windows 8.1 nebo Windows Server 2012 R2 se ujistěte, že je nainstalovaná oprava hotfix KB3114025. Tato oprava hotfix zlepšuje výkon při vytváření a zavírání popisovačů.
Spuštěním následujícího skriptu můžete zkontrolovat, jestli byla oprava hotfix nainstalovaná:
reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies
Pokud je nainstalovaná oprava hotfix, zobrazí se následující výstup:
HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1
Poznámka
Windows Server 2012 Image R2 v Azure Marketplace ve výchozím nastavení nainstalované opravy hotfix KB3114025 od prosince 2015.
Žádná složka s písmenem jednotky v části Tento počítač nebo Tento počítač
Pokud namapovat sdílené složky Azure jako správce pomocí net use, zdá se, že sdílená složku chybí.
Příčina
Ve výchozím Windows Průzkumník souborů nástroj nespouštěl jako správce. Pokud příkaz net use spustíte z příkazového řádku pro správu, namapovat síťovou jednotku jako správce. Vzhledem k tomu, že jsou mapované jednotky zaměřené na uživatele, uživatelský účet, který je přihlášený, nezobrazí jednotky, pokud jsou připojené pod jiným uživatelským účtem.
Řešení
Připojte sdílené složky z příkazového řádku bez oprávnění správce. Případně můžete podle tohoto tématu na webu TechNet nakonfigurovat hodnotu registru EnableLinkedConnections.
Příkaz NET USE se nezdařil, pokud účet úložiště obsahuje lomítko.
Příčina
Příkaz net use interpretuje lomítko (/) jako parametr příkazového řádku. Pokud název vašeho uživatelského účtu začíná lomítkem, mapování jednotky se nezdařilo.
Řešení
K vyřešení problému můžete použít některý z následujících kroků:
Spusťte následující příkaz PowerShellu:
New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"Pomocí dávkového souboru můžete spustit příkaz tímto způsobem:
Echo new-smbMapping ... | powershell -command –Pokud chcete tento problém obejít, vložte dvojité uvozovky do tohoto klíče – Pokud se před lomítkem nejedná o první znak. Pokud je, buď použijte interaktivní režim a zadejte heslo samostatně, nebo znovu vygenerujte klíče, abyste získali klíč, který nezačíná lomítkem.
Aplikace nebo služba nemůže získat přístup k jednotce připojené služby soubory Azure.
Příčina
Jednotky jsou připojeny na uživatele. Pokud je vaše aplikace nebo služba spuštěná pod jiným uživatelským účtem, než je ten, který jednotku připojil, aplikace tuto jednotku neuvidí.
Řešení
Použijte jedno z následujících řešení:
Připojte jednotku ze stejného uživatelského účtu, který obsahuje aplikaci. Můžete použít nástroj, jako je PsExec.
Název a klíč účtu úložiště předejte do parametrů uživatelské jméno a heslo pro příkaz net use.
Pomocí příkazu cmdkey přidejte přihlašovací údaje do Správce přihlašovacích údajů. Tuto operaci proveďte z příkazového řádku v kontextu účtu služby, a to buď pomocí interaktivního přihlášení, nebo pomocí
runas.cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>Namapujte sdílenou složku přímo bez použití mapovaného písmene jednotky. Některé aplikace se nemusí znovu připojit ke správnému písmenu jednotky, takže použití úplné cesty UNC může být spolehlivější.
net use * \\storage-account-name.file.core.windows.net\share
Po provedení těchto pokynů se může zobrazit následující chybová zpráva, když spustíte příkaz NET USE pro účet System/Network Service: došlo k systémové chybě 1312. Zadaná přihlašovací relace neexistuje. Je možné, že již byla ukončena. " Pokud k tomu dojde, ujistěte se, že uživatelské jméno předané do příkazu net use zahrnuje informace o doméně (například: "[název účtu úložiště]. soubor. Core. Windows. NET").
Chyba: kopírujete soubor do cílového umístění, které nepodporuje šifrování.
Když se soubor zkopíruje přes síť, dešifruje se na zdrojovém počítači, přenáší se do prostého textu a v cíli se znovu zašifruje. Při pokusu o zkopírování zašifrovaného souboru se ale může zobrazit následující chyba: kopírujete soubor do cílového umístění, které šifrování nepodporuje. "
Příčina
K tomuto problému může dojít, pokud používáte systém souborů EFS (Encrypting File System) (EFS). Soubory šifrované BitLockerem je možné zkopírovat do souborů Azure. Soubory Azure ale nepodporují systém souborů NTFS.
Alternativní řešení
Chcete-li zkopírovat soubor přes síť, je nutné jej nejprve dešifrovat. Použijte jednu z následujících metod:
- Použijte příkaz Kopírovat/d . Povoluje ukládání šifrovaných souborů v cílovém umístění jako dešifrovaných souborů.
- Nastavíte následující klíč registru:
- cesta = nastavením hklm\software\policies\microsoft\ Windows \system
- Typ hodnoty = DWORD
- Název = CopyFileAllowDecryptedRemoteDestination
- Hodnota = 1
Mějte na paměti, že nastavení klíče registru ovlivňuje všechny operace kopírování provedené ve sdílených síťových složkách.
Pomalé vyčíslení výčtu souborů a složek
Příčina
K tomuto problému může dojít, pokud na klientském počítači není dost paměti pro velké adresáře.
Řešení
Pokud chcete tento problém vyřešit, upravte hodnotu registru DirectoryCacheEntrySizeMax tak, aby povolovala ukládání většího počtu výpisů adresářů na klientském počítači:
- Umístění: HKLM\System\CCS\Services\Lanmanworkstation\Parameters
- Hodnota Mane: DirectoryCacheEntrySizeMax
- Typ hodnoty: DWORD
Můžete ho například nastavit na 0x100000 a zjistit, jestli se výkon zlepšil.
chyba AadDsTenantNotFound při povolování ověřování služby Azure Active Directory Domain services (azure služba AD DS) pro soubory Azure – nejde najít aktivní klienty s ID tenanta aad-tenant-ID.
Příčina
k chybě AadDsTenantNotFound dojde při pokusu o povolení ověřování Azure Active Directory doménových služeb (azure služba AD DS) na azure Files v účtu úložiště, kde služba azure ad Domain Service (azure služba AD DS) není vytvořená v tenantovi služby azure ad přidruženého předplatného.
Řešení
Povolte Azure služba AD DS v tenantovi Azure AD předplatného, na které je váš účet úložiště nasazený. K vytvoření spravované domény potřebujete oprávnění správce pro tenanta Azure AD. pokud nejste správcem tenanta Azure AD, obraťte se na správce a postupujte podle podrobných pokynů pro vytvoření a konfiguraci spravované domény Azure Active Directory domain Services.
Chyba ConditionHeadersNotSupported z webové aplikace pomocí služby soubory Azure z prohlížeče
K chybě ConditionHeadersNotSupported dojde při přístupu k obsahu hostovanému v souborech Azure pomocí aplikace, která využívá podmíněná záhlaví, jako je webový prohlížeč, ale přístup se nezdařil. Chyba uvádí, že hlavičky podmínek nejsou podporovány.

Příčina
Podmíněné hlavičky ještě nejsou podporované. Aplikace, které je implementují, budou muset požádat o úplný soubor pokaždé, když se k souboru dostanete.
Alternativní řešení
Když se nahraje nový soubor, ve výchozím nastavení vlastnost Control cache je "no-cache". Chcete-li vynutit, aby aplikace vyžadovala soubor pokaždé, je nutné aktualizovat vlastnost řízení mezipaměti souboru z "no-cache" na "no-cache" No-Store ", musí-revalidate". Toho lze dosáhnout pomocí Průzkumník služby Azure Storage.

Nepovedlo se připojit soubory Azure s přihlašovacími údaji služby AD
Kroky pro samočinnou diagnostiku
Nejdřív se ujistěte, že jste provedli všechny čtyři kroky, abyste mohli povolit ověřování Azure Files AD.
Za druhé zkuste připojit sdílenou složku Azure s klíčem účtu úložiště. Pokud se nepovedlo připojit, Stáhněte si AzFileDiagnostics.ps1 , abyste vám pomohli ověřit spuštěné prostředí klienta, zjistit nekompatibilní konfiguraci klienta, která by způsobila selhání přístupu pro soubory Azure, nabízí doporučené pokyny k automatickým opravám a shromažďování diagnostických trasování.
Na třetí, můžete spustit rutinu Debug-AzStorageAccountAuth a provést sadu základních kontrol konfigurace služby AD s přihlášeným uživatelem služby AD. Tuto rutinu podporuje AzFilesHybrid verze 0.1.2 nebo novější. Tuto rutinu je potřeba spustit pod uživatelem AD, který má oprávnění vlastníka k cílovému účtu úložiště.
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
Debug-AzStorageAccountAuth -StorageAccountName $StorageAccountName -ResourceGroupName $ResourceGroupName -Verbose
Tato rutina provádí následující kontroly v posloupnosti a poskytuje pokyny k selhání:
- CheckADObjectPasswordIsCorrect: Ujistěte se, že heslo nakonfigurované na identitě AD, které představuje účet úložiště, odpovídá účtu úložiště kerb1 nebo kerb2 Key. Pokud není heslo správné, můžete heslo resetovat spuštěním rutiny Update-AzStorageAccountADObjectPassword .
- CheckADObject: potvrďte, že ve službě Active Directory existuje objekt, který představuje účet úložiště, a má správný název SPN (hlavní název služby). Pokud hlavní název služby není správně nastavený, spusťte rutinu Set-AD vrácenou v rutině ladění a nakonfigurujte hlavní název služby (SPN).
- CheckDomainJoined: Ověřte, zda je klientský počítač připojen k doméně služby AD. Pokud Váš počítač není připojený k doméně AD, přečtěte si tento článek , kde najdete pokyny k připojení k doméně.
- CheckPort445Connectivity: Ověřte, že je pro připojení SMB otevřený port 445. Pokud požadovaný port není otevřený, přečtěte si další informace o problémech s připojením se soubory Azure v tématu AzFileDiagnostics.ps1 nástroje pro řešení potíží.
- CheckSidHasAadUser: Ověřte, že se přihlášený uživatel služby AD synchronizuje do Azure AD. Pokud chcete vyhledat konkrétního uživatele služby AD, který je synchronizovaný s Azure AD, můžete ve vstupních parametrech zadat-UserName a-Domain.
- CheckGetKerberosTicket: Pokuste se získat lístek protokolu Kerberos pro připojení k účtu úložiště. Pokud není k dispozici platný token protokolu Kerberos, spusťte rutinu příkaz Klist (získat CIFS/Storage-Account-Name. File. Core. Windows. NET a prověřte kód chyby pro hlavní-příčinu selhání načtení lístku.
- CheckStorageAccountDomainJoined: Ověřte, jestli je povolené ověřování AD a naplní se vlastnosti Active Directory účtu. Pokud ne, přečtěte si tady pokyny, abyste povolili služba AD DS ověřování v souborech Azure.
- CheckUserRbacAssignment: Ověřte, jestli má uživatel AD správné přiřazení role RBAC, aby poskytovala oprávnění na úrovni sdílení pro přístup k souborům Azure. Pokud ne, přečtěte si tady pokyny ke konfiguraci oprávnění na úrovni sdílené složky. (Podporováno ve verzi AzFilesHybrid v 0.2.3 +)
- CheckUserFileAccess: ověřte, jestli má uživatel AD ke službě Azure Files správný přístup k adresáři nebo souboru (seznamy acl pro Windows). Pokud ne, přečtěte si tady pokyny ke konfiguraci oprávnění na úrovni adresáře nebo souboru. (Podporováno ve verzi AzFilesHybrid v 0.2.3 +)
nepovedlo se nakonfigurovat oprávnění na úrovni adresáře nebo souboru (Windows acl) pomocí Windows průzkumník souborů.
Příznak
při pokusu o konfiguraci Windowsch seznamů acl pomocí průzkumníka souborů v připojené sdílené složce se můžou vyskytnout příznaky popsané níže:
- Po kliknutí na oprávnění upravit na kartě zabezpečení se Průvodce oprávněními nenačte.
- Když se pokusíte vybrat nového uživatele nebo skupinu, v umístění domény se nezobrazí správná služba AD DS doména.
Řešení
Doporučujeme použít nástroj Icacls ke konfiguraci oprávnění na úrovni adresáře nebo souboru jako alternativní řešení.
Chyby při spuštění rutiny Join-AzStorageAccountForAuth
Chyba: adresářové službě se nepodařilo přidělit relativní identifikátor.
K této chybě může dojít, pokud řadič domény, který obsahuje roli FSMO hlavního serveru RID, není k dispozici nebo byl odebrán z domény a obnoven ze zálohy. Ověřte, že všechny řadiče domény jsou spuštěné a dostupné.
Chyba: Nejde vytvořit vazbu pozičních parametrů, protože se nezadaly žádné názvy
Nejpravděpodobnější příčinou této chyby je chyba syntaxe v příkazu Join-AzStorageAccountforAuth. Zkontrolujte chyby chyb v příkazu nebo chyby syntaxe a ověřte, že je nainstalovaná nejnovější verze modulu AzFilesHybrid ( https://github.com/Azure-Samples/azure-files-samples/releases) .
Azure Files místní ověřování AD DS pro šifrování AES 256 Kerberos
Zavedli jsme podporu šifrování AES 256 Kerberos pro ověřování Azure Files AD DS pomocí modulu AzFilesHybrid verze 0.2.2. Pokud jste povolili ověřování AD DS s nižší verzí modulu než v0.2.2, budete si muset stáhnout nejnovější modul AzFilesHybrid (v0.2.2+) a spustit Níže uvedený PowerShell. Pokud jste ve svém účtu úložiště ještě nepoučili ověřování AD DS, můžete postupovat podle těchto pokynů pro povolení.
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
Update-AzStorageAccountAuthForAES256 -ResourceGroupName $ResourceGroupName -StorageAccountName $StorageAccountName
Potřebujete pomoc? Obraťte se na podporu.
Pokud stále potřebujete pomoc, obraťte se na podporu, aby se váš problém rychle vyřešil.