Azure ファイル共有をマウントできません - Azure

[アーティクル]
04/12/2024

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

現象

Azure Kubernetes Service (AKS) 環境で、デプロイや StatefulSet などの Kubernetes リソースをデプロイします。デプロイでは、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)

注:

ストレージアカウントにパブリックにアクセスできる場合、出力に表示されるホスト名は 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 アドレスをチェックするには、などのnslookupdighostドメインネームシステム (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 が有効なノードプールが使用される

注:

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

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

ファイル共有が存在するかどうかをチェックするには、次の手順に従います。

Azure portalのストレージアカウントをSearchし、ストレージアカウントにアクセスします。
[ストレージアカウントのデータストレージ] で [ファイル共有] を選択し、ポッド、デプロイ、またはステートフルセットの yaml ファイルに関連付けられている PersistentVolumeClaim がファイル共有に存在する場合にチェックします。

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

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

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

NSG がストレージアカウントの IP アドレスをブロックするかどうかをチェックするには、次の手順に従います。

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

[Traffic status]\(トラフィックの状態\) は [許可] または [拒否] です。 拒否状態は、NSG が AKS クラスターとストレージアカウント間のトラフィックをブロックしていることを意味します。状態が [拒否] の場合は、NSG 名が表示されます。

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

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

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

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

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

AKS クラスターのトラフィックを制御するルートテーブルを確認するには、次の手順に従います。

Azure portalで AKS クラスターに移動し、[プロパティ>インフラストラクチャ] リソースグループを選択します。
このような VM セットの種類を使用している場合は、仮想マシンスケールセット (VMSS) または可用性セット内の VM にアクセスします。
[ 仮想ネットワーク/サブネットサブネット>] を 選択し、AKS クラスターのサブネットを特定します。右側にルートテーブルが表示されます。

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

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

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

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

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

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

原因 4: FIPS が有効なノードプールが使用される

Federal Information Processing Standard (FIPS) 対応ノードプールを使用する場合、FIPS によって一部の認証モジュールが無効になるため、マウント操作は失敗し、CIFS 共有のマウントが妨けられます。この動作は、AKS に固有ではなく、予期されます。

この問題を解決するには、次のいずれかの解決策を使用します。

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

FIPS は、AKS ノードプールでは既定で無効になっており、パラメーターを使用 --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 
```
PREMIUM SKU は NFS に必要であるため、SKU は YAML ファイル内で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: ストレージアカウントの最小暗号化要件が満たされていない

注:

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

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

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

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

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

不一致の原因として考えられる

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

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

不一致を確認する

不一致を確認するには、次の手順に従います。

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

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

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

詳細については、「 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 クラスターに移動し、[プロパティ>インフラストラクチャ] リソースグループを選択し、ノードに関連付けられている VMSS にアクセスし、[仮想ネットワーク/サブネット] をチェックして VNET とサブネットを識別します。
Azure portalのストレージアカウントにアクセスします。 [ ネットワーク] を選択します。 [アクセスを許可する] が [選択されたネットワーク] に設定されている場合は、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 バージョンは、Linux 5.4 カーネルを使用し、AES-128-CCM と AES-128-GCM 暗号化アルゴリズムのみをサポートする Ubuntu 18.04 LTS に基づいています。 最大セキュリティ プロファイル、または AES-128-GCM を無効にするカスタム プロファイルでは、共有マッピングエラーが発生します。

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

解決策: AES-128-GCM 暗号化アルゴリズムの使用を許可する

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

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

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

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

最大セキュリティ (SMB 3.1.1) である AES-256-GCM 暗号化のみを使用する場合は、次の操作を行います。

Linux

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

cifsConfPath="/etc/modprobe.d/cifs.conf" 
echo "`date` before change ${cifsConfPath}:"
cat ${cifsConfPath}
if !(( grep require_gcm_256 ${cifsConfPath} ))
then
modprobe cifs
echo 1 > /sys/module/cifs/parameters/require_gcm_256
echo "options cifs require_gcm_256=1" > ${cifsConfPath}
echo "`date` after changing ${cifsConfPath}:"
cat ${cifsConfPath}
fi

Windows

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

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

注:

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

詳細

その他のマウントエラーが発生した場合は、「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

詳細

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

フィードバック

フィードバック

その他のリソース

次の方法で共有

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

詳細

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

フィードバック

フィードバック

その他のリソース

マウントエラー(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 暗号化アルゴリズムを有効にする