次の方法で共有

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

  • [アーティクル]

この記事では、Windows または Linux クライアントからサーバー メッセージ ブロック (SMB) Azure ファイル共有に接続してアクセスしようとしたときに発生する可能性がある一般的な問題の一覧を示します。 これらの問題の考えられる原因と解決策についても説明します。

Note

この記事は役に立ちましたか? あなたの入力は私たちにとって重要です。 このページの Feedback ボタンを使用して、この記事がどれだけうまく機能したか、または改善方法をお知らせください。

重要

この記事は、SMB 共有にのみ適用されます。 ネットワーク ファイル システム (NFS) 共有の詳細については、「 Azure NFS ファイル共有をトラブルシューティングする」を参照してください。

適用対象

ファイル共有の種類 SMB NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (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 の解決策

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

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

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

原因 2 の解決策

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

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

ユーザーが ID ベースの認証を使用して Azure ファイル共有にアクセスしている場合、共有レベルのアクセス許可が正しくない場合、ファイル共有へのアクセスは "アクセスが拒否されました" というエラーで失敗します。

原因 3 の解決策

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

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

Note

このコマンドは、ストレージ アカウントの現在の IP アドレスを返します。 この IP アドレスは同じ状態で維持される保証がなく、常に変化する可能性があります。 この IP アドレスをスクリプトやファイアウォールの構成にハードコーディングしないでください。

原因 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 解決と接続 確認します。

Azure ファイル共有 (または共有スナップショット) にアクセスできないか、これを変更または削除できない

ユーザーが開始したフェールオーバー後の "ユーザー名またはパスワードが正しくありません" エラー

geo 冗長ストレージ アカウントを使用する顧客が開始したフェールオーバー シナリオでは、フェールオーバー時にファイル ハンドルとリースは保持されません。 クライアントは、ファイル共有のマウントを解除して再マウントする必要があります。

Azure ファイル共有にアクセスするか、Azure ファイル共有を削除しようとしたときに "アクセス権なし" というエラーが発生する

Azure portal を使用して Azure ファイル共有にアクセスするか、Azure ファイル共有を削除しようとしたときに、以下のエラーが発生する場合があります。

"アクセス権なし" エラー コード: 403

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

原因 1 の解決策

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

原因 2: ユーザー アカウントに、ストレージ アカウントへのアクセス権がない

原因 2 の解決策

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] タブを選択します。

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

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

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

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

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

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

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

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

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

Note

REST リースは、ファイルが削除または変更されないようにするために、アプリケーションによって使用されます。 リースを解除する前に、どのアプリケーションがリースを取得するかを特定する必要があります。 そうしないと、アプリケーションの動作が中断される可能性があります。

原因 1

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

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

解決策 1

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

Note

Get-AzStorageFileHandle および Close-AzStorageFileHandle コマンドレットは、Az PowerShell モジュールのバージョン 2.4 以降に含まれます。 最新の Az PowerShell モジュールをインストールするには、「Install the Azure PowerShell module」(Azure 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 で Azure ファイル共有スナップショットをマウントできない

Linux で Azure ファイル共有スナップショットをマウントしようとしたときの "マウント エラー (22): 引数が無効です"

原因

mount コマンドの snapshot オプションが認識される形式で渡されなかった場合、mount コマンドはこのエラーで失敗することがあります。 これを確認するには、カーネル ログ メッセージ (dmesg) を確認すると、dmesg に cifs: Bad value for 'snapshot' などのログ エントリが表示されます。

ソリューション

mount コマンドの snapshot オプションを正しい形式で渡していることを確認します。 mount.cifs のマニュアル ページを参照してください (例: man mount.cifs)。 よくあるエラーは、ピリオドではなくハイフンやコロンを使うなど、間違った形式で GMT タイムスタンプを渡すことです。 詳細については、ファイル共有のスナップショットのマウントに関する記事を参照してください。

Linux で Azure ファイル共有のスナップショットをマウントしようとしたときの "Bad snapshot token" (不適切なスナップショット トークン)

原因

@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 コマンドレットを使用します。

Note

Get-AzStorageFileHandle および Close-AzStorageFileHandle コマンドレットは、Az PowerShell モジュールのバージョン 2.4 以降に含まれます。 最新の Az PowerShell モジュールをインストールするには、「Install the Azure PowerShell module」(Azure PowerShell モジュールのインストール) を参照してください。

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

原因

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

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

ソリューション

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

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

エラー "暗号化をサポートしていない宛先に、ファイルをコピーします"

ファイルがネットワーク経由でコピーされる場合、ファイルはコピー元コンピューターで暗号化が解除された後、プレーンテキストとして送信され、コピー先で再暗号化されます。 ただし、暗号化されたファイルをコピーしようとしている場合は、"暗号化をサポートしていない宛先に、ファイルをコピーします" というエラーが表示されることがあります。

原因

この問題は、暗号化ファイル システム (EFS) を使用している場合に発生することがあります。 BitLocker で暗号化されたファイルは Azure Files にコピーできます。 ただし、Azure Files は、NTFS EFS をサポートしていません。

回避策

ネットワーク経由でファイルをコピーするには、まず、ファイルの暗号化を解除します。 以下のいずれかの方法を使用します。

  • copy /d コマンドを使用します。 この方法では、暗号化されたファイルを、暗号化を解除したファイルとしてコピー先に保存することができます。
  • 次のレジストリ キーを設定します。
    • Path = HKLM\Software\Policies\Microsoft\Windows\System
    • Value type = DWORD
    • Name = CopyFileAllowDecryptedRemoteDestination
    • Value = 1

レジストリ キーの設定は、ネットワーク共有に対するすべてのコピー操作に影響しますのでご注意ください。

ブラウザーから Azure Files を使用する Web アプリケーションの ConditionHeadersNotSupported エラー

条件ヘッダーが使用されるアプリケーション (Web ブラウザーなど) を通して Azure Files でホストされているコンテンツにアクセスすると、アクセスが失敗し、ConditionHeadersNotSupported エラーが発生します。 エラーは、条件ヘッダーがサポートされていないことを示しています。

ConditionHeadersNotSupported エラー メッセージを示すスクリーンショット。

原因

条件付きヘッダーはまだサポートされていません。 それらを実装しているアプリケーションでは、ファイルにアクセスするたびに、ファイル全体を要求する必要があります。

回避策

新しいファイルをアップロードすると、既定では CacheControl プロパティは no-cache です。 アプリケーションで毎回ファイルを要求するには、ファイルの CacheControl プロパティを no-cache から no-cache、no-store、must-revalidate に更新する必要があります。 これは、Azure Storage Explorer を使用して実現できます。

CacheControl ファイルのプロパティを示すスクリーンショット。

関連項目

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。