☰

NFS のマウント: 所有者は nobody:nogroup です

tag-icon • tag-icon nfs
NFS のマウント: 所有者は nobody:nogroup です

次のコードを使用して、シェルから NFS ファイルシステムをマウントしました。

LINE='nfs.mit.edu:/export/evodesign/beatdb /beatdb nfs tcp,intr,rw 0 0'
grep "$LINE" /etc/fstab >/dev/null || echo $LINE >> /etc/fstab
mkdir /beatdb
mount -a # Remount /etc/fstab Without Reboot in Linux

ファイルをnobody:nogroupとして表示します:

ここに画像の説明を入力してください

この問題を修正して正しい所有者を表示するアイデアはありますか?

私はUbuntu 12.04を使用しています。

編集：

クライアント側 (NFS サーバーにアクセスできません):

rpcidmapdが走っています：

ここに画像の説明を入力してください

rpcinfo -p:

ここに画像の説明を入力してください

/etc/idmapd.conf:

ここに画像の説明を入力してください

答え1

ローカル サポートまたはドキュメントを要求することは、非常に良いアイデアのように思えます :)。

チェックリスト形式では、

1) クライアント システムで必要なユーザーを作成します。これは手動で行うことができますが、構成できる自動「ディレクトリ サービス」が存在することを期待する必要があります。LDAP が考えられます。

2) クライアントとサーバー間のユーザーマッピング。NFS4では(tcp オプションによって暗示される)これは、gareth が述べたように、idmapd によって処理されます。サーバーが考えるドメインと一致するようにドメインを設定する必要があります。クロスドメインは機能しません。これは Linux の制限だと思います。

3) サーバーに自分自身を認証するための Kerberos (NFS4 で利用可能)。"nobody" 以外のユーザーとしてファイルにアクセスする場合は、これが絶対に必要です。まずは Kerberos を設定してテストすることをお勧めします。設定にはドメインの設定が含まれます。idmapd.conf で同じドメインを設定します。

または、NFS3 スタイルの認証では、3) はスキップされ、2) の代わりに、ユーザーの数値 UID がサーバーのものと一致することを確認するだけです。これは、サーバーがクライアントを信頼する場合にのみ使用されます :)。

答え2

同様の問題を追跡しました。/etc/idmapd.conf Verbosity=3 を設定すると、Ubuntu 上のいくつかの問題を確認できましたが、すべてではありませんでした。以下は、私の調査結果の要約です。

/etc/passwd およびグループ ファイルが、共有を提供するマシンと同じユーザー/グループを共有しない可能性がまだあります。ヒント: ローカル マシンには、/etc/nsswitch.conf を介して同様のユーザー/グループ名マッピングが必要です。そうしないと、idmapd のマッピング操作が失敗します。ここで、Verbosity=3 を実行すると、/var/log/syslog に次のようなエントリが表示されることに注意してください。

idmapd[25193]: クライアント64: (グループ) 名前 "TheGroupNameYouExpected" -> ID "65534

/etc/nsswitch.conf を変更してファイル以外のもの (ldap や nis など) にマップする場合は、ldap または nis に ID 変換するユーザー名またはグループ名のエントリが実際にあることも確認する必要があります。エントリが存在しない場合、idmapd はユーザー/グループを正常にマップできません。

RHEL v7 で見つかった関連する問題では、NFS クライアントに対して idmapd.conf サービスを有効にする必要がなくなりました。

https://bugzilla.redhat.com/show_bug.cgi?id=1033708#c2

ただし、上記のスレッドでは、自動 ID ユーザー名マッピングを実行するサービスでは、デフォルトでメモリ内にマップされたままの ID の数が非常に少ないという問題が進行中です。エラーをログに記録する代わりに、idmapd は 200 を超えるユーザーの変換を拒否します。これは、現在のカーネル設定から確認できます。

cat /proc/sys/kernel/keys/root_maxkeys

おそらく 200 がデフォルト設定です。NFS マウント ポイントが利用可能なすべてのユーザーを適切にマップできるようにするには、このファイルを変更する必要があります。

/etc/sysctl.conf

次のようにこれらの行を追加または変更します。

# To ensure we can map all the possible NFS users
kernel.keys.root_maxkeys=65000
kernel.keys.root_maxbytes=1300000
kernel.keys.maxkeys=65000
kernel.keys.maxbytes=1300000

システムではそれほど多くのユーザー/ID キー マッピングが必要ない場合がありますので、必要に応じて調整してください。これにより、NFS マウントを使用している間、すべての ID-名前キーがマップされたままになります。現在のカーネル設定を示す別の関連投稿を次に示します。

https://bugzilla.redhat.com/show_bug.cgi?id=876705#c20

これらの値の場合:

cat /proc/sys/kernel/keys/root_maxkeys
cat /proc/sys/kernel/keys/root_maxbytes
cat /proc/sys/kernel/keys/maxkeys
cat /proc/sys/kernel/keys/maxbytes

おそらく、maxbytes と root_maxbytes はすべてのキーを格納するのに十分な大きさである必要があります。

https://www.kernel.org/doc/Documentation/security/keys.txt

答え3

Kerberos を使用して NFSv4 を実行していることを前提とした、もう 1 つのチェックリスト:

  • kinitを参照してくださいklist。チケットが表示されるはずです。表示されない場合は、まず Kerberos 認証を修正する方法に関する回答を探してください。
  • はrpc.gssd実行されていますか? サービスを開始することをお勧めします。また、一部のディストリビューションでは、 のオプションで krb5* を使用して NFS マウントを指定しない限り、自動的に開始されません/etc/fstab。
  • 実行されていますかrpc.idmapd? (繰り返しますが、これは通常、クライアント側の NFS サービスによって起動されるはずであり、ls /etc/init.d/良い出発点となります。
  • を見てください/etc/idmapd.conf。「ドメイン」の部分は、NFS サーバーの実際のドメインと一致していますか? (... 他に何もない場合は、Kerberos レルムを使用してみてください。) これが必要なディストリビューションもあれば、必要なディストリビューションもありました。おそらく、一部のディストリビューションでは、FQDN のより適切なデフォルトが設定されているのでしょう。
  • GSS_principal_attr = GSSAuthNameファイルにも追加します。ドメインだけで所有権の問題がいくつか解決されるかもしれませんが、たとえばディレクトリにもこれが必要なようです。
  • 設定を調整して少なくともrpc.idmapd1 回再起動します。設定を調整した後は再マウントする必要はありませんが、再マウントしても問題ありません。
  • また！nfsidmap -cどうやら、再起動してもクリアされないキャッシュがあるようです。これでクリアされます。（そうしないと、修正が機能したとしても機能しないと考え続ける可能性があります。）

関連情報