☰

NFSマウント：所有者なし：nogroup

tag-icon • tag-icon nfs
NFSマウント：所有者なし：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

ファイルを誰もなし：グループなしとしてマークします。

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

この問題を解決して正しい所有者を表示する方法はありますか？

Ubuntu 12.04を使用してください。

編集する：

クライアント（NFSサーバーにアクセスできない）：

rpcidmapdランニング：

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

rpcinfo -p:

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

/etc/idmapd.conf:

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

答え1

ローカルサポートや文書を要求することは非常に良い考えのようです:).

リスト形式では、以下が必要だと思います。

1) クライアントシステムに必要なユーザーを作成します。これは手動で実行できますが、構成できる自動「ディレクトリサービス」が必要です。 LDAPかもしれません。

2）クライアントとサーバー間のユーザーマッピング。 NFS4から（tcpオプションで暗黙的に）Garethが述べたように、これはidmapdによって処理されます。サーバーが必要なものと一致するようにドメインを設定するだけです。クロスドメインが機能しません。これがLinuxの限界だと思います。

3) Kerberos はサーバーに対して自身を認証します (NFS4 で使用可能)。これは、「誰も」以外の人でファイルにアクセスしたい場合に必要です。まず、Kerberosを設定してテストすることをお勧めします。これを構成するには、ドメイン（idmapd.confで設定したのと同じドメイン）設定が必要です。

または、NFS3スタイル認証を使用すると、2）ではなく3）がスキップされ、ユーザーの数値UIDがサーバーの数値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"

ファイル以外のもの（たとえばldapやnisなど）にマップするように/etc/nsswitch.confを変更する場合は、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を実行すると仮定する別のチェックリスト：

  • kinitをクリックして見てくださいklist。チケットを表示する必要があります。そうでない場合は、まずKerberos認証の修正方法に関する答えを見つけてください。
  • ランニングrpc.gssd？サービスを開始したい場合があります。また、いくつかのディストリビューションでは/etc/fstab。
  • ランニングrpc.idmapd？ （つまり、これは通常、クライアントのnfsサービスによって開始されなければならず、ls /etc/init.d/良い出発点になります。
  • より/etc/idmapd.conf。 「ドメイン」部分がNFSサーバーの物理ドメインと一致していますか？ （...何も機能しない場合は、Kerberosゾーンを使用してみることができます。）これを必要としないいくつかのディストリビューションと必要なディストリビューションの中には、いくつかの点でより合理的なFQDNデフォルトがあります。
  • GSS_principal_attr = GSSAuthNameファイルにも追加されました。ドメインのみを使用すると一部の所有権の問題を解決できますが、ディレクトリなどにも必要なようです。
  • rpc.idmapd設定を調整するには、1回以上再起動してください。設定を調整した後、再インストールする必要はありませんが、悪いことはありません。
  • 返品！nfsidmap -c。明らかに、再起動後もクリアされないキャッシュがあります。 （そうでなければ、修正が機能しても機能しないと考え続けることができます。）

関連情報