Azure ファイル共有をマウントできない - Azure

[アーティクル]
11/20/2024

この記事では、Azure ファイル共有のマウントが失敗する原因となるエラーの考えられる原因と解決策について説明します。

現象

デプロイや StatefulSet などの Kubernetes リソースは、Azure Kubernetes Service (AKS) 環境にデプロイします。デプロイでは、Azure ファイル共有を参照する PersistentVolumeClaim (PVC) をマウントするポッドが作成されます。

ただし、ポッドは ContainerCreating 状態のままです。 kubectl describe pods コマンドを実行すると、コマンド出力に次のいずれかのエラーが表示され、マウント操作が失敗することがあります。

マウントエラー (2):を開けませんでした原因: ファイルまたはディレクトリが存在しません
マウントマウントエラー (13): アクセス許可は拒否されました

例として、次の出力を参照してください。

MountVolume.MountDevice failed for volume "\<pv-fileshare-name>"
rpc error: code = Internal desc =
volume(\<storage-account's-resource-group>#\<storage-account-name>#\<pv/fileshare-name>#) > mount "//\<storage-account-name>.file.core.windows.net/\<pv-fileshare-name>" on "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-fileshare-name>/globalmount" failed with
mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t cifs -o dir_mode=0777,file_mode=0777,uid=0,gid=0,mfsymlinks,cache=strict,actimeo=30,\<masked> //\<storage-account-name>.file.core.windows.net/\<pv-name> /var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-name>/globalmount
Output: mount error(\<error-id>): \<error-description>
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Note

ストレージアカウントにパブリックにアクセスできる場合、出力に表示されるホスト名は <storage-account-name>.file.core.windows.net になります。
ストレージアカウントがプライベートリンク、エンドポイント、または DNS ゾーンを使用してプライベートに構成されている場合、ホスト名は <storage-account-name>.privatelink.file.core.windows.net になります。

トラブルシューティングの前に

次の例に示すように、出力のメッセージに従って、ストレージアカウントとファイル共有を特定します。これらの値は後のトラブルシューティング手順で使われます。

mount "//<storage-account-name>.file.core.windows.net/<pv-fileshare-name>"

考えられる原因と解決方法については、以下のセクションを参照してください。

マウントエラー (2):を開けませんでした原因: ファイルまたはディレクトリが存在しません

このエラーは、AKS クラスターとストレージアカウント間に接続がないことを示します。

初期のトラブルシューティング

Azure File は SMB プロトコル (ポート 445) に依存しています。ポート 445 とストレージアカウントの IP アドレスがブロックされていないことを確認します。

ストレージアカウントの IP アドレスを確認するには、nslookup、dig、host などのドメインネームシステム (DNS) コマンドを実行します。例えば次が挙げられます。

nslookup <storage-account-name>.file.core.windows.net

AKS クラスターとストレージアカウント間に接続があるかどうかを確認するには、ノードまたはポッド内に移動し、次の nc または telnet コマンドを実行します。

nc -v -w 2 <storage-account-name>.file.core.windows.net 445

telnet <storage-account-name>.file.core.windows.net 445

マウントエラー (2) の考えられる原因

原因 1: ファイル共有が存在しない
原因 2: NSG によって AKS とストレージアカウント間のトラフィックがブロックされる
原因 3: 仮想アプライアンスが AKS とストレージアカウント間のトラフィックをブロックしている
原因 4: FIPS 対応ノードプールが使われている

Note

原因 1、2、4 は、パブリックおよびプライベートストレージアカウントのシナリオに適用されます。
原因 3 は、パブリックシナリオにのみ適用されます。

原因 1: ファイル共有が存在しない

ファイル共有が存在するかどうかを確認するには、以下の手順を実行します。

Azure portal で Storage アカウント を検索し、ストレージアカウントにアクセスします。
ストレージアカウントの Data storage で File 共有を選択し、ポッド、デプロイ、またはステートフルセットの yaml ファイルに関連付けられている PersistentVolumeClaim が File 共有に存在するかどうかを確認。

この問題を解決するには、PV/PVC に関連付けられたファイル共有が存在することを確認します。

原因 2: ネットワークセキュリティグループが AKS とストレージアカウント間のトラフィックをブロックしている

「Initial troubleshooting」セクションで説明されているncまたはtelnet コマンドの出力を確認します。タイムアウトが表示された場合は、ネットワークセキュリティグループ (NSG) を確認し、ストレージアカウントの IP アドレスがブロックされていないことを確認します。

NSG がストレージアカウントの IP アドレスをブロックしているかどうかを確認するには、以下の手順を実行します。

Azure portal で、 Network Watcher に移動し NSG 診断選択。
フィールドに次の値を入力します。
- プロトコル:任意
- 方向: 送信
- ソースの種類: IPv4 アドレス/CIDR
- IPv4 アドレス/CIDR: AKS ノードに関連付けられているインスタンスの IP アドレス
- 宛先 IP アドレス: ストレージアカウントの IP アドレス
- 宛先ポート: 445
Check ボタンを選択し、Traffic 状態を確認します。

Trafficの状態は、AllowedまたはDeniedできます。 Denied状態は、NSG が AKS クラスターとストレージアカウント間のトラフィックをブロックしていることを意味します。状態が Denied の場合、NSG 名が表示されます。

解決策: AKS とストレージアカウント間の接続を許可する

この問題を解決するには、NSG レベルで適宜変更を加えて、ポート 445 での AKS クラスターとストレージアカウント間の接続を許可します。

原因 3: 仮想アプライアンスが AKS とストレージアカウント間のトラフィックをブロックしている

仮想アプライアンス (通常はファイアウォール) を使って AKS クラスターの送信トラフィックを制御している場合 (たとえば、仮想アプライアンスには AKS クラスターのサブネットで適用されるルートテーブルがあり、ルートテーブルには仮想アプライアンスに向けてトラフィックを送信するルートがある)、仮想アプライアンスは AKS クラスターとストレージアカウント間のトラフィックをブロックする可能性があります。

問題を切り分けるために、ストレージアカウントの IP アドレスのルートテーブルに、トラフィックをインターネットに送信するルートを追加します。

どのルートテーブルが AKS クラスターのトラフィックを制御しているかを確認するために、以下の手順を実行します。

Azure portal で AKS クラスターに移動し、 Properties>Infrastructure リソースグループを選択します。
仮想マシンスケールセット (VMSS) または可用性セット内の VM (そのような VM セットの種類を使っている場合) にアクセスします。
仮想ネットワーク/サブネット>Subnets を選択し、AKS クラスターのサブネットを識別します。右側にルートテーブルが表示されます。

ルートテーブルにルートを追加するには、「ルートの作成」の手順に従って次のフィールドに入力します。

アドレスプレフィックス: <storage-account's-public-IP>/32
次ホップの種類:インターネット

このルートからは、AKS クラスターとストレージアカウント間のすべてのトラフィックがパブリックインターネットを介して送信されます。

このルートを追加したら、nc または telnet コマンドを使って接続をテストし、マウント操作をもう一度実行します。

解決策: 仮想アプライアンスが AKS とストレージアカウント間のトラフィックを許可していることを確認する

マウント操作に成功した場合は、ネットワークチームに相談して、仮想アプライアンスがポート 445 で AKS クラスターとストレージアカウント間のトラフィックを許可できることを確認することをお勧めします。

原因 4: FIPS 対応ノードプールが使われている

Federal Information Processing Standards (FIPS) 対応ノードプールを使っている場合、マウント操作は失敗します。これは、FIPS によ一部の認証モジュールが無効になり、その結果、CIFS 共有をマウントできなくなるためです。これは想定された動作であり、AKS に固有のものではありません。

この問題を解決するには、次の解決策のいずれかを採用してください。

解決策 1: 非 FIPS ノードプール内のノードでポッドをスケジュールする

AKS ノードプールの既定で FIPS は無効であり、--enable-fips-image パラメーターを使ってノードプールの作成時にのみ有効にすることができます。

このエラーを解決するには、非 FIPS ノードプール内のノードでポッドをスケジュールします。

解決策 2: FIPS 対応ノードでスケジュールできるポッドを作成する

FIPS 対応ノードでスケジュールできるポッドを作成するには、以下の手順を実行します。

Azure File CSI ドライバーを使って、NFS プロトコルを使うカスタムの StorageClass を作成します。

次の YAML ファイルを例として参考にしてください。
```
kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 
  name: azurefile-sc-fips 
provisioner: file.csi.azure.com 
reclaimPolicy: Delete 
volumeBindingMode: Immediate 
allowVolumeExpansion: true 
parameters: 
  skuName: Premium_LRS 
  protocol: nfs 
```
NFS には Premium SKU が必要なので、YAML ファイルでは SKU が Premium_LRS に設定されています。詳細については、「動的プロビジョニング」を参照してください。

Premium SKU なので、ファイル共有の最小サイズは 100 GB です。詳細については、「ストレージクラスの作成」を参照してください。

カスタム StorageClass azurefile-sc-fips を参照する PVC を作成します。

次の YAML ファイルを例として参考にしてください。

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: azurefile-pvc-fips 
spec: 
  accessModes: 
    - ReadWriteMany 
  storageClassName: azurefile-sc-fips 
  resources: 
    requests: 
      storage: 100Gi

PVC azurefile-pvc-fips をマウントするポッドを作成します。

次の YAML ファイルを例として参考にしてください。

kind: Pod 
apiVersion: v1 
metadata: 
  name: azurefile-pod-fips 
spec: 
  containers: 
  - name: azurefile-pod-fips 
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine 
    resources: 
      requests: 
        cpu: 100m 
        memory: 128Mi 
      limits: 
        cpu: 250m 
        memory: 256Mi 
    volumeMounts: 
    - mountPath: "/mnt/azure" 
      name: volume 
  volumes: 
    - name: volume 
      persistentVolumeClaim: 
        claimName: azurefile-pvc-fips

マウントマウントエラー (13): アクセス許可は拒否されました

このエラーの原因として、次のことが考えられます。

原因 1: Kubernetes のシークレットが正しいストレージアカウント名またはキーを参照していない
原因 2: このストレージアカウントに AKS の VNET とサブネットは許可されていない
原因 3: 接続はプライベートリンク経由ですが、ノードとプライベートエンドポイントは異なる VNET 内にあります
原因 4: クライアントがサポートしていない暗号化を要求するようにストレージアカウントが設定されている
原因 5: ストレージアカウントの最小暗号化要件が満たされていない
原因 6: NTLM v2 認証が有効になっていない状態でセキュリティプロファイルが使用される

Note

原因 1 は、パブリックとプライベートのシナリオに適用されます。
原因 2 は、パブリックシナリオにのみ適用されます。
原因 3 は、プライベートシナリオにのみ適用されます。
原因 4 は、パブリックとプライベートのシナリオに適用されます。
原因 5 は、パブリックシナリオとプライベートシナリオに適用されます。
原因 6 は、パブリックとプライベートのシナリオに適用されます。

原因 1: Kubernetes のシークレットが正しいストレージアカウント名またはキーを参照していない

ファイル共有が動的に作成場合、"azure-storage-account-<storage-account-name>-secret" という名前のKubernetes シークレットリソースが自動的に作成されます。

ファイル共有を手動で作成した場合は、Kubernetes シークレットリソースを手動で作成する必要があります。

作成方法に関係なく、Kubernetes シークレットで参照されるストレージアカウント名やキーが実際の値と異なる場合、マウント操作は "アクセス許可が拒否されました" エラーで失敗します。

不一致の考えられる原因

Kubernetes シークレットを手動で作成した場合、作成時に入力ミスが発生する可能性があります。
ストレージアカウントレベルで "キーのローテーション" 操作を実行した場合、その変更は Kubernetes のシークレットレベルには反映されません。その結果、ストレージアカウントレベルのキー値と Kubernetes シークレットレベルの値は一致しなくなります。

"キーのローテーション" 操作が発生した場合、ストレージアカウントの [アクティビティログ] に "ストレージアカウントキーの再生成" という操作が表示されます。 90 日という [アクティビティログ] の保持期間に注意してください。

不一致を確認する

不一致を確認するには、以下の手順を実行します。

Azure portal でストレージアカウントを検索してアクセスします。ストレージアカウントで Access キー>Show キー を選択します。ストレージアカウント名とそれに関連付けられたキーが表示されます。
AKS クラスターに移動し、 Configuration>Secrets を選択し、関連付けられているシークレットを検索してアクセスします。
Show (目のアイコン) を選択し、ストレージアカウント名と関連付けられているキーの値を手順 1 の値と比較します。

Show を選択する前に、ストレージアカウント名と関連付けられているキーの値が base64 文字列にエンコードされます。 Showを選択すると、値がデコードされます。

Azure portal で AKS クラスターにアクセスできない場合は、kubectl レベルで手順 2 を実行します。

Kubernetes シークレットの YAML ファイルを取得し、次のコマンドを実行して、ストレージアカウント名とキーの値を出力から取得します。
```
kubectl get secret <secret-name> -n <secret-namespace> -o <yaml-file-name>
```
echo コマンドを使って、ストレージアカウント名とキーの値をデコードし、ストレージアカウントレベルの値と比較します。

ストレージアカウント名をデコードする例を次に示します。
```
echo -n '<storage account name>' | base64 --decode ;echo
```

解決策: Kubernetes シークレットを調整し、ポッドを再作成する

Kubernetes シークレットのストレージアカウント名またはキーの値がストレージアカウントの Access キー の値と一致しない場合は、次のコマンドを実行して Kubernetes シークレットレベルで Kubernetes シークレットを調整します。

kubectl edit secret <secret-name> -n <secret-namespace>

Kubernetes シークレット構成で追加したストレージアカウント名またはキーの値は、base64 でエンコードされた値である必要があります。エンコードされた値を取得するには、echo コマンドを使います。

ストレージアカウント名をエンコードする例を次に示します。

echo -n '<storage account name>'| base64 | tr -d '\n' ; echo

詳細については、「Managing Secrets using kubectl」(kubectl を使ったシークレットの管理) を参照してください。

Kubernetes シークレット azure-storage-account-<storage-account-name>-secret に正しい値が設定されたら、ポッドを再作成します。そうしないと、有効ではない古い値をそれらのポッドが使い続けることになります。

原因 2: このストレージアカウントに AKS の VNET とサブネットは許可されていない

ストレージアカウントのネットワークを選んだネットワークに限定している場合、その選んだネットワークに AKS クラスターの VNET とサブネットを追加していないと、マウント操作は "アクセス許可が拒否されました" エラーで失敗します。

解決策: ストレージアカウントに AKS の VNET とサブネットを許可する

次のコマンドを実行して、障害のあるポッドをホストするノードを特定します。
```
kubectl get pod <pod-name> -n <namespace> -o wide
```
コマンドの出力でノードを確認します。
Azure portal で AKS クラスターに移動し、 Properties>Infrastructure リソースグループを選択しノードに関連付けられている VMSS にアクセスし、 仮想ネットワーク/サブネット を確認して VNET とサブネットを識別します。
Azure portal でストレージアカウントにアクセスします。 [ネットワーク] を選択します。 AKS クラスターの VNET とサブネットが選択されたネットワークに設定されている場合AKS クラスターの VNET とサブネットが追加されているかどうかを確認します。

AKS クラスターの VNET とサブネットが追加されていない場合は、 既存の仮想ネットワークの追加を選択します。 ネットワークの追加 ページで、AKS クラスターの VNET とサブネットを入力し、追加>保存を選択します。

変更が有効になるまでに数分かかる場合があります。 VNET とサブネットが追加されたら、ポッドの状態が ContainerCreating から Running に変わるかどうかを確認します。

原因 3: 接続はプライベートリンク経由だが、ノードとプライベートエンドポイントが異なる VNET 内にある

AKS クラスターとストレージアカウントがプライベートリンクを介して接続されている場合、承認済みのプライベートエンドポイント接続が使われます。

このシナリオでは、プライベートエンドポイントと AKS ノードが同じ VNET にある場合、Azure ファイル共有をマウントできます。

プライベートエンドポイントと AKS クラスターが異なる VNET にある場合、マウント操作は "アクセス許可が拒否されました" エラーで失敗します。

解決策: プライベート DNS ゾーンで AKS クラスターの VNET 用に仮想ネットワークリンクを作成する

ノード内に移動し、完全修飾ドメイン名 (FQDN) がパブリックまたはプライベートの IP アドレスを介して解決されているかどうかを確認します。そのためには、次のコマンドを実行します。

nslookup <storage-account-name>.privatelink.file.core.windows.net

FQDN がパブリック IP アドレスを介して解決されている場合 (以下のスクリーンショットを参照してください)、プライベート DNS ゾーン ("privatelink.file.core.windows.net") レベルで AKS クラスターの VNET 用に仮想ネットワークリンクを作成します。仮想ネットワークリンクは、ストレージアカウントのプライベートエンドポイントの VNET 用に既に自動的に作成されていることに注意してください。

仮想ネットワークリンクを作成するには、以下の手順を実行します。

プライベート DNS ゾーンにアクセスし、仮想ネットワークリンク>追加を選択します。
フィールドに入力し、 仮想ネットワークの AKS クラスターの VNET を選択。 AKS クラスターの VNET を特定する方法については、「解決策: ストレージアカウントに AKS の VNET とサブネットを許可する」を参照してください。
[OK] を選択します。

仮想ネットワークリンクを追加すると、FQDN はプライベート IP アドレスを介して解決され、マウント操作は成功するはずです。例については、次のスクリーンショットを参照してください。

原因 4: クライアントがサポートしていない暗号化を要求するようにストレージアカウントが設定されている

Azure Files の [セキュリティ設定] には、ストレージアカウントに対するセキュリティと暗号化の設定を制御するオプションが多数あります。許可する方法とアルゴリズムを制限すると、クライアントが接続できなくなる可能性があります。

1.25 より前の AKS バージョンは Ubuntu 18.04 LTS に基づいています。これは、Linux 5.4 カーネルを使い、AES-128-CCM と AES-128-GCM の暗号化アルゴリズムのみをサポートするものです。 [最大のセキュリティ] プロファイル、または AES-128-GCM を無効にする [カスタム] プロファイルは共有マッピングエラーの原因になります。

AKS バージョン 1.25 以降のバージョンは Ubuntu 22.04 に基づいています。これは、Linux 5.15 カーネルを使い、AES-256-GCM をサポートするものです。

解決策: AES-128-GCM の暗号化アルゴリズムを使用できるようにする

[最大の互換性] プロファイルまたは AES-128-GCM を有効にする [カスタム] プロファイルを使って、AES-128-GCM アルゴリズムを有効にします。詳細については、Azure Files のセキュリティ設定に関する記事を参照してください。

原因 5: ストレージアカウントの最小暗号化要件が満たされていない

解決策: すべてのストレージアカウントに対して AES-128-GCM 暗号化アルゴリズムを有効にする

ファイル共有を正常にマウントまたはアクセスするには、すべてのストレージアカウントに対して AES-128-GCM 暗号化アルゴリズムを有効にする必要があります。

AES-256-GCM 暗号化のみを使用する場合は、次の操作を行います。

Linux

次のスクリプトを使用して、クライアントが AES-256-GCM をサポートしているかどうかを確認し、サポートされている場合にのみ適用します。

cifsConfPath="/etc/modprobe.d/cifs.conf"
echo "$(date) before change ${cifsConfPath}:"
cat ${cifsConfPath}

# Check if 'require_gcm_256' is already present in the configuration file
if ! grep -q "require_gcm_256" "${cifsConfPath}"; then

    # Load the CIFS module
    modprobe cifs

    # Set the parameter at runtime
    echo 1 > /sys/module/cifs/parameters/require_gcm_256

    # Persist the configuration
    echo "options cifs require_gcm_256=1" >> "${cifsConfPath}"

    echo "$(date) after changing ${cifsConfPath}:"
    cat "${cifsConfPath}"
else
    echo "require_gcm_256 is already set in ${cifsConfPath}"
fi

Kubernetes DaemonSet を使用して、すべてのノードに AES-256 を適用することもできます。次の例を参照してください。

support-cifs-aes-256-gcm.yaml

Windows

Set-SmbClientConfiguration PowerShell コマンドを使用して、SMB クライアントで使用される暗号化暗号と、ユーザーの確認なしで優先する暗号化の種類を指定します。

Set-SmbClientConfiguration -EncryptionCiphers "AES_256_GCM" -Confirm:$false

Note

EncryptionCiphers パラメーターは、x64 ベースシステム (KB5014665) の Windows Server バージョン 21H2 用の 2022-06 累積的な更新プログラムと、Windows 11 バージョン 22H2 の累積的な更新プログラム (KB5014668) 以降で使用できます。

原因 6: NTLM v2 認証が有効になっていない状態でセキュリティプロファイルが使用される

NTLM v2 認証メカニズムを有効にせずに Maximum セキュリティ プロファイルまたは Custom セキュリティプロファイルを使用すると、マウント操作は "マウントエラー (13): アクセス許可が拒否されました" エラーで失敗します。

解決策: NTLM v2 認証を有効にするか、"最大互換性" プロファイルを使用する

AKS で適切にマウントするには、 NTLM v2 Custom セキュリティプロファイルの認証メカニズムを有効にするか、 Maximum 互換性 セキュリティプロファイルを使用する必要があります。

詳細

その他のマウントエラーが発生する場合は、「 Linux で Azure Files の問題をトラブルシューティングするを参照してください。

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

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

次の方法で共有

現象

トラブルシューティングの前に

マウントエラー (2):を開けませんでした原因: ファイルまたはディレクトリが存在しません

初期のトラブルシューティング

マウントエラー (2) の考えられる原因

原因 1: ファイル共有が存在しない

原因 2: ネットワークセキュリティグループが AKS とストレージアカウント間のトラフィックをブロックしている

解決策: AKS とストレージアカウント間の接続を許可する

原因 3: 仮想アプライアンスが AKS とストレージアカウント間のトラフィックをブロックしている

解決策: 仮想アプライアンスが AKS とストレージアカウント間のトラフィックを許可していることを確認する

原因 4: FIPS 対応ノードプールが使われている

解決策 1: 非 FIPS ノードプール内のノードでポッドをスケジュールする

解決策 2: FIPS 対応ノードでスケジュールできるポッドを作成する

マウントマウントエラー (13): アクセス許可は拒否されました

原因 1: Kubernetes のシークレットが正しいストレージアカウント名またはキーを参照していない

不一致の考えられる原因

不一致を確認する

解決策: Kubernetes シークレットを調整し、ポッドを再作成する

原因 2: このストレージアカウントに AKS の VNET とサブネットは許可されていない

解決策: ストレージアカウントに AKS の VNET とサブネットを許可する

原因 3: 接続はプライベートリンク経由だが、ノードとプライベートエンドポイントが異なる VNET 内にある

解決策: プライベート DNS ゾーンで AKS クラスターの VNET 用に仮想ネットワークリンクを作成する

原因 4: クライアントがサポートしていない暗号化を要求するようにストレージアカウントが設定されている

解決策: AES-128-GCM の暗号化アルゴリズムを使用できるようにする

原因 5: ストレージアカウントの最小暗号化要件が満たされていない

解決策: すべてのストレージアカウントに対して AES-128-GCM 暗号化アルゴリズムを有効にする

Linux

Windows

原因 6: NTLM v2 認証が有効になっていない状態でセキュリティプロファイルが使用される

解決策: NTLM v2 認証を有効にするか、"最大互換性" プロファイルを使用する

詳細

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

フィードバック

その他のリソース

次の方法で共有

Azure ファイル共有をマウントするときのエラー

現象

トラブルシューティングの前に

マウント エラー (2):を開けませんでした 原因: ファイルまたはディレクトリが存在しません

初期のトラブルシューティング

マウント エラー (2) の考えられる原因

原因 1: ファイル共有が存在しない

解決策: ファイル共有が存在することを確認する

原因 2: ネットワーク セキュリティ グループが AKS とストレージ アカウント間のトラフィックをブロックしている

解決策: AKS とストレージ アカウント間の接続を許可する

原因 3: 仮想アプライアンスが AKS とストレージ アカウント間のトラフィックをブロックしている

解決策: 仮想アプライアンスが AKS とストレージ アカウント間のトラフィックを許可していることを確認する

原因 4: FIPS 対応ノード プールが使われている

解決策 1: 非 FIPS ノード プール内のノードでポッドをスケジュールする

解決策 2: FIPS 対応ノードでスケジュールできるポッドを作成する

マウントマウント エラー (13): アクセス許可は拒否されました

原因 1: Kubernetes のシークレットが正しいストレージ アカウント名またはキーを参照していない

不一致の考えられる原因

不一致を確認する

解決策: Kubernetes シークレットを調整し、ポッドを再作成する

原因 2: このストレージ アカウントに AKS の VNET とサブネットは許可されていない

解決策: ストレージ アカウントに AKS の VNET とサブネットを許可する

原因 3: 接続はプライベート リンク経由だが、ノードとプライベート エンドポイントが異なる VNET 内にある

解決策: プライベート DNS ゾーンで AKS クラスターの VNET 用に仮想ネットワーク リンクを作成する

原因 4: クライアントがサポートしていない暗号化を要求するようにストレージ アカウントが設定されている

解決策: AES-128-GCM の暗号化アルゴリズムを使用できるようにする

原因 5: ストレージ アカウントの最小暗号化要件が満たされていない

解決策: すべてのストレージ アカウントに対して AES-128-GCM 暗号化アルゴリズムを有効にする

Linux

Windows

原因 6: NTLM v2 認証が有効になっていない状態でセキュリティ プロファイルが使用される

解決策: NTLM v2 認証を有効にするか、"最大互換性" プロファイルを使用する

詳細

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

フィードバック

その他のリソース

マウントエラー (2):を開けませんでした原因: ファイルまたはディレクトリが存在しません

マウントエラー (2) の考えられる原因

原因 2: ネットワークセキュリティグループが AKS とストレージアカウント間のトラフィックをブロックしている

解決策: AKS とストレージアカウント間の接続を許可する

原因 3: 仮想アプライアンスが AKS とストレージアカウント間のトラフィックをブロックしている

解決策: 仮想アプライアンスが AKS とストレージアカウント間のトラフィックを許可していることを確認する

原因 4: FIPS 対応ノードプールが使われている

解決策 1: 非 FIPS ノードプール内のノードでポッドをスケジュールする

マウントマウントエラー (13): アクセス許可は拒否されました

原因 1: Kubernetes のシークレットが正しいストレージアカウント名またはキーを参照していない

原因 2: このストレージアカウントに AKS の VNET とサブネットは許可されていない

解決策: ストレージアカウントに AKS の VNET とサブネットを許可する

原因 3: 接続はプライベートリンク経由だが、ノードとプライベートエンドポイントが異なる VNET 内にある

解決策: プライベート DNS ゾーンで AKS クラスターの VNET 用に仮想ネットワークリンクを作成する

原因 4: クライアントがサポートしていない暗号化を要求するようにストレージアカウントが設定されている

原因 5: ストレージアカウントの最小暗号化要件が満たされていない

解決策: すべてのストレージアカウントに対して AES-128-GCM 暗号化アルゴリズムを有効にする

原因 6: NTLM v2 認証が有効になっていない状態でセキュリティプロファイルが使用される