NFS Azure ファイル共有のトラブルシューティング

  • [アーティクル]

注:

この記事で参照されている CentOS は Linux ディストリビューションであり、End Of Life (EOL) に到達します。 使用を検討し、それに応じて計画します。 詳細については、「 CentOS End Of Life ガイダンス」を参照してください。

この記事では、NFS Azure ファイル共有に関連する一般的な問題の一覧と、考えられる原因と回避策について説明します。

重要

この記事の内容は NFS 共有にのみ適用されます。 Linux で SMB の問題をトラブルシューティングするには、「Linux (SMB) でのAzure Filesの問題のトラブルシューティング」を参照してください。 NFS Azure ファイル共有は Windows ではサポートされていません。

適用対象

ファイル共有の種類 SMB Nfs
標準ファイル共有 (GPv2)、LRS/ZRS
標準ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

chgrp "filename" が失敗しました: 引数が無効です (22)

原因 1: idmapping が無効になっていない

Azure Filesでは英数字 UID/GID が許可されないため、idmapping を無効にする必要があります。

原因 2: idmapping が無効になりましたが、ファイル名/dir 名が正しくないと検出された後に再度有効になりました

idmapping を正しく無効にした場合でも、場合によっては自動的に再度有効にすることができます。 たとえば、Azure Filesが不適切なファイル名を検出すると、エラーが返されます。 このエラー コードが表示されると、NFS 4.1 Linux クライアントは idmapping を再度有効にし、英数字 UID/GID を使用して今後の要求を送信します。 Azure Filesでサポートされていない文字の一覧については、こちらの記事を参照してください。 コロンは、サポートされていない文字の 1 つです。

回避策

idmapping が無効になっており、再度有効にするものがないことを確認します。 次に、次の手順を実行します。

  1. 共有のマウントを解除します。

  2. idmapping を無効にするには、次の操作を行います。

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping

  3. 共有をマウントし直します。

  4. rsync を実行している場合は、ディレクトリ名またはファイル名が正しくないディレクトリから引数を指定して rsync —numeric-ids を実行します。

NFS 共有を作成できません

原因: サポートされていないストレージ アカウントの設定

NFS は、次の構成を持つストレージ アカウントでのみ使用できます。

ソリューション

「NFS 共有を作成する方法」の手順に従います。

NFS Azure ファイル共有に接続またはマウントできない

原因 1: 要求は、信頼されていないネットワーク/信頼されていない IP 内のクライアントから発生します

SMB とは異なり、NFS にはユーザーベースの認証がありません。 共有の認証は、ネットワーク セキュリティ規則の構成に基づいています。 クライアントが NFS 共有へのセキュリティで保護された接続のみを確立するには、サービス エンドポイントまたはプライベート エンドポイントを使用する必要があります。 プライベート エンドポイントに加えてオンプレミスから共有にアクセスするには、VPN または ExpressRoute 接続を設定する必要があります。 ファイアウォールのストレージ アカウントの許可リストに追加された IP は無視されます。 NFS 共有へのアクセスを設定するには、次のいずれかの方法を使用する必要があります。

  • サービス エンドポイント

    • パブリック エンドポイントによってアクセスされます。

    • 同じリージョンでのみ使用できます。

    • 共有アクセスに VNet ピアリングを使用することはできません。

    • 各仮想ネットワークまたはサブネットを許可リストに個別に追加する必要があります。

    • オンプレミス アクセスの場合は、ExpressRoute、ポイント対サイト、サイト間 VPN でサービス エンドポイントを使用できます。 プライベート エンドポイントの方が安全であるため、使用することをお勧めします。

      次の図は、パブリック エンドポイントを使用した接続を示しています。

      パブリック エンドポイント接続の図。

  • プライベート エンドポイント

    • アクセスは、サービス エンドポイントよりも安全です。

    • プライベート リンクを介した NFS 共有へのアクセスは、ストレージ アカウントの Azure リージョン (クロスリージョン、オンプレミス) の内外から利用できます。

    • プライベート エンドポイントでホストされている仮想ネットワークを使用した仮想ネットワーク ピアリングにより、ピアリングされた仮想ネットワーク内のクライアントへの NFS 共有アクセス権が付与されます。

    • プライベート エンドポイントは、ExpressRoute、ポイント対サイト VPN、およびサイト間 VPN で使用できます。

      プライベート エンドポイント接続の図。

