web-dev-qa-db-ja.com

NFSクライアントでrootユーザーによって作成されたファイルの所有者がクライアントで「nobody：nogroup」ではなく「root：root」として表示されるようにNFSv4マウントを構成するにはどうすればよいですか？

NextcloudスナップがインストールされているUbuntu16.04サーバー（_nextcloud.lan_）と、NFSv4経由でファイルを提供するように構成されたUbuntu 16.04 NAS）があります（_nas.lan_）。 NASからエクスポートされたNFSディレクトリを介してnextcloud.lanにディレクトリ_/var/snap/nextcloud_をマウントし、Nextcloudが使用するすべてのファイルがNASに保存されるようにします。

NASのNFS認証はデフォルトのAUTH_SYS/AUTH_UNIXとして構成されています。nas.lanの次の構成ファイルを参照してください。

_/etc/idmap.conf_：

_[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = localdomain
_

_/etc/exports_：

/vol0/export 192.168.2.0/24(rw,fsid=0,insecure,no_subtree_check,async) /vol0/export/nextcloud 192.168.2.0/24(rw,nohide,insecure,no_subtree_check,async,no_root_squash)

そして_nextcloud.lan_の場合：

_/etc/fstab_：

_nas:/nextcloud /mnt nfs auto 0 0_

_/etc/idmap.conf_：

_[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = localdomain
_

現在、nas.lanとnextcloud.lanの両方に存在するuidを持つユーザーが、nextcloud.lanのマウントされたディレクトリにファイル（ユーザー名jacob、uid 1000など）を作成すると、ファイルは両方のシステムの適切な所有者で作成されます（例：jacob：jacob）。

ただし、rootユーザーがnextcloud.lanのエクスポートされたディレクトリにファイルを作成すると、ファイルは両方のシステムで「nobody：nogroup」によって所有されているように見えます。 Nextcloudスナップはrootユーザーとしてのみ実行できるので、私の質問は、NFSクライアントnextcloud.lanでrootユーザーによって作成されたファイルが「root：root」として表示されるようにするにはどうすればよいですか？ 'nobody：nogroup'？

NFSはrootユーザーのアクセス許可に関して特別な処理を行い、セキュリティ上の理由からシステム間でrootユーザーIDをマップしないことを読みました。これを無効にする方法があるかどうか疑問に思っていますか？

_no_root_squash_というオプションが1つあるのを見ましたが、これはうまくいきませんでした。

Nextcloud.localの_/etc/idmapd.conf_で以下を設定しようとしましたが、これもうまくいきませんでした：

_[Mapping]
Nobody-User=root
Nobody-Group=root
_

これまでのところ、nextcloud.lanシステムでnobody：nogroupをroot：rootにマップするために考えられるすべてのことを試みましたが、成功しませんでした。

これを行う方法について誰もが共有できる洞察をいただければ幸いです。ご協力ありがとうございました。

ubuntunfsnfs4
1
jbeard4

エクスポートファイルに重複する2つのエントリがあります。

/vol0/export           192.168.2.0/24(rw,fsid=0,insecure,no_subtree_check,async)
/vol0/export/nextcloud 192.168.2.0/24(rw,nohide,insecure,no_subtree_check,async,no_root_squash)

サブネット192.168.2.0/24内のすべてのクライアントは、最初のエントリを使用する可能性があり（おそらく使用します）、最終的にrootをユーザーnobodyにマッピングします。 IP範囲を絞り込んでみてください。

/vol0/export  192.168.2.0/24(rw,fsid=0,insecure,no_subtree_check,async) 192.168.2.1(rw,nohide,insecure,no_subtree_check,async,no_root_squash)

ここで、192.168.2.1はnextcloud.lanのIPアドレスに割り当てられています。

1
kofemann

/ etc/exportsに次の変更を加えることで、これを実現できました。

/vol0/export           192.168.2.0/24(rw,fsid=0,insecure,no_subtree_check,async,no_root_squash)
/vol0/export/nextcloud 192.168.2.0/24(rw,nohide,insecure,no_subtree_check,async,no_root_squash)

その後、NFS経由で/ var/snap/nextcloudをNASのエクスポートされたディレクトリにマウントすることができ、すべてがうまく機能しているようです。

しかし、私は@AndrewHenleに同意します-このアプローチは危険で安全ではないようです。nextcloud.lanシステムのrootユーザーをnas.lanシステムの非rootユーザーにマッピングするアプローチを見つける方が良いでしょう。残念ながら、現時点ではnextcloudスナップをrootとして実行する必要があります。私はこれを別の質問に生み出すかもしれません。

1
jbeard4