Azure Files の接続とアクセスの問題のトラブルシューティング (SMB)

Windows で Azure ファイル共有に接続しようとすると、次のエラーメッセージが表示されることがあります。

Azure ファイル共有をマウントするときに、エラー 5 が発生する

• システム エラー 5 が発生しました。 アクセスが拒否されました。

原因 1:通信チャネルが暗号化されていない

通信チャネルが暗号化されていない場合や、接続の試行が Azure ファイル共有が存在するのと同じデータセンターから行われていない場合、セキュリティ上、Azure ファイル共有への接続がブロックされます。 ストレージ アカウントで [安全な転送が必須] 設定が有効になっている場合は、同じデータセンター内の暗号化されていない接続もブロックされす。 エンドユーザーのクライアント OS が SMB 暗号化をサポートしている場合、暗号化された通信チャネルのみを利用できます。

各システムの Windows 8、Windows Server 2012、およびそれ以降のバージョンでは、SMB 3. を含む要求をネゴシエートします。x。暗号化をサポートします。

原因 1 の解決策

1. SMB 暗号化をサポートするクライアント (Windows 8/Windows Server 2012 以降) から接続します。
2. 同じデータセンター内の仮想マシン (VM) から、Azure ファイル共有に使用される Azure ストレージ アカウントとして接続します。
3. クライアントが SMB 暗号化をサポートしていない場合、ストレージ アカウントで [安全な転送が必須] 設定が無効になっていることを確認します。

原因 2:ストレージ アカウントに対して仮想ネットワークまたはファイアウォール ルールが有効になっている

仮想ネットワーク（VNET）およびファイアウォールルールがストレージアカウントに設定されている場合、クライアントのIPアドレスまたは仮想ネットワークを許可しない限り、ネットワークトラフィックが拒否されます。

原因 2 の解決策

ストレージ アカウントに対して仮想ネットワークまたはファイアウォール ルールが適切に構成されていることを確認します。 仮想ネットワークまたはファイアウォールルールが問題の原因かどうかをテストするには、ストレージアカウントの設定を一時的に「すべてのネットワークからのアクセスを許可する」に変更します。 詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。

原因 3: ID ベースの認証を使用するとき、共有レベルのアクセス許可が正しくない

ユーザーが Active Directory (AD) または Microsoft Entra Domain Services 認証を使用して Azure ファイル共有にアクセスしているとき、共有レベルのアクセス許可が正しくないと、ファイル共有にアクセスできず、"アクセスが拒否されました" エラーが表示されます。

原因 3 の解決策

アクセス許可が正しく構成されていることを確認します。

• Active Directory Domain Services (AD DS): 「共有レベルのアクセス許可を割り当てる」を参照してください。

  共有レベルのアクセス許可の割り当ては、Microsoft Entra Connect Sync または Microsoft Entra Connect クラウド同期を使用して AD DS から Microsoft Entra ID に同期されたグループとユーザーでサポートされています。共有レベルのアクセス許可が割り当てられているグループとユーザーが、サポートされていない "クラウド専用" グループでないことを確認します。

• Microsoft Entra Domain Services については、「Assign share-level permissions (共有レベルのアクセス許可の割り当て)」を参照してください。

Azure ファイル共有をマウントまたはマウント解除するときに、エラー 53、エラー 67、またはエラー 87 が発生する

オンプレミスまたは別のデータセンターからファイル共有をマウントしようとすると、次のエラーが発生する可能性があります。

• システム エラー 53 が発生しました。 ネットワーク パスが見つかりませんでした。
• システム エラー 67 が発生しました。 ネットワーク名が見つかりません。
• システム エラー 87 が発生しました。 パラメーターが正しくありません。

原因 1:ポート 445 がブロックされている

Azureファイルデータセンターへのポート445発信通信がブロックされている場合は、システムエラー53またはシステムエラー67が発生することがあります。 ポート 445 からのアクセスを許可する ISP または許可しない 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

原因 1 の解決策

解決策 1 — QUIC エンドポイントとして Azure File Sync を使用する ポート 445 がブロックされているクライアントから Azure Files にアクセスするための回避策として、Azure File Sync を使用できます。 Azure Files は SMB over QUIC を直接サポートしていませんが、Windows Server 2022 Azure Edition では QUIC プロトコルがサポートされています。 Azure File Sync を使用して、Windows Server 2022 Azure Edition VM に Azure ファイル共有の軽量キャッシュを作成できます。この構成では、ポート 445 ではなく、HTTPS をサポートするためにアウトバウンドで広く開かれているポート 443 を使用します。 このオプションの詳細については、Azure File Sync を使用した SMB over QUIC に関するページを参照してください。

