Azure Files接続とアクセスの問題 (SMB) のトラブルシューティング
この記事では、Windows または Linux クライアントからサーバー メッセージ ブロック (SMB) Azure ファイル共有に接続してアクセスしようとしたときに発生する可能性がある一般的な問題を示します。 また、これらの問題の考えられる原因と解決策も提供します。
注:
この記事はお役に立ちましたか? お客様の入力は、当社にとって重要です。 このページの [フィードバック ] ボタンを使用して、この記事がどれだけうまく機能したか、または改善する方法をお知らせください。
重要
この記事は SMB 共有にのみ適用されます。 ネットワーク ファイル システム (NFS) 共有の詳細については、「 Azure NFS ファイル共有のトラブルシューティング」を参照してください。
適用対象
| ファイル共有の種類 | SMB | Nfs |
|---|---|---|
| 標準ファイル共有 (GPv2)、LRS/ZRS | 
|
|
| 標準ファイル共有 (GPv2)、GRS/GZRS |
|
|
| Premium ファイル共有 (FileStorage)、LRS/ZRS |
|
|
Azure ファイル共有に接続またはマウントできない
Azure ファイル共有にアクセスするために使用しているクライアント オペレーティング システムに応じて、[Windows または Linux] タブを選択します。
Windows で Azure ファイル共有に接続しようとすると、次のエラー メッセージが表示される場合があります。
Azure ファイル共有をマウントするときのエラー 5
- システム エラー 5 が発生しました。 アクセスが拒否されました。
原因 1: 暗号化されていない通信チャネル
セキュリティのために、通信チャネルが暗号化されておらず、Azure ファイル共有が存在するのと同じデータセンターから接続が試行されない場合、Azure ファイル共有への接続はブロックされます。 ストレージ アカウントで [セキュリティで保護された転送が必要] 設定が有効になっている場合、同じデータセンター内の暗号化されていない接続もブロックされます。 暗号化された通信チャネルは、エンド ユーザーのクライアント OS が SMB 暗号化をサポートしている場合にのみ提供されます。
各システムのWindows 8、Windows Server 2012、およびそれ以降のバージョンは、SMB 3 を含む要求をネゴシエートします。x。これは暗号化をサポートします。
原因 1 の解決策
- SMB 暗号化 (Windows 8/Windows Server 2012 以降) をサポートするクライアントから接続します。
- Azure ファイル共有に使用される Azure ストレージ アカウントと同じデータセンター内の仮想マシン (VM) から接続します。
- クライアントが SMB 暗号化をサポートしていない場合は、ストレージ アカウントで [セキュリティで保護された転送が必要 ] 設定が無効になっていることを確認します。
原因 2: 仮想ネットワークまたはファイアウォール規則がストレージ アカウントで有効になっている
クライアント IP アドレスまたは仮想ネットワークが許可されている場合を除き、仮想ネットワーク (VNET) 規則とファイアウォール規則がストレージ アカウントで構成されている場合、ネットワーク トラフィックは拒否されます。
原因 2 の解決策
仮想ネットワークとファイアウォールの規則がストレージ アカウントで正しく構成されていることを確認します。 仮想ネットワークまたはファイアウォール規則によって問題が発生しているかどうかをテストするには、ストレージ アカウントの設定を一時的に [ すべてのネットワークからのアクセスを許可する] に変更します。 詳細については、「 Azure Storage ファイアウォールと仮想ネットワークの構成」を参照してください。
原因 3: ID ベースの認証を使用する場合、共有レベルのアクセス許可が正しくありません
ユーザーが Active Directory (AD) またはMicrosoft Entra Domain Services認証を使用して Azure ファイル共有にアクセスしている場合、共有レベルのアクセス許可が正しくない場合、ファイル共有へのアクセスは "アクセスが拒否されました" というエラーで失敗します。
原因 3 の解決策
アクセス許可が正しく構成されていることを検証します。
Active Directory Domain Services (AD DS) については、「共有レベルのアクセス許可を割り当てる」を参照してください。
共有レベルのアクセス許可の割り当ては、MICROSOFT ENTRA Connect Sync または connect クラウド同期を使用して AD DS からMicrosoft Entra IDに同期されたグループとユーザー Microsoft Entraサポートされます。共有レベルのアクセス許可が割り当てられているグループとユーザーが、サポートされていない "クラウド専用" グループではないことを確認します。
Microsoft Entra Domain Services「共有レベルのアクセス許可を割り当てる」を参照してください。
Azure ファイル共有をマウントまたはマウント解除するときのエラー 53、エラー 67、またはエラー 87
オンプレミスまたは別のデータセンターからファイル共有をマウントしようとすると、次のエラーが発生する可能性があります。
- システム エラー 53 が発生しました。 ネットワーク パスが見つかりませんでした。
- システム エラー 67 が発生しました。 ネットワーク名が見つかりません。
- システム エラー 87 が発生しました。 パラメーターが間違っています。
原因 1: ポート 445 がブロックされている
Azure Files データセンターへのポート 445 送信通信がブロックされている場合、システム エラー 53 またはシステム エラー 67 が発生する可能性があります。 ポート 445 からのアクセスを許可または禁止する ISP の概要を確認するには、 TechNet に移動します。
ファイアウォールまたは ISP がポート 445 をブロックしているかどうかをチェックするには、AzFileDiagnostics ツールまたはコマンドレットをTest-NetConnection使用します。
コマンドレットをTest-NetConnection使用するには、Azure PowerShell モジュールをインストールする必要があります。 詳細については、「Azure PowerShell モジュールのインストール」を参照してください。 と は、ストレージ アカウントに関連する名前に置き換えてください<your-storage-account-name><your-resource-group-name>。
$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"
# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName
# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445
接続が成功した場合は、次の出力が表示されます。
ComputerName : <your-storage-account-name>
RemoteAddress : <storage-account-ip-address>
RemotePort : 445
InterfaceAlias : <your-network-interface>
SourceAddress : <your-ip-address>
TcpTestSucceeded : True
注:
このコマンドは、ストレージ アカウントの現在の IP アドレスを返します。 この IP アドレスは、常に変わる可能性があり、同じままである保証はありません。 この IP アドレスをスクリプトやファイアウォール構成にハードコーディングしないでください。
原因 1 の解決策
解決策 1 — AZURE FILE SYNCを QUIC エンドポイントとして使用する Azure File Syncを回避策として使用して、ポート 445 がブロックされているクライアントからAzure Filesにアクセスできます。 Azure Filesは QUIC 経由の SMB を直接サポートしていませんが、Windows Server 2022 Azure Edition では QUIC プロトコルがサポートされています。 Azure File Syncを使用して、Windows Server 2022 Azure Edition VM 上に Azure ファイル共有の軽量キャッシュを作成できます。この構成では、ポート 445 ではなく HTTPS をサポートするために広く開かれているポート 443 が使用されます。 このオプションの詳細については、「Azure File Syncを使用した QUIC 経由の SMB」を参照してください。
解決策 2 - VPN または ExpressRoute を使用するオンプレミスから Azure ストレージ アカウントに仮想プライベート ネットワーク (VPN) または ExpressRoute を設定し、プライベート エンドポイントを使用して内部ネットワークにAzure Files公開することで、トラフィックはインターネット経由ではなくセキュリティで保護されたトンネルを経由します。 手順に従って、Windows からAzure Filesにアクセスするための VPN を設定します。
解決策 3 — ISP/IT 管理者の助けを借りてポート 445 のブロックを解除 するIT 部門または ISP と連携して、 Azure IP 範囲へのポート 445 アウトバウンドを開きます。
解決策 4 - STORAGE EXPLORERや PowerShell などの REST API ベースのツールを使用Azure Files、SMB に加えて REST もサポートします。 REST アクセスは、ポート 443 (標準 tcp) で動作します。 豊富な UI エクスペリエンスを実現する REST API を使用して記述されるさまざまなツールがあります。 Storage Explorerもその 1 つです。 Storage Explorerをダウンロードしてインストールし、Azure Filesによってサポートされているファイル共有に接続します。 REST API も使用する PowerShell を使用することもできます。
原因 2: NTLMv1 が有効になっている
クライアントで NTLMv1 通信が有効になっている場合、システム エラー 53 またはシステム エラー 87 が発生する可能性があります。 Azure Filesでは、NTLMv2 認証のみがサポートされます。 NTLMv1 を有効にすると、セキュリティが低いクライアントが作成されます。 そのため、通信はAzure Filesに対してブロックされます。
これがエラーの原因であるかどうかを判断するには、次のレジストリ サブキーが 3 未満の値に設定されていないことを確認します。
HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel
詳細については、TechNet の LmCompatibilityLevel トピックを参照してください。
原因 2 の解決策
次の LmCompatibilityLevel レジストリ サブキーで、値を既定値の 3 に戻します。
HKLM\SYSTEM\CurrentControlSet\Control\Lsa
マウントされたAzure Files ドライブにアプリケーションまたはサービスがアクセスできない
原因
ドライブはユーザーごとにマウントされます。 アプリケーションまたはサービスが、ドライブをマウントしたユーザー アカウントとは異なるユーザー アカウントで実行されている場合、アプリケーションにはドライブが表示されません。
ソリューション
次のいずれかのソリューションを使用します。
アプリケーションを含む同じユーザー アカウントからドライブをマウントします。 PsExec などのツールを使用できます。
コマンドのユーザー名とパスワード パラメーターにストレージ アカウント名とキーを
net use渡します。コマンドを
cmdkey使用して資格情報を Credential Manager に追加します。 対話型ログインまたは を使用runasして、サービス アカウント コンテキストのコマンド ラインからこのアクションを実行します。cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>マップされたドライブ文字を使用せずに、共有を直接マップします。 一部のアプリケーションはドライブ文字に正しく再接続されない可能性があるため、完全な UNC パスを使用する方が信頼性が高い場合があります。
net use * \\storage-account-name.file.core.windows.net\share
次の手順に従うと、システム/ネットワーク サービス アカウントに対して net use を実行すると、次のエラー メッセージが表示されることがあります。"システム エラー 1312 が発生しました。 指定されたログオン セッションが存在しません。 既に終了している可能性があります。このエラーが表示される場合は、渡されるユーザー名に net use ドメイン情報 (例: ) が含まれていることを確認します [storage account name].file.core.windows.net。
[マイ コンピューター] または [この PC] にドライブ文字が含まれるフォルダーがありません
コマンドを使用 net use して管理者として Azure ファイル共有をマップすると、共有が見つからないように見えます。
原因
既定では、Windows エクスプローラーは管理者として実行されません。 管理コマンド プロンプトから実行 net use する場合は、ネットワーク ドライブを管理者としてマップします。 マップされたドライブはユーザー中心であるため、別のユーザー アカウントにマウントされている場合、ログインしているユーザー アカウントにはドライブが表示されません。
ソリューション
管理者以外のコマンド ラインから共有をマウントします。 または、 この TechNet トピック に従ってレジストリ値を EnableLinkedConnections 構成することもできます。
ストレージ アカウントにスラッシュが含まれている場合、Net use コマンドが失敗する
原因
コマンドは net use スラッシュ (/) をコマンド ライン オプションとして解釈します。 ユーザー アカウント名がスラッシュで始まる場合、ドライブのマッピングは失敗します。
ソリューション
次のいずれかの手順を使用して、問題を回避できます。
次の PowerShell コマンドを実行します。
New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"バッチ ファイルから、次のようにコマンドを実行できます。
Echo new-smbMapping ... | powershell -command –スラッシュが最初の文字でない限り、この問題を回避するには、キーの周りに二重引用符を付けます。 その場合は、対話型モードを使用してパスワードを個別に入力するか、キーを再生成してスラッシュで始まらないキーを取得します。
New-PSDrive コマンドが "ネットワーク リソースの種類が正しくない" エラーで失敗する
原因
ファイル共有にアクセスできない場合、このエラー メッセージが表示されることがあります。 たとえば、 ポート 445 がブロックされているか 、DNS 解決の問題があります。
ソリューション
ポート 445 が開いていることを確認し、ファイル共有への DNS 解決と接続をチェックします。
Azure ファイル共有 (または共有スナップショット) にアクセス、変更、または削除できない
ユーザーが開始したフェールオーバー後の "ユーザー名またはパスワードが正しくありません" エラー
geo 冗長ストレージ アカウントを使用した顧客が開始したフェールオーバー シナリオでは、ファイル ハンドルとリースはフェールオーバー時に保持されません。 クライアントは、ファイル共有のマウントを解除して再マウントする必要があります。
Azure ファイル共有にアクセスまたは削除しようとすると、エラー "アクセスなし"
Azure portalを使用して Azure ファイル共有にアクセスまたは削除しようとすると、次のエラーが表示される場合があります。
アクセスなし エラー コード: 403
原因 1: 仮想ネットワークまたはファイアウォール規則がストレージ アカウントで有効になっている
原因 1 の解決策
仮想ネットワークとファイアウォールの規則がストレージ アカウントで正しく構成されていることを確認します。 仮想ネットワークまたはファイアウォール規則によって問題が発生しているかどうかをテストするには、ストレージ アカウントの設定を一時的に [ すべてのネットワークからのアクセスを許可する] に変更します。 詳細については、「 Azure Storage ファイアウォールと仮想ネットワークの構成」を参照してください。
原因 2: ユーザー アカウントがストレージ アカウントにアクセスできない
原因 2 の解決策
Azure ファイル共有が配置されているストレージ アカウントを参照し、[ アクセス制御 (IAM)] を選択し、ユーザー アカウントがストレージ アカウントへのアクセス権を持っていることを確認します。 詳細については、「 Azure ロールベースのアクセス制御 (Azure RBAC) を使用してストレージ アカウントをセキュリティで保護する方法」を参照してください。
ファイル ロックとリース
Azure ファイル共有またはスナップショットを変更または削除できない場合は、ファイルロックまたはリースが原因である可能性があります。 Azure Filesには、Azure ファイル共有と共有スナップショットの誤った変更または削除を防ぐ 2 つの方法が用意されています。
ストレージ アカウントのリソース ロック: ストレージ アカウントを含むすべての Azure リソースは、 リソース ロックをサポートします。 ロックは、管理者またはAzure Backupなどのサービスによってストレージ アカウントに配置される場合があります。 リソース ロックには、ストレージ アカウントとそのリソースに対するすべての変更を防ぐ modify と、ストレージ アカウントとそのリソースの削除のみを防止する 削除という 2 つのバリエーションがあります。 リソース プロバイダーを使用して
Microsoft.Storage共有を変更または削除すると、Azure ファイル共有と共有スナップショットにリソース ロックが適用されます。 ほとんどのポータル操作では、Azure PowerShellコマンド グループの名前 (など) と Azure CLI コマンドshare-rm(などaz storage share-rm listGet-AzRmStorageShare) でAzure FilesするためのRmコマンドレットがリソース プロバイダーをMicrosoft.Storage使用します。 Storage Explorer、レガシ Azure Files PowerShell 管理コマンドレットなど、一部のツールとユーティリティでは、名前 (など) を指定せずRm、Get-AzStorageShareコマンド グループの下shareのレガシ Azure Files CLI コマンド (例: ) は、az storage share listリソース プロバイダーとリソース ロックをバイパスMicrosoft.Storageする FileREST API のレガシ API を使用します。 FileREST API で公開されているレガシ管理 API の詳細については、Azure Filesのコントロール プレーンに関するページを参照してください。共有/共有スナップショットリース: 共有リースは、Azure ファイル共有とファイル共有スナップショットの専用ロックの一種です。 リースは、スクリプトを介して API を呼び出すか、Azure Backupなどの付加価値サービスによって、管理者によって個々の Azure ファイル共有またはファイル共有スナップショットに配置される場合があります。 Azure ファイル共有またはファイル共有スナップショットにリースを設定すると、リース ID を使用してファイル共有/共有スナップショットを変更または削除できます。 管理者は、リース ID を必要とする変更操作の前にリースを解放することも、リース ID を必要としないリースを解除することもできます。 共有リースの詳細については、「 リース共有」を参照してください。
リソースのロックとリースは、ストレージ アカウント/Azure ファイル共有に対する意図された管理者操作に干渉する可能性があるため、リソースに手動で、またはAzure Backupなどの付加価値サービスによって自動的に配置されたリソース ロック/リースを削除したい場合があります。 次のスクリプトは、すべてのリソース ロックとリースを削除します。 と <storage-account> は、環境に適した値に置き換えてください<resource-group>。
次のスクリプトを実行する前に、 最新バージョン の Azure Storage PowerShell モジュールをインストールする必要があります。
重要
Azure Files リソースのリソース ロックと共有/共有スナップショットリースを受け取る付加価値サービスは、ロックとリースを定期的に再適用する場合があります。 付加価値サービスによってロックされたリソースを変更または削除すると、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 { }
}
ファイルまたはディレクトリを変更、移動/名前変更、または削除できません
Azure ファイル共有にアクセスするために使用しているクライアント オペレーティング システムに応じて、[Windows または Linux] タブを選択します。
Windows では、次のエラーが表示される場合があります。
孤立したファイル ハンドルまたはリース
ファイル共有の主な目的の 1 つは、複数のユーザーとアプリケーションが共有内のファイルとディレクトリを同時に操作できる点です。 この操作を支援するために、ファイル共有は、ファイルとディレクトリへのアクセスを仲介するいくつかの方法を提供します。
SMB 経由でマウントされた Azure ファイル共有からファイルを開くと、アプリケーション/オペレーティング システムはファイル ハンドルを要求します。これはファイルへの参照です。 特に、アプリケーションでは、ファイル ハンドルを要求するときにファイル共有モードを指定します。これは、Azure Filesによって適用されるファイルへのアクセスの排他性のレベルを指定します。
None: 排他的アクセス権を持っています。Read: ファイルを開いている間に他のユーザーがファイルを読み取ることがあります。Write: ファイルを開いている間に他のユーザーがファイルに書き込む場合があります。ReadWrite: モードとWrite共有モードの両方のRead組み合わせ。Delete: 開いている間に他のユーザーがファイルを削除することがあります。
ステートレス プロトコルとして FileREST プロトコルにはファイル ハンドルの概念はありませんが、スクリプト、アプリケーション、またはサービスで使用できるファイルやフォルダーへのアクセスを仲介するための同様のメカニズムが提供されます。 ファイルがリースされると、ファイル共有モード Noneが のファイル ハンドルと同等として扱われます。
ファイル ハンドルとリースは重要な目的を果たしますが、ファイル ハンドルとリースが孤立することがあります。 この場合、ファイルの変更または削除に問題が発生する可能性があります。 次のようなエラー メッセージが表示される場合があります。
- ファイルが別のプロセスによって使用されているため、プロセスはファイルにアクセスできません。
- ファイルが別のプログラムで開かれているため、アクションを完了できません。
- ドキュメントは、別のユーザーが編集するためにロックされています。
- 指定されたリソースは、SMB クライアントによって削除対象としてマークされます。
この問題の解決策は、これが孤立したファイル ハンドルまたはリースによって引き起こされているかどうかによって異なります。
注:
REST リースは、ファイルが削除または変更されるのを防ぐために、アプリケーションによって使用されます。 リースを解除する前に、どのアプリケーションがリースを取得するかを特定する必要があります。 そうしないと、アプリケーションの動作が中断される可能性があります。
原因 1
ファイル ハンドルは、ファイル/ディレクトリの変更または削除を妨げている。 Get-AzStorageFileHandle PowerShell コマンドレットを使用して、開いているハンドルを表示できます。
すべての SMB クライアントがファイル/ディレクトリで開いているハンドルを閉じ、問題が引き続き発生する場合は、ファイル ハンドルを強制的に閉じることができます。
解決策 1
ファイル ハンドルを強制的に閉じるには、 Close-AzStorageFileHandle PowerShell コマンドレットを使用します。
注:
Get-AzStorageFileHandleコマンドレットと Close-AzStorageFileHandle コマンドレットは、Az PowerShell モジュール バージョン 2.4 以降に含まれています。 最新の Az PowerShell モジュールをインストールするには、「Azure PowerShell モジュールをインストールする」を参照してください。
原因 2
ファイル リースによって、ファイルが変更または削除されるのを防ぐことができます。 次の PowerShell コマンドを使用して、ファイルにファイル リースがあるかどうかをチェックできます。 、<storage-account>、<file-share>および <path-to-file> を環境に適した値に置き換えます<resource-group>。
# 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
ファイルにリースがある場合、返されるオブジェクトには次のプロパティが含まれている必要があります。
LeaseDuration : Infinite
LeaseState : Leased
LeaseStatus : Locked
解決策 2
ファイルからリースを削除するには、リースを解放するか、リースを解除します。 リースを解放するには、リースの LeaseId が必要です。リースの作成時に設定します。 リースを解除するために LeaseId は必要ありません。
次の例は、原因 2 で示されているファイルのリースを解除する方法を示しています (この例では、原因 2 から PowerShell 変数を引き続き使用します)。
$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null
Linux で Azure ファイル共有スナップショットをマウントできない
Linux で Azure ファイル共有スナップショットをマウントしようとすると、"マウント エラー(22): 引数が無効です"
原因
コマンドの snapshot オプションが mount 認識された形式で渡されない場合、 mount コマンドはこのエラーで失敗する可能性があります。 これを確認するために、カーネル ログ メッセージ (dmesg) をチェックすると、dmesg などのcifs: Bad value for 'snapshot'ログ エントリが表示されます。
ソリューション
コマンドのオプションmountをsnapshot正しい形式で渡していることを確認します。 mount.cifs のマニュアル ページ (例: ) を参照してください。 man mount.cifs 一般的なエラーは、ピリオドの代わりにハイフンやコロンを使用するなど、間違った形式で GMT タイムスタンプを渡すことです。 詳細については、「ファイル共有スナップショットのマウント」を参照してください。
Linux 上で Azure ファイル共有スナップショットをマウントしようとすると、"スナップショット トークンが正しくありません"
原因
で始まる @GMTスナップショット mount オプションを渡しても、形式が間違っている場合 (ピリオドではなくハイフンやコロンを使用するなど)mount、コマンドはこのエラーで失敗する可能性があります。
ソリューション
GMT タイムスタンプを正しい形式 @GMT-year.month.day-hour.minutes.seconds() で渡していることを確認します。 詳細については、「ファイル共有スナップショットのマウント」を参照してください。
Azure ファイル共有をマウントしようとすると"マウント エラー(2): そのようなファイルまたはディレクトリがありません"スナップショット
原因
マウントしようとしているスナップショットが存在しない場合、mountコマンドはこのエラーで失敗する可能性があります。 これを確認するために、カーネル ログ メッセージ (dmesg) をチェックすると、dmesg に次のようなログ エントリが表示されます。
[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
ソリューション
マウントしようとしているスナップショットが存在することを確認します。 特定の Azure ファイル共有で使用可能なスナップショットを一覧表示する方法の詳細については、「ファイル共有スナップショットのマウント」を参照してください。
開いているハンドルが多すぎるディスク クォータまたはネットワーク エラー
Azure ファイル共有にアクセスするために使用しているクライアント オペレーティング システムに応じて、[Windows または Linux] タブを選択します。
エラー 1816 - このコマンドを処理するのに十分なクォータがありません
原因
エラー 1816 は、Azure ファイル共有上のファイルまたはディレクトリで許可される同時オープン ハンドルの上限に達したときに発生します。 詳細については、「スケール ターゲットのAzure Files」を参照してください。
ソリューション
一部のハンドルを閉じて同時に開いているハンドルの数を減らし、再試行します。 詳細については、「パフォーマンスとスケーラビリティのチェックリストMicrosoft Azure Storage」を参照してください。
ファイル共有、ディレクトリ、またはファイルの開いているハンドルを表示するには、 Get-AzStorageFileHandle PowerShell コマンドレットを使用します。
ファイル共有、ディレクトリ、またはファイルの開いているハンドルを閉じるには、 Close-AzStorageFileHandle PowerShell コマンドレットを使用します。
注:
Get-AzStorageFileHandleコマンドレットと Close-AzStorageFileHandle コマンドレットは、Az PowerShell モジュール バージョン 2.4 以降に含まれています。 最新の Az PowerShell モジュールをインストールするには、「Azure PowerShell モジュールをインストールする」を参照してください。
ハンドルに対して操作を実行する場合のERROR_UNEXP_NET_ERR (59)
原因
多数の開いているハンドルを長期間キャッシュまたは保持すると、調整の理由により、このサーバー側のエラーが発生する可能性があります。 クライアントによって多数のハンドルがキャッシュされると、それらのハンドルの多くが同時に再接続フェーズに入り、調整する必要があるサーバー上にキューを構築できます。 再接続の再試行ロジックとバックエンドでの調整には、クライアントのタイムアウトより長い時間がかかります。 この状況は、クライアントが既存のハンドルを操作に使用できず、すべての操作がERROR_UNEXP_NET_ERR (59) で失敗した状態で現れます。
また、クライアント ハンドルがサーバーから切断されるエッジ ケースもあります (たとえば、数分間続くネットワークの停止)。
ソリューション
大量のハンドルをキャッシュに保持しないでください。 ハンドルを閉じ、再試行します。 開いているハンドルを表示または閉じるには、PowerShell コマンドレットと Close-AzStorageFileHandle PowerShell コマンドレットを使用Get-AzStorageFileHandleします。
Azure ファイル共有を使用して、大規模な仮想デスクトップデプロイのプロファイル コンテナーまたはディスク イメージ、またはファイル、ディレクトリ、またはルート ディレクトリでハンドルを開くその他のワークロードを格納する場合は、同時オープン ハンドルの 上限に 達する可能性があります。 この場合は、追加の Azure ファイル共有を使用し、共有間でコンテナーまたはイメージを配布します。
エラー "暗号化をサポートしていない宛先にファイルをコピーしています"
ファイルがネットワーク経由でコピーされると、ファイルはソース コンピューターで暗号化解除され、プレーンテキストで送信され、宛先で再暗号化されます。 ただし、暗号化されたファイルをコピーしようとすると、"暗号化をサポートしていない宛先にファイルをコピーしています" というエラーが表示される場合があります。
原因
この問題は、暗号化ファイル システム (EFS) を使用している場合に発生する可能性があります。 BitLocker で暗号化されたファイルは、Azure Filesにコピーできます。 ただし、Azure Filesは NTFS EFS をサポートしていません。
回避策
ネットワーク経由でファイルをコピーするには、最初に暗号化を解除する必要があります。 以下のいずれかの方法を実行します。
- copy /d コマンドを使用します。 これにより、暗号化されたファイルを宛先に暗号化解除されたファイルとして保存できます。
- 次のレジストリ キーを設定します。
- パス = HKLM\Software\Policies\Microsoft\Windows\System
- 値の種類 = DWORD
- Name = CopyFileAllowDecryptedRemoteDestination
- 値 = 1
レジストリ キーを設定すると、ネットワーク共有に対して行われるすべてのコピー操作に影響します。
ブラウザーからAzure Filesを使用して Web アプリケーションから Error ConditionHeadersNotSupported
ConditionHeadersNotSupported エラーは、Web ブラウザーなどの条件付きヘッダーを使用するアプリケーションを介してAzure Filesでホストされているコンテンツにアクセスできない場合に発生します。 エラーは、条件ヘッダーがサポートされていないことを示します。
原因
条件付きヘッダーはまだサポートされていません。 それらを実装するアプリケーションは、ファイルにアクセスするたびに完全なファイルを要求する必要があります。
回避策
新しいファイルがアップロードされると、既定では CacheControl プロパティは キャッシュなしになります。 アプリケーションが毎回ファイルを要求するには、ファイルの CacheControl プロパティをキャッシュなしからキャッシュなし、ストアなし、再検証が必要に応じて更新する必要があります。 これは、Azure Storage Explorerを使用して実現できます。
関連項目
- Azure Filesのトラブルシューティング
- Azure Filesパフォーマンスのトラブルシューティング
- Azure Files認証と承認 (SMB) のトラブルシューティング
- Linux Azure Files一般的な SMB の問題のトラブルシューティング
- Linux Azure Files一般的な NFS の問題のトラブルシューティング
- Azure File Syncの問題のトラブルシューティング
お問い合わせはこちらから
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示