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

NFS Azure ファイル共有への適用✔️>:

注

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

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

重要

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

常時稼働の診断ツールを使用する

Always-On Diagnostics (AOD) ツールを使用して、NFSv4 および SMB Linux クライアントのログを収集できます。 デーモンはバックグラウンドでシステム サービスとして実行され、dmesg ログ、デバッグ データ、エラー メトリック、待機時間メトリックなど、さまざまなソースの異常を検出するように構成できます。 tcpdump、nfsstat、mountstsat、およびその他のソースから、システムの CPU とメモリの使用量と共にデータをキャプチャできます。 このツールは、再現が困難なフィールドの問題に関するデバッグ情報を収集するのに役立ちます。

現在、Always-On 診断ツールは、SUSE Linux Enterprise Server 15 (SLES 15) および Red Hat Enterprise Linux 8 (RHEL 8) を実行しているシステムと互換性があります。 オペレーティング システムに対応するインストール手順に従います。

重要

Always-On 診断では、転送中の暗号化が有効になっている NFS ボリュームはサポートされていません。 影響を受ける NFS 共有でログ収集を有効にするには、EiT なしで共有をマウントする必要があります。

RHEL 8 で、次の手順に従って Always-On 診断ツールをインストールします。

  1. リポジトリ構成パッケージをダウンロードします。

    curl -ssl -O https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm

  2. リポジトリ構成パッケージをインストールします。

    sudo rpm -i packages-microsoft-prod.rpm

  3. パッケージ インデックス ファイルをインストールして更新した後、リポジトリ構成パッケージを削除します。

    rm packages-microsoft-prod.rpm
sudo dnf update

  4. パッケージをインストールします。

    sudo dnf install aod

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

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

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

原因 2: 無効な idmapping が無効なファイルまたはディレクトリ名を検出した後に再び有効になる

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 は、次の構成のストレージ アカウントでのみ使用できます。

  • 層: Premium
  • アカウントの種類: FileStorage

ソリューション

NFS ファイル共有の作成の手順に従います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • プライベート エンドポイントを、ExpressRoute、ポイント対サイト VPN、サイト間 VPN と共に使用できます。

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

原因 2: 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

原因 3: ファイアウォールによるポート 2049 のブロック

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

ソリューション

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

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

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

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

ソリューション

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

原因 5: AZNFS マウント ヘルパーの代わりに NFS クライアント マウントを使用して共有をマウントしようとしています。また、ストレージ アカウントで 、NFS の転送中に セキュリティで保護された転送が必須 または 必須の暗号化を必要とする 設定が有効になっています。

[Secure transfer required]\(セキュリティで保護された転送が必要\) 設定では、NFS 転送中の暗号化が有効になっていない限り、ストレージ アカウント内のすべてのファイル共有に対して転送中の暗号化が適用されます。この場合、Secure Transfer required は REST/HTTPS トラフィックにのみ適用されます。 NFS ファイル共有の場合、転送中に暗号化を使用するには、NFSv4.1 トラフィックのセキュリティで保護されたトンネルを確立する複雑さを抽象化するクライアント ユーティリティ パッケージである AZNFS マウント ヘルパーを使用して共有をマウントする必要があります。

ソリューション

ストレージ アカウントの [ Secure transfer required]\(安全な転送が必要な 設定\) と [ 転送中の暗号化を要求 する] 設定の両方を無効にするか、AZNFS マウント ヘルパーを使用して共有をマウントします。 詳細については、「 NFS Azure ファイル共有の転送中の暗号化を参照してください。

一部のカーネルにおいて、大きなディレクトリを列挙すると ls がハングする

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

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

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

問題を解決するには、カーネルを影響を受ける範囲外のバージョンにダウングレードまたはアップグレードします。

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

原因

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

ソリューション

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

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

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

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

ファイルとディレクトリの所有権を変更できない

原因

クライアント OS は、Azure Files サービスではなく NFS ファイル共有にアクセス許可を適用します。 NFS ファイル共有で ルート スカッシュ 設定を有効にした場合、クライアント システムのルート ユーザーはアクセス制御のために匿名 (特権なし) ユーザーになります。 この制限は、クライアント システムで root としてログインしている場合でも、 chown コマンドを使用して所有していないファイルとディレクトリの所有権を変更できないことを意味します。

ソリューション

Azure ポータルで、ファイル共有に移動し、Properties を選択します。 Root スカッシュ設定をNo Root Squashに変更します。 詳細については、Azure Files のルート スカッシュを構成するを参照してください。

[ルート スカッシュなし] を有効にすると、クライアント システムのルート ユーザーは、サーバー システムのルート ユーザーと同じ権限を持ちます。 chownを使用して、現在の所有者に関係なく、共有内の任意のファイルまたはディレクトリの所有権を変更できるようになりました。 変更を加えた後、必要に応じて Root スカッシュ を再度有効にすることができます。

ヘルプが必要ですか?

まだ支援が必要な場合は、問題を迅速に解決するために、サポートにお問い合わせください。

関連項目

サードパーティの情報に関する免責事項

この記事で説明するサードパーティ製品は、Microsoftに依存しない企業によって製造されています。 Microsoftは、これらの製品の性能または信頼性について、黙示的またはその他の方法で何の保証も行いません。

  • Last updated on