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

  • [アーティクル]

Note

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

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

重要

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

適用対象

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

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 を実行している場合は、不適切なディレクトリまたはファイル名を持たないディレクトリから、 —numeric-ids 引数を指定して rsync を実行します。

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 では、Azure データセンター間で転送中のすべてのデータに対して、MACSec を使用した暗号化レイヤーが提供されます。 信頼された仮想ネットワークから、および VPN トンネル経由でのみ NFS 共有にアクセスできます。 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 kernel v5.11 で確認され、v5.12.5 で修正されました。 したがって、その間のバージョンにはこのバグが存在します。 RHEL 8.4 にはこのカーネル バージョンが含まれています。

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

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

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

原因

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

解決策

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

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

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

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

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

原因

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

解決策

Azure portal でファイル共有に移動し、 Properties を選択します。 Root スカッシュ設定を ルート スカッシュに変更します。

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

ヘルプが必要ですか?

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

関連項目

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

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