次の方法で共有

Azure NetApp Files 用に NFSv4.1 ID ドメインを構成する

  • [アーティクル]

NFSv4 では、ID 認証ドメインの概念が導入されています。 Azure NetApp Files では、認証ドメインとしてエントリ値 defaultv4iddomain.com が使用され、NFS クライアントは独自の構成を使用して、それらのボリューム上のファイルにアクセスするユーザーを認証します。 既定では、NFS クライアントは NFSv4 ID ドメインとして DNS ドメイン名を使用します。 この設定は、idmapd.conf という名前の NFSv4 構成ファイルを使用してオーバーライドできます。

NFS クライアントと Azure NetApp Files の認証ドメイン設定が一致しない場合、NFSv4 ユーザーとグループのマッピングが失敗する可能性があるため、ファイル アクセスが拒否される可能性があります。 この場合、適切に一致しないユーザーとグループは、idmapd.conf ファイルで構成されたユーザーとグループをスカッシュし (一般に、nobody:99)、クライアントにイベントが記録されます。

この記事では、ユーザー/グループ マッピングの既定の動作と、適切に認証してアクセスを許可するように NFS クライアントを正しく構成する方法について説明します。 

ユーザー/グループ マッピングの既定の動作

ルート ユーザー マッピングは、Azure NetApp Files と NFS クライアントの間に不一致がある場合の動作を示すことができます。 アプリケーションのインストール プロセスでは、多くの場合、ルート ユーザーを使用する必要があります。 Azure NetApp Files は、root へのアクセスを許可するように構成できます。

次のディレクトリ一覧の例では、ユーザー root が、ID 認証ドメインの既定の構成 localdomain を使用する Linux クライアントにボリュームをマウントします。これは、defaultv4iddomain.com の Azure NetApp Files の既定の構成とは異なります。

ファイル ディレクトリの出力のスクリーンショット。

ディレクトリ内のファイルの一覧で、file1 はルート ユーザーが所有する必要がある場合に、nobody にマップされていることを示します。

両方の側で認証ドメインを調整するには、NFS サーバーとして Azure NetApp Files を使用する方法と、NFS クライアントとして Linux を使用する 2 つの方法があります。

  1. 中央ユーザー管理: Active Directory Domain Services (AD DS) などの中央ユーザー管理を既に使用している場合は、LDAP を使用するように Linux クライアントを構成し、AD DS で構成されたドメインを認証ドメインとして設定できます。 サーバー側で、Azure NetApp Files の AD ドメイン サービスを有効にして、LDAP 対応ボリュームを作成する必要があります。 LDAP 対応ボリュームは、AD DS で構成されたドメインを認証ドメインとして自動的に使用します。

    このプロセスの詳細については、「NFS ボリュームの Active Directory Domain Services (AD DS) LDAP 認証を有効にする」を参照してください。

  2. Linux クライアントを手動で構成する: Linux クライアントに対して中央ユーザー管理を使用していない場合は、LDAP 対応でないボリュームの Azure NetApp Files の既定の認証ドメインと一致するように Linux クライアントを手動で構成できます。

このセクションでは、Linux クライアントを構成する方法と、LDAP 非対応のすべてのボリュームの Azure NetApp Files 認証ドメインを変更する方法について説明します。

Azure NetApp Files で NFSv4.1 ID ドメインを構成する

Azure portal を使用して、LDAP 以外のすべてのボリュームに必要な NFSv4.1 ID ドメインを指定できます。 この設定は、同じサブスクリプションとリージョン内のすべての NetApp アカウントのすべての LDAP 以外のボリュームに適用されます。 同じ NetApp サブスクリプションとリージョン内の LDAP 対応ボリュームには影響しません。

機能を登録する

Azure NetApp Files では、Azure portal を使用して、サブスクリプション内のすべての LDAP 以外のボリュームに NFSv4.1 ID ドメインを設定する機能がサポートされています。 現在、この機能はプレビュー段階にあります。 初めて使用する前に、機能を登録する必要があります。 登録が完了すると、機能が有効になり、バックグラウンドで動作します。

  1. 機能を登録する

    Register-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

  2. 機能の登録の状態を確認します。

    Note

    RegistrationState が Registering 状態から Registered に変化するまでに最大 60 分間かかる場合があります。 この状態が Registered になってから続行してください。

    Get-AzProviderFeature -ProviderNamespace Microsoft.NetApp -FeatureName ANFNFSV4IDDomain