ソリューション 2 - VPN または ExpressRoute を使用する オンプレミスから Azure ストレージ アカウントに仮想プライベート ネットワーク (VPN) または ExpressRoute を設定し、プライベート エンドポイントを使用して内部ネットワーク上に Azure Files を公開すると、トラフィックはインターネット経由ではなくセキュリティで保護されたトンネルを経由します。 に従って VPN をセットアップしWindows から Azure Files にアクセスします。

解決策 3 — ISP/IT 管理者の助けを借りてポート 445 のブロックを解除する IT 部門または ISP と連携して、ポート 445 の送信方向の通信を Azure の IP 範囲に解放します。

ソリューション 4 - Storage Explorer や PowerShell などの REST API ベースのツールを使用する Azure Files では SMB に加えて REST もサポートされます。 REST アクセスは、ポート 443 (標準の tcp) 上で動作します。 REST API を使用して作成された、豊富な UI エクスペリエンスを可能にするさまざまなツールがあります。 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

エラー コード 0x800704b3で失敗しました

Azure ファイル共有をマウントしようとすると、次のエラーが表示されます。

エラー コード: 0x800704b3
シンボリック名: ERROR_NO_NET_OR_BAD_PATH
エラーの説明: ネットワーク パスが正しく入力されていないか、存在しないか、ネットワーク プロバイダーが現在使用できません。 パスを再入力するか、ネットワーク管理者に問い合わせてください。

原因

このエラーは、これらのネットワーク サービスに明示的に依存するすべてのサービスが起動に失敗するため、主要な Windows ネットワーク関連サービスが無効になっている場合に発生する可能性があります。

ソリューション

次のいずれかのサービスが Windows VM で Stopped 状態になっているかどうかを確認します。

• ネットワーク接続
• Network List Service
• Network Location Awareness
• Network Store Interface Service
• DHCP クライアント
• TCP/IP NetBIOS ヘルパー
• ワークステーション

見つかる場合は、サービスを開始し、Azure ファイル共有のマウントを再試行します。

アプリケーションまたはサービスがマウントされた Azure Files ドライブにアクセスできない

原因

ドライブは、ユーザーごとにマウントされます。 アプリケーションまたはサービスが、ドライブをマウントしたユーザー アカウントとは別のユーザー アカウントで実行されている場合、アプリケーションがドライブを認識しません。

解決策

次のいずれかのソリューションを使用します。

• アプリケーションが属しているのと同じユーザー アカウントからドライブをマウントします。 PsExec などのツールを使用することができます。

• net use コマンドのユーザー名とパスワードのパラメーターで、ストレージ アカウント名とキーを渡します。

• cmdkey コマンドを使って、資格情報を資格情報マネージャーに追加します。 対話型ログインまたは 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 ファイル共有をマップすると、共有が存在しないように見えます。

原因

既定では、エクスプローラーは管理者として実行されません。 管理コマンド プロンプトから 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 コマンドが "ネットワーク リソースの種類が正しくありません" エラーで失敗する

原因

ファイル共有にアクセスできない場合、このエラー メッセージが表示されることがあります。 たとえば、 port 445 がブロックされている または DNS 解決の問題があります。

ソリューション

ポート 445 が開いていることを確認し、ファイル共有への DNS 解決と接続 確認します。

この問題の一般的な原因は次のとおりです。

• お使いの Linux ディストリビューションの SMB クライアントが最新ではありません。 クライアントに互換性があって、なおかつ Azure で利用できる一般的な Linux ディストリビューションについては、Linux での Azure Files の使用に関するページを参照してください。
• クライアントに SMB ユーティリティ (cifs-utils) がインストールされていません。
• SMB の最小バージョン 2.1 がクライアントで利用できません。
• SMB 3.x 暗号化がクライアントでサポートされていません。 上記の表では、暗号化を使用してオンプレミスや複数のリージョンにまたがるマウントをサポートする Linux ディストリビューションの一覧を示しています。 他のディストリビューションの場合は、カーネル 4.11 以降のバージョンが必要です。
• Azure VM から Azure ファイル共有に接続しようとしていますが、VM はストレージ アカウントと同じリージョンにありません。
• [安全な転送が必須] 設定がストレージ アカウントで有効になっている場合、Azure Files は暗号化付き SMB 3.x を使った接続のみを許可します。

解決策

この問題を解決するには、「Troubleshooting tool for Azure Files mounting errors on Linux (Linux での Azure Files のマウント エラー用トラブルシューティング ツール)」を使用します。 このツールには、以下の機能があります。

