web-dev-qa-db-ja.com

NFSクライアントのrootユーザーをNFSサーバーのrootユーザーにマップする方法は?

NFSを使用すると問題が発生します。そのディレクトリがNFSサーバー上に作成されている場合、NFSクライアントマシン上のディレクトリに書き込むことはできません。その理由は、ファイル/ディレクトリのアクセス許可とユーザーマッピングにあるようです。

私たちのセットアップ:

2つのEC2ノードがあります-Ubuntu16.04.2 LTS

1台のマシンにインストールされたNFSサーバー:

ubuntu@master:~$ less /etc/exports
/home/ubuntu/data *(rw,no_subtree_check,sync,insecure)

同じディレクトリが別のマシンにマウントされています。

Sudo mkdir /home/ubuntu/data
Sudo mount -t nfs masterIp:/home/ubuntu/data /home/ubuntu/data

私たちが抱えている問題:

マスターのNFSでディレクトリを作成すると、次のように作成されます。

# Sudo mkdir /home/ubuntu/data/Test
# Sudo ls -all /home/ubuntu/data
drwxr-xr-x  2 root  root       4096 Jul  5 07:19 Test

マスターはこのディレクトリへのアクセスに問題はなく、ファイルinsideeetcを作成します。しかし、Test dir内のスレーブノードからファイルを作成しようとすると、Permissiondeniedエラーが発生します。

NFSクライアントマシンからディレクトリを作成すると、次のようになります。

# Sudo mkdir /home/ubuntu/data/Test2
# Sudo ls -all /home/ubuntu/data
drwxr-xr-x  2 root  root       4096 Jul  5 07:19 Test
drwxr-xr-x  2 nobody nogroup   4096 Jul  5 07:21 Test2

したがって、NFSディレクトリに書き込むときにNFSクライアントのrootユーザーがnobody @ nogroupにマップされているため、NFSサーバー上のrootユーザーによって作成されたディレクトリに書き込むことができないようです。 NFSクリネットのrootユーザーをNFSサーバーのrootユーザーにマップして、作成した場所に関係なく、両方がディレクトリを自由に操作できるようにする必要があります。

3
MaxNevermind

no_root_squashエントリで/etc/exportsオプションを使用します。 exportsのマニュアルページから:

ユーザーIDマッピング

nfsdは、各NFS RPC要求で提供されるuidおよびgidに基づいて、サーバーマシン上のファイルへのアクセス制御を行います。ユーザーが期待する通常の動作は、通常のファイルシステムの場合と同じように、サーバー上のファイルにアクセスできることです。これには、クライアントとサーバーマシンで同じuidとgidを使用する必要があります。これは常に正しいとは限らず、常に望ましいとは限りません。

多くの場合、NFSサーバー上のファイルにアクセスするときに、クライアントマシンのrootユーザーもrootとして扱われることは望ましくありません。このため、uid 0は通常、別のID(いわゆる匿名またはnobody uid)にマップされます。この操作モード(「ルートスカッシュ」と呼ばれます)がデフォルトであり、no_root_squashでオフにできます。

5
Larssend