原因 2: セキュリティで保護された転送が有効になっている

NFS Azure ファイル共有では、現在、二重暗号化はサポートされていません。 Azure では、MACSec を使用して Azure データセンター間で転送されるすべてのデータに対して暗号化レイヤーが提供されます。 NFS 共有には、信頼された仮想ネットワークと VPN トンネル経由でのみアクセスできます。 NFS 共有では、追加のトランスポート層暗号化を使用できません。

ソリューション

ストレージ アカウントの構成ブレードで [安全な転送が必要 ] を無効にします。

ストレージ アカウント構成ブレードを示すスクリーンショット。セキュリティで保護された転送を無効にする必要があります。

原因 3: nfs-utils、nfs-client、または nfs-common パッケージがインストールされていない

コマンドを実行する前に mount 、nfs-utils、nfs-client、または nfs-common パッケージをインストールします。

NFS パッケージがインストールされているかどうかをチェックするには、次を実行します。

このセクションの同じコマンドは、CentOS と Oracle Linux に適用されます。

sudo rpm -qa | grep nfs-utils

ソリューション

パッケージがインストールされていない場合は、ディストリビューション固有のコマンドを使用してパッケージをインストールします。

このセクションの同じコマンドは、CentOS と Oracle Linux に適用されます。

OS バージョン 7.X

sudo yum install nfs-utils

OS バージョン 8.X または 9.X

sudo dnf install nfs-utils

原因 4: ファイアウォールのブロック ポート 2049

NFS プロトコルは、ポート 2049 経由でサーバーと通信します。 このポートがストレージ アカウント (NFS サーバー) に対して開いていることを確認します。

ソリューション

次のコマンドを実行して、クライアントでポート 2049 が開かれていることを確認します。 ポートが開いていない場合は、ポートを開きます。

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

原因 5: ストレージ アカウントが削除されました

接続がタイムアウトしたためにファイル共有をマウントできない場合は、ファイル共有を含むストレージ アカウントが誤って削除される可能性があります。

ソリューション

ストレージ アカウントを回復します。 次に、プライベート エンドポイントを削除して再作成し、新しいストレージ アカウント リソース ID に関連付けます。

ls は、一部のカーネルで大きなディレクトリ列挙に対してハングします

原因: Linux カーネル v5.11 でバグが導入され、v5.12.5 で修正されました

一部のカーネル バージョンでは、ディレクトリの一覧が無限の READDIR シーケンスを引き起こすバグがあります。 すべてのエントリを 1 回の呼び出しで配布できる小さなディレクトリでは、この問題はありません。 このバグは Linux カーネル v5.11 で導入され、v5.12.5 で修正されました。 そのため、その間に何かがバグを持っています。 RHEL 8.4 には、このカーネル バージョンがあります。

回避策: カーネルをダウングレードまたはアップグレードする

影響を受けるカーネルの外部にカーネルをダウングレードまたはアップグレードすると、問題が解決する必要があります。

システム コマンドが "ファイルが見つかりません" エラーで失敗する

原因

inode 番号に依存する Linux 32 ビット アプリケーションは、NFS サービスによって生成された 64 ビットの inode 番号の書式設定により、Azure Filesで期待どおりに動作しない可能性があります。

ソリューション

この問題を解決するには、以下のいずれかの方法を使用します。

  • カーネル ブート オプションを使用して、64 ビットの inode 番号を 32 ビットに圧縮します nfs.enable_ino64=0 。

  • モジュール パラメーターを設定するには、/etc/modprobe.d/nfs.conf ファイルにを追加options nfs enable_ino64=0し、VM を再起動します。

このカーネル ブート オプションを grub.conf ファイルに保持することもできます。 詳細については、Linux ディストリビューションのドキュメントを参照してください。

お困りの際は、

それでも問題が解決しない場合は、 サポートにお問い合わせください 。

関連項目

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

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