• クライアントの実行環境の検証を支援します。
• Azure Files へのアクセス エラーの原因となる、互換性のないクライアント構成を検出します。
• 自己修正に関する規範的なガイダンスを提供します。
• 診断トレースを収集します。

Azure ファイル共有をマウントしようとしたときに、"マウント エラー (13): アクセス許可が拒否されました" というエラーが発生する

原因 1:通信チャネルが暗号化されていない

セキュリティ上の理由から、通信チャネルが暗号化されておらず、Azure ファイル共有が存在するのと同じデータセンターから接続が試行されない場合、Azure ファイル共有への接続はブロックされます。 ストレージ アカウントで [安全な転送が必須] 設定が有効になっている場合は、同じデータセンター内の暗号化されていない接続もブロックされる可能性があります。 暗号化された通信チャネルは、ユーザーのクライアント OS が SMB 暗号化をサポートしている場合にのみ提供されます。

詳しくは、「Linux で cifs-utils パッケージを使用してAzure ファイル共有をマウントするための前提条件」をご覧ください。

原因 1 の解決策

1. SMB 暗号化をサポートするクライアントから接続するか、Azure ファイル共有に使用される Azure ストレージ アカウントと同じデータセンター内の仮想マシンから接続します。
2. クライアントが SMB 暗号化をサポートしていない場合、ストレージ アカウントで [安全な転送が必須] 設定が無効になっていることを確認します。

原因 2:ストレージ アカウントに対して仮想ネットワークまたはファイアウォール ルールが有効になっている

仮想ネットワーク (VNET) またはファイアウォール ルールがストレージ アカウントに構成されている場合、クライアント IP アドレスまたは仮想ネットワークがアクセスを許可されていない限り、ネットワーク トラフィックは拒否されます。

原因 2 の解決策

VNET とファイアウォール規則がストレージ アカウントで正しく構成され、ポート 445 が許可リストに登録されていることを確認します。 仮想ネットワークまたはファイアウォール規則によって問題が発生するかどうかをテストするには、ストレージ アカウントの設定を一時的に変更して、すべてのネットワークからのアクセスを できます。 詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。

原因 3: SMB クライアントが NTLMv1 を使用するように構成されている

Azure Files では、SMB ファイル共有に対して NTLMv2 と Kerberos のみがサポートされます。 カーネル 4.4 以降のバージョンでは、NTLMv2 が既定で有効になり、LANMAN が無効になります。 既定の構成では、NTLMv1 はネゴシエーションのみのオプションとして保持されます。 詳細については、OS のドキュメントを参照してください。

原因 3 の解決策

オプションを使用して、SMB マウント コマンドによって既定の NTLMv2 認証がオーバーライドされないようにします。 sec オプションは、SMB Azure ファイル共有に接続するときにntlmやntlmiを使用しないでください。 /etc/samba/smb.conf でグローバル オプションを設定する場合は、NTLMv2 を無効にしないでください。

原因 4: ポリシーを使用してストレージ アカウント キーのアクセスが無効または禁止されている

ストレージ アカウントに対してストレージ アカウント キーのアクセスが無効または禁止されている場合、SAS トークンとアクセス キーは機能しません。

原因 4 の解決策

ID ベースの認証を使用します。 ファイル共有は、オンプレミスの Active Directory Domain Servies (AD DS) または Microsoft Entra Domain Services ドメインに参加している必要があり、Kerberos 認証を使用するには Linux クライアントを構成する必要があります。

SMB 3.x を使用して Azure Files をマウントするときの "マウント エラー (115): 操作は現在実行中です"

原因

一部の Linux ディストリビューションは、SMB 3.x の暗号化機能を現時点ではサポートしていません。 ユーザーが SMB 3.x を使用して Azure Files をマウントしようとしたときに、機能が見つからないために "115" エラー メッセージが表示される場合があります。 完全暗号化を使用する SMB 3.x は、Linux ディストリビューションの最新バージョンでのみサポートされます。

解決策

Linux 用の SMB 3.x の暗号化機能は 4.11 カーネルで導入されました。 この機能により、オンプレミスまたは別の Azure リージョンから Azure ファイル共有をマウントできます。 Linux ディストリビューションによっては、4.11 カーネルから以前のバージョンの Linux カーネルへの移植変更が加えられている場合があります。 使用している Linux のバージョンが暗号化を使用した SMB 3.x をサポートしているかどうかを判断するには、Linux での Azure Files の使用に関するページを参照してください。