また、Azure CLI のコマンド az feature register と az feature show を使用して、機能を登録し、登録状態を表示することもできます。

手順

  1. Azure NetApp Files サブスクリプションで、NFSv4.1 ID ドメインを選択します。

  2. [構成] をクリックします。

  3. 既定のドメイン defaultv4iddomain.com を使用するには、[既定の NFSv4 ID ドメインを使用] の横にあるボックスを選択します。 別のドメインを使用するには、テキスト ボックスをオフにし、NFSv4.1 ID ドメインの名前を指定します。

    NFSv4 ドメインを設定するフィールドを含むスクリーンショット。

  4. [保存] を選択します。

NFS クライアントで NFSv4.1 ID ドメインを構成する

  1. NFS クライアントで /etc/idmapd.conf ファイルを編集します。
    行 #Domain をコメント解除し (つまり、行から # を削除する)、値 localdomain を次のように変更します。

    • ボリュームが LDAP に対して有効になっていない場合は、Domain = defaultv4iddomain.com を指定して既定のドメイン defaultv4iddomain.com を使用するか、Azure NetApp Files で構成されている NFSv4.1 ID ドメインを指定します。
    • ボリュームで LDAP が有効になっている場合は、Domain を NetApp アカウントの Active Directory 接続で構成されているドメインに設定します。 たとえば、contoso.com が NetApp アカウントで構成されているドメインの場合は、Domain = contoso.com を設定します。

    次の例は、変更前の /etc/idmapd.conf の初期構成を示しています。

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
# Domain = localdomain 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    次の例は、既定のドメイン defaultv4iddomain.com の LDAP 以外の NFSv4.1 ボリュームの更新された構成を示しています。

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = defaultv4iddomain.com 

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

    次の例は、LDAP 対応の NFSv4.1 ボリュームの更新された構成を示しています。 この例では、contoso.com は NetApp アカウントで構成されているドメインです。

    [General]
Verbosity = O 
Pipefs—Directory = /run/rpc_pipefs 
# set your own domain here, if it differs from FQDN minus hostname 
Domain = contoso.com

[Mapping] 
Nobody-User = nobody 
Nobody-Group = nogroup

  2. 現在マウントされている NFS ボリュームをマウント解除します。

  3. /etc/idmapd.conf ファイルを更新します。

  4. NFS idmapper (nfsidmap -c) のキーリングをクリアします。

  5. 必要に応じて NFS ボリュームをマウントします。

    「Windows または Linux の VM のボリュームをマウントする」を参照してください。

次の例は、結果として得られるユーザー/グループの変更を示しています。

結果として発生するユーザー/グループの変更の例を示すスクリーンショット。

この例に示すように、ユーザー/グループは nobody から root に変更されました。

他の (ルート以外の) ユーザーとグループの動作

Azure NetApp Files では、ローカル ユーザーとグループ (NFS クライアントでローカルに作成され、ユーザー ID とグループ ID で表されます) と、NFSv4.1 ボリューム内のファイルまたはフォルダーに関連付けられている対応する所有権とアクセス許可がサポートされます。 ただし、NFS クライアント間でローカル ユーザーとグループをマッピングする場合、サービスは自動的に解決されません。 1 つのホストで作成されたユーザーとグループは、別の NFS クライアントに存在する場合と存在しない場合があり (または異なるユーザー ID とグループ ID を持つ場合)、以下の例で説明するように正しくマップされません。

次の例では、Host1 には 3 つのユーザー アカウント (testuser01、testuser02、testuser03) があります。

Host1 に既存のテスト ユーザー アカウントが 3 つあることを示すスクリーンショット。

Host2では、対応するユーザー アカウントは存在しませんが、同じボリュームが両方のホストにマウントされます。

NFSv4.1 の結果の構成

この問題を解決するには、NFS クライアントで不足しているアカウントを作成するか、Azure NetApp Files が一元管理された UNIX ID に使用している LDAP サーバーを使用するように NFS クライアントを構成します。

次のステップ