このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
この記事では、Windows または Linux クライアントからサーバー メッセージ ブロック (SMB) Azure ファイル共有に接続してアクセスしようとしたときに発生する可能性がある一般的な問題の一覧を示します。 これらの問題の考えられる原因と解決策についても説明します。
注意
この記事は役に立ちましたか? あなたの入力は私たちにとって重要です。 このページの Feedback ボタンを使用して、この記事がどれだけうまく機能したか、または改善方法をお知らせください。
重要
この記事は、SMB 共有にのみ適用されます。 ネットワーク ファイル システム (NFS) 共有の詳細については、「 Azure NFS ファイル共有をトラブルシューティングする」を参照してください。
| ファイル共有の種類 | SMB | NFS |
|---|---|---|
| Standard ファイル共有 (GPv2)、LRS/ZRS | 
|
|
| Standard ファイル共有 (GPv2)、GRS/GZRS |
|
|
| Premium ファイル共有 (FileStorage)、LRS/ZRS |
|
|
Azure ファイル共有へのアクセスに使用しているクライアント オペレーティング システムに応じて、Windows または Linux タブを選択します。
この問題の一般的な原因は次のとおりです。
この問題を解決するには、「Troubleshooting tool for Azure Files mounting errors on Linux (Linux での Azure Files のマウント エラー用トラブルシューティング ツール)」を使用します。 このツールには、以下の機能があります。
セキュリティ上の理由から、通信チャネルが暗号化されておらず、Azure ファイル共有が存在するのと同じデータセンターから接続が試行されない場合、Azure ファイル共有への接続はブロックされます。 ストレージ アカウントで [安全な転送が必須] 設定が有効になっている場合は、同じデータセンター内の暗号化されていない接続もブロックされる可能性があります。 暗号化された通信チャネルは、ユーザーのクライアント OS が SMB 暗号化をサポートしている場合にのみ提供されます。
詳しくは、「Linux で cifs-utils パッケージを使用してAzure ファイル共有をマウントするための前提条件」をご覧ください。
仮想ネットワーク (VNET) またはファイアウォール ルールがストレージ アカウントに構成されている場合、クライアント IP アドレスまたは仮想ネットワークがアクセスを許可されていない限り、ネットワーク トラフィックは拒否されます。
VNET とファイアウォール規則がストレージ アカウントで正しく構成され、ポート 445 が許可リストに登録されていることを確認します。 仮想ネットワークまたはファイアウォール規則によって問題が発生するかどうかをテストするには、ストレージ アカウントの設定を一時的に変更して、すべてのネットワークからのアクセスを できます。 詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。
Azure Files では、SMB ファイル共有に対して NTLMv2 と Kerberos のみがサポートされます。 カーネル 4.4 以降のバージョンでは、NTLMv2 が既定で有効になり、LANMAN が無効になります。 既定の構成では、NTLMv1 はネゴシエーションのみのオプションとして保持されます。 詳細については、OS のドキュメントを参照してください。
sec オプションは、SMB Azure ファイル共有に接続するときにntlmやntlmiを使用しないでください。 /etc/samba/smb.conf でグローバル オプションを設定する場合は、NTLMv2 を無効にしないでください。
ストレージ アカウントに対してストレージ アカウント キーのアクセスが無効または禁止されている場合、SAS トークンとアクセス キーは機能しません。
ID ベースの認証を使用します。 ファイル共有は、オンプレミスの Active Directory Domain Servies (AD DS) または Microsoft Entra Domain Services ドメインに参加している必要があり、Kerberos 認証を使用するには Linux クライアントを構成する必要があります。
一部の 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" マウント エラーは、Linux クライアント上で、クライアントが長時間アイドル状態になった場合に発生します。 長時間アイドル時間が経過すると、クライアントが切断され、接続がタイムアウトします。
接続は、以下の理由でアイドル状態になることがあります。
Linux カーネルの再接続に関するこの問題は、以下の変更の一環として修正されました。
ただし、これらの変更は、すべての Linux ディストリビューションにまだ移植されていない可能性があります。 一般的な Linux ディストリビューションを使用している場合は、「 Azure Files と Linux を使用する で、必要なカーネルの変更があるディストリビューションのバージョンを確認できます。
ハード マウントを指定することによって、この問題を回避することができます。 ハード マウントでは、接続が確立されるか、明示的に中断されるまで、クライアントが強制的に待機させられます。 この機能を使用することで、ネットワーク タイムアウトによるエラーを防ぐことができます。 ただし、この回避策では、待機が無期限に続く可能性があります。 必要に応じて、接続を停止できるように準備しておいてください。
最新バージョンのカーネルにアップグレードできない場合は、Azure ファイル共有にファイルを保持し、30 秒以下の間隔で書き込みを実行することによって、この問題を回避できます。 これは、ファイルの作成日/変更日が書き換えられるような書き込み操作である必要があります。 そうでない場合、キャッシュされた結果が取得され、操作によって再接続がトリガーされない可能性があります。
geo 冗長ストレージ アカウントを使用する顧客が開始したフェールオーバー シナリオでは、フェールオーバー時にファイル ハンドルとリースは保持されません。 クライアントは、ファイル共有のマウントを解除して再マウントする必要があります。
Azure portal を使用して Azure ファイル共有にアクセスするか、Azure ファイル共有を削除しようとしたときに、以下のエラーが発生する場合があります。
"アクセス権なし" エラー コード: 403
ストレージ アカウントに対して仮想ネットワークまたはファイアウォール ルールが適切に構成されていることを確認します。 仮想ネットワークまたはファイアウォール ルールが問題の原因となっているかどうかをテストするには、ストレージ アカウントの設定を一時的に [すべてのネットワークからのアクセスを許可する] に変更する必要があります。 詳細については、「Azure Storage ファイアウォールおよび仮想ネットワークを構成する」を参照してください。
Azure ファイル共有があるストレージ アカウントを参照し、 Access control (IAM)を選択し、ユーザー アカウントがストレージ アカウントにアクセス可能であることを確認します。 詳しくは、ロールベースのアクセス制御 (RBAC) を使用してストレージ アカウントをセキュリティで保護する方法に関するページをご覧ください。
Azure ファイル共有またはスナップショットを変更または削除できない場合、ファイル ロックまたはリースが原因である可能性があります。 Azure Files には、Azure ファイル共有と共有スナップショットが誤って変更または削除されないようにする 2 つの方法があります。
ストレージ アカウントのリソース ロック: ストレージ アカウントを含むすべての Azure リソースでは、[リソース ロック] をサポートしています。 ロックは、管理者または Azure Backup などのサービスによってストレージ アカウントに配置される場合があります。 リソース ロックには、ストレージ アカウントとそのリソースに対するすべての変更を防ぐ modify と、ストレージ アカウントとそのリソースの削除のみを防止する delete という 2 つのバリエーションがあります。 Microsoft.Storage リソース プロバイダーを介して共有を変更または削除すると、Azure ファイル共有と共有スナップショットにリソース ロックが適用されます。 ほとんどのポータル操作、名前に Rm ( Get-AzRmStorageShareなど) が含まれる Azure Files 用の Azure PowerShell コマンドレット、 share-rm コマンド グループ内の Azure CLI コマンド ( az storage share-rm list など) では、 Microsoft.Storage リソース プロバイダーが使用されます。 Storage Explorer、名前に Rm しない従来の Azure Files PowerShell 管理コマンドレット ( 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 などの付加価値サービスによって手動または自動でリソースに設定されたリソースのロック/リースを削除することをお勧めします。 次のスクリプトでは、すべてのリソース ロックとリースを削除します。 忘れずに、<resource-group> および <storage-account> を実際の環境の適切な値に置き換えてください。
次のスクリプトを実行する前に、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] タブを選択します。
Linux では、次の問題が発生する場合があります。
この問題は、通常、ファイルまたはディレクトリのハンドルが開いている場合に発生します。
開いているすべてのハンドルを SMB クライアントで閉じた後も問題が引き続き発生する場合は、次の手順を行います。
Get-AzStorageFileHandle PowerShell コマンドレットを使用して、開いているハンドルを表示します。
Close-AzStorageFileHandle PowerShell コマンドレットを使用して、開いているハンドルを閉じます。
注意
Get-AzStorageFileHandle および Close-AzStorageFileHandle コマンドレットは、Az PowerShell モジュールのバージョン 2.4 以降に含まれます。 最新の Az PowerShell モジュールをインストールするには、「Install the Azure PowerShell module」(Azure PowerShell モジュールのインストール) を参照してください。
mount コマンドの snapshot オプションが認識される形式で渡されなかった場合、mount コマンドはこのエラーで失敗することがあります。 これを確認するには、カーネル ログ メッセージ (dmesg) を確認すると、dmesg に cifs: Bad value for 'snapshot' などのログ エントリが表示されます。
mount コマンドの snapshot オプションを正しい形式で渡していることを確認します。 mount.cifs のマニュアル ページを参照してください (例: man mount.cifs)。 よくあるエラーは、ピリオドではなくハイフンやコロンを使うなど、間違った形式で GMT タイムスタンプを渡すことです。 詳細については、ファイル共有のスナップショットのマウントに関する記事を参照してください。
@GMT で始まるスナップショットの mount オプションを渡し、形式は正しくない場合 (ピリオドではなくハイフンやコロンが使われているなど)、mount コマンドはこのエラーで失敗することがあります。
GMT タイムスタンプを正しい形式 ( @GMT-year.month.day-hour.minutes.seconds) で渡していることを確認します。 詳細については、ファイル共有のスナップショットのマウントに関する記事を参照してください。
マウントしようとしているスナップショットが存在しない場合、 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] タブを選択します。
Linux では、次のようなエラー メッセージが表示される場合があります。
<filename> [アクセス許可が拒否されました] ディスク クォータを超えました
ファイルまたはディレクトリで許容される、同時に開くことのできるハンドルの上限に達しました。
Azure Files では、ルート ディレクトリで 10,000 個のオープン ハンドルが、共有内のファイルとディレクトリごとに 2,000 個のオープン ハンドルがサポートされます。
一部のハンドルを閉じてから操作を再試行して、同時に開いているハンドルの数を減らします。
ファイル共有、ディレクトリ、またはファイルの開いているハンドルを表示するには、Get-AzStorageFileHandle PowerShell コマンドレットを使用します。
ファイル共有、ディレクトリ、またはファイルの開いているハンドルを閉じるには、Close-AzStorageFileHandle PowerShell コマンドレットを使用します。
注意
Get-AzStorageFileHandle および Close-AzStorageFileHandle コマンドレットは、Az PowerShell モジュールのバージョン 2.4 以降に含まれます。 最新の Az PowerShell モジュールをインストールするには、「Install the Azure PowerShell module」(Azure PowerShell モジュールのインストール) を参照してください。
ファイルがネットワーク経由でコピーされる場合、ファイルはコピー元コンピューターで暗号化が解除された後、プレーンテキストとして送信され、コピー先で再暗号化されます。 ただし、暗号化されたファイルをコピーしようとしている場合は、"暗号化をサポートしていない宛先に、ファイルをコピーします" というエラーが表示されることがあります。
この問題は、暗号化ファイル システム (EFS) を使用している場合に発生することがあります。 BitLocker で暗号化されたファイルは Azure Files にコピーできます。 ただし、Azure Files は、NTFS EFS をサポートしていません。
ネットワーク経由でファイルをコピーするには、まず、ファイルの暗号化を解除します。 以下のいずれかの方法を使用します。
レジストリ キーの設定は、ネットワーク共有に対するすべてのコピー操作に影響しますのでご注意ください。
条件ヘッダーが使用されるアプリケーション (Web ブラウザーなど) を通して Azure Files でホストされているコンテンツにアクセスすると、アクセスが失敗し、ConditionHeadersNotSupported エラーが発生します。 エラーは、条件ヘッダーがサポートされていないことを示しています。
条件付きヘッダーはまだサポートされていません。 それらを実装しているアプリケーションでは、ファイルにアクセスするたびに、ファイル全体を要求する必要があります。
新しいファイルをアップロードすると、既定では CacheControl プロパティは no-cache です。 アプリケーションで毎回ファイルを要求するには、ファイルの CacheControl プロパティを no-cache から no-cache、no-store、must-revalidate に更新する必要があります。 これは、Azure Storage Explorer を使用して実現できます。
質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。
トレーニング
ラーニング パス
Azure でハイパフォーマンス コンピューティング (HPC) アプリケーションを実行する - Training
Azure HPC は、優れたアプリケーション パフォーマンス、スケーラビリティ、および価値を実現するために、最先端のプロセッサと HPC クラス InfiniBand の相互接続を使用して、HPC & AI ワークロード用に構築されたクラウド機能です。 Azure HPC では、お客様のビジネスや技術的なニーズの変化に応じて動的に割り当てることができる、HPC & AI テクノロジの高可用性範囲を通じて、イノベーション、生産性、およびビジネスの機敏性を向上させることができます。 このラーニング パスは、Azure HPC の使用を開始するのに役立つ一連のモジュールです。最も関心のあるトピックを選択したり、各トピックを 1つずつ順番に表示したりすることができます。
ドキュメント
Azure Files のトラブルシューティング - Azure
Azure ファイル共有に関する問題をトラブルシューティングします。 一般的な問題を参照し、考えられる解決策を調べます。
Windows と Windows Server での Azure ファイル共有の使用方法について説明します。 オンプレミスまたは Azure VM で実行されている Windows インストールで、SMB 3.x を使用して Azure ファイル共有を利用します。
安全な転送、パブリックおよびプライベート エンドポイント、VPN、ExpressRoute、DNS、ファイアウォールの設定など、Azure Files のネットワークに関する考慮事項とオプションの概要。