Linux SMB クライアントが暗号化をサポートしていない場合は、ファイル共有と同じ Azure データ センターにある Linux VM から SMB 2.1 を使用して Azure Files をマウントします。 ストレージ アカウントで [安全な転送が必須] 設定が無効になっていることを確認します。

再接続タイムアウトによる"マウント エラー (112): ホストがダウンしています"

"112" マウント エラーは、Linux クライアント上で、クライアントが長時間アイドル状態になった場合に発生します。 長時間アイドル時間が経過すると、クライアントが切断され、接続がタイムアウトします。

原因

接続は、以下の理由でアイドル状態になることがあります。

• 既定の "ソフト" マウント オプションが使用されている場合に、サーバーへの TCP 接続を再確立できないネットワーク通信エラー。
• 古いカーネルに存在しない最近の再接続の修正。

ソリューション

Linux カーネルの再接続に関するこの問題は、以下の変更の一環として修正されました。

• ソケットの再接続後、smb3 セッションの再接続を長時間保留しないようにする修正
• ソケットの再接続後すぐにエコー サービスを呼び出す
• CIFS:再接続中にメモリが破損する可能性がある問題の修正
• CIFS:再接続中にミューテックスのダブル ロックが発生する可能性がある問題の修正 (カーネル v4.9 以降)

ただし、これらの変更は、すべての Linux ディストリビューションにまだ移植されていない可能性があります。 一般的な Linux ディストリビューションを使用している場合は、「 Azure Files と Linux を使用する で、必要なカーネルの変更があるディストリビューションのバージョンを確認できます。

回避策

ハード マウントを指定することによって、この問題を回避することができます。 ハード マウントでは、接続が確立されるか、明示的に中断されるまで、クライアントが強制的に待機させられます。 この機能を使用することで、ネットワーク タイムアウトによるエラーを防ぐことができます。 ただし、この回避策では、待機が無期限に続く可能性があります。 必要に応じて、接続を停止できるように準備しておいてください。

最新バージョンのカーネルにアップグレードできない場合は、Azure ファイル共有にファイルを保持し、30 秒以下の間隔で書き込みを実行することによって、この問題を回避できます。 これは、ファイルの作成日/変更日が書き換えられるような書き込み操作である必要があります。 そうでない場合、キャッシュされた結果が取得され、操作によって再接続がトリガーされない可能性があります。

Windows で、次のエラーが表示されることがあります。

孤立したファイル ハンドルまたはリース

ファイル共有の主な目的の 1 つは、複数のユーザーおよびアプリケーションが、共有内のファイルとディレクトリを同時に操作できることです。 このようなやり取りを支援するために、ファイル共有は、ファイルとディレクトリへのアクセスを複数の方法で提供します。

SMB 経由でマウントされた Azure ファイル共有からファイルを開くと、アプリケーションまたはオペレーティング システムは、ファイルを参照するファイル ハンドルを要求します。 特に、アプリケーションはファイル ハンドルを要求するときにファイル共有モードを指定します。このモードでは、Azure Files によって適用されるファイルへのアクセスの排他性のレベルを指定します。

• None: 排他アクセスがあります。
• Read: ファイルを開いている間、他のユーザーはそのファイルを読み取ることができます。
• Write: ファイルを開いている間、他のユーザーはそのファイルに書き込むことができます。
• ReadWrite: Read と Write の両方の共有モードの組み合わせです。
• Delete: ファイルを開いている間、他のユーザーはそのファイルを削除できます。

FileREST プロトコルはステートレス プロトコルであるため、ファイル ハンドルの概念はありませんが、類似のメカニズムとして、スクリプト、アプリケーション、またはサービスが使用できるファイルやフォルダーへのアクセスを仲介するためのファイル リースが用意されています。 リースされたファイルは、ファイル共有モードが None のファイル ハンドルと同じように扱われます。

ファイル ハンドルとリースは重要な目的がありますが、ファイル ハンドルやリースが孤立する場合もあります。 この場合、ファイルの変更または削除時に問題が発生することがあります。 次のようなエラー メッセージが表示される場合があります。

• ファイルが別のプロセスによって使用されているため、プロセスはファイルにアクセスできません。
• ファイルを別のプログラムで開いているため、アクションを完了できません。
• ドキュメントは、別のユーザーが編集するためにロックされています。
• 指定されたリソースは SMB クライアントが削除対象に設定しています。

この問題の解決策は、問題が孤立したファイル ハンドルまたはリースによって発生しているかどうかによって異なります。

原因 1

ファイル ハンドルが原因で、ファイルまたはディレクトリの変更または削除が妨げられています。 Get-AzStorageFileHandle PowerShell コマンドレットを使用して、開いているハンドルを表示できます。

すべての SMB クライアントがファイルまたはディレクトリの開いているハンドルを閉じていても、問題が引き続き発生する場合は、ファイル ハンドルを強制的に閉じることができます。

解決策 1

ファイル ハンドルを強制的に閉じるには、Close-AzStorageFileHandle PowerShell コマンドレットを使用します。

原因 2

ファイルのリースのために、ファイルを変更または削除できません。 ファイルにファイル リースがあるかどうかを確認するには、次の PowerShell コマンドを使用します。 <resource-group>、<storage-account>、<file-share>、<path-to-file> を実際の環境の適切な値に置き換えます。

# 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 では、次の問題が発生する場合があります。

ファイルまたはディレクトリのハンドルを開く

原因

この問題は、通常、ファイルまたはディレクトリのハンドルが開いている場合に発生します。

解決策

開いているすべてのハンドルを SMB クライアントで閉じた後も問題が引き続き発生する場合は、次の手順を行います。

• Get-AzStorageFileHandle PowerShell コマンドレットを使用して、開いているハンドルを表示します。

• Close-AzStorageFileHandle PowerShell コマンドレットを使用して、開いているハンドルを閉じます。

エラー 1816 - このコマンドを実行するのに十分なクォータがありません

原因

エラー 1816 は、Azure ファイル共有上のファイルまたはディレクトリに対して許可されている、同時に開くことのできるハンドルの上限に達したときに発生します。 詳細については、「Azure Files のスケール ターゲット」をご覧ください。

解決策

ハンドルをいくつか閉じて、同時に開いているハンドルの数を減らしてから、再試行します。 詳細については、「Microsoft Azure Storage のパフォーマンスとスケーラビリティに対するチェック リスト」を参照してください。

ファイル共有、ディレクトリ、またはファイルの開いているハンドルを表示するには、Get-AzStorageFileHandle PowerShell コマンドレットを使用します。

ファイル共有、ディレクトリ、またはファイルの開いているハンドルを閉じるには、Close-AzStorageFileHandle PowerShell コマンドレットを使用します。

ハンドルで何らかの操作を行うときの ERROR_UNEXP_NET_ERR (59)

原因

多数の開いているハンドルを長時間キャッシュまたは保持すると、調整のために、このサーバー側エラーが発生する可能性があります。 多数のハンドルがクライアントによってキャッシュされると、それらのハンドルの多くが同時に再接続フェーズに入り、調整を必要とするキューがサーバー上に作成される可能性があります。 バックエンドでの再接続のための再試行ロジックと調整に、クライアントのタイムアウトより長い時間がかかります。 このような状況により、クライアントがどの操作にも既存のハンドルを使用できなくなり、すべての操作が ERROR_UNEXP_NET_ERR (59) で失敗します。

また、クライアント ハンドルが (たとえば、数分間続くネットワーク停止で) サーバーから切断されたことが原因でこのエラーが発生する可能性のあるエッジ ケースもあります。

ソリューション

多数のハンドルをキャッシュしたままにしないでください。 ハンドルを閉じ、再試行します。 開いているハンドルを表示する/閉じるには、Get-AzStorageFileHandle および Close-AzStorageFileHandle PowerShell コマンドレットを使用します。

Azure ファイル共有を使用して、大規模な仮想デスクトップデプロイのプロファイル コンテナーまたはディスク イメージ、またはファイル、ディレクトリ、ルート ディレクトリでハンドルを開くその他のワークロードを格納している場合は、同時に開くハンドルのスケールの上限に達する可能性があります。 この場合は、追加の Azure ファイル共有を使用し、共有間でコンテナーまたはイメージを配布します。

ファイルを開こうとしたときの "[アクセス許可が拒否されました] ディスク クォータを超えました"

Linux では、次のようなエラー メッセージが表示される場合があります。

<filename> [アクセス許可が拒否されました] ディスク クォータを超えました

原因

ファイルまたはディレクトリで許容される、同時に開くことのできるハンドルの上限に達しました。

Azure Files では、ルート ディレクトリで 10,000 個のオープン ハンドルが、共有内のファイルとディレクトリごとに 2,000 個のオープン ハンドルがサポートされます。

ソリューション

一部のハンドルを閉じてから操作を再試行して、同時に開いているハンドルの数を減らします。

ファイル共有、ディレクトリ、またはファイルの開いているハンドルを表示するには、Get-AzStorageFileHandle PowerShell コマンドレットを使用します。

ファイル共有、ディレクトリ、またはファイルの開いているハンドルを閉じるには、Close-AzStorageFileHandle PowerShell コマンドレットを使用します。