Synology NAS上のNFSを使用したユーザーIDマッピング

Synology NASボックス（DSM 5.1を実行）があり、NFS経由でディレクトリをエクスポートしました。Ubuntuボックスにマウントしようとしています。

ほとんど問題なく動作しますが、ユーザーとグループのマッピングに問題があります。Ubuntuボックスでは、uid 1000（roger）、gid 1000（roger）です。Synologyでは、UID 1026（ロジャー）、グループ100（ユーザー）があります。

NFSv3を使用する場合、数値のuid / gid値を使用します。これは、所有権がSynologyで台無しになることを意味します。

同じユーザーを使用して同じUbuntuボックスからNFSマウントにのみアクセスする場合、これは問題ありませんが、CIFS（SMB）を使用してWindowsボックスからディレクトリにもアクセスします。違う。

mount -o nfsvers=4Synologyのデフォルト設定でNFSv4（）を使用するroger.usersと、Synologyが所有するファイルroger.usersは、Ubuntuボックスから表示したときに所有者として表示されます。これはいい。

ただし、touchファイルを作成する場合：

roger@ubuntu$ touch /mounts/diskstation/music/foo

それはが所有終わる1000.1000が所有しているようSynologyの上、図示nobody.4294967294のUbuntuボックスから見たとき。

Synologyフォーラムのトピックで見つけられるものはすべて、NFSv4がサポートされていなかった2011年以降のものであるか、同じ質問をしてからあきらめる人々で構成されています。

完全を期すために、以下を/etc/exports持っています：

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

...そして、私はそれをUbuntuボックスにマウントしています：

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

NFSv4 uid / gidマッピングがAUTH_UNIX（AUTH_SYS）で機能しないsec=sysのに、問題があるかもしれないというヒントを見つけましたが、解決策がありません。

この問題を回避する簡単な方法はありますか？これを解決するより複雑な（咳 Kerberos 咳）方法はありますか？

真剣に、ケルベロスが答えであるなら、私はそのヒットを取るでしょう、しかし、私はそれに多くの時間を浪費する前に知りたいです。

更新：SynologyのドキュメントではさまざまなKerberosオプションについて説明していますが、UIでそれらを見つけることができません。リリースノートの「Kerberosセキュリティ風味が...実装されている場合は、」状態。特定のモデルではない可能性があることを示唆するページを見つけました（ただし、再び見つけることはできません）。システム情報ページによると、DS211があります。たぶん私は運が悪いのですか？

NFSv4 IDマッピングが正しく機能するためには、クライアントとサーバーの両方がidmapdIDマッパーデーモンを実行しており、同じDomain設定がで行われている必要があります/etc/idmapd.conf。

このようにして、NFSクライアントroger@example.comは、ネットワーク上のNFSコマンドのようにID資格情報を送信し、NFSサーバーidmapperはそれをNFSサーバーで呼び出されたユーザーにマップしrogerます。UIDとGIDは重要ではなく、idmapperによって各システムにマッピングされます。

ただし、Synologyではそれを気にしません。私の共有フォルダには、次の権限を持っています：

• 許可
  • ローカルユーザー
    • 管理者=読み取り/書き込み
• NFSアクセス許可
  • 押しつぶす
    • すべてのユーザーを管理者にマップする

これにより、anonuid=1024,anongid=100（adminユーザーとusersグループ）が/etc/exportsNASのエクスポートに追加されます。

NFSクライアント（IDマッパーが実行されていない）はNFSコマンドをユーザー（1000:1000）として送信し、そのUIDとGIDがNASに存在しないため、UIDとGIDを変換して1024:100、完全な権限を持つ管理者ユーザー。

これは、ビジネス環境でのNFSの非常に専門的で安全でない使用方法ですが、自宅で自分のファイルにアクセスするのは、NFSの動作を悪用することです。

別のオプションはroger、NFSクライアントとNASでのUIDとGIDを同じにすることです。その後、IDマッピングなしでNFSv4を使用するか、UIDとGIDのみに依存するNFSv3を使用できます。

私はまったく同じ問題に本当に苦労してきました。SynologyでDockerを使用してKerberosサーバーを設定し、IDマッピングを設定するという大きな苦痛を経験しましたが、それでもこの動作は好きではありませんでした。Kerberosはあまりにも過剰に設計されており、再起動や自動マウントの作業を続けるのは困難です。さらに、新しく作成されたファイルのデフォルトのumaskは0000であり、ローカルumaskが何であっても、新しいファイルはすべてモード777で作成されました。

私の解決策はsuprjamiのものに似ていましたが、私はそれをもう少し取りました：

• Synology Web UIで新しいユーザーを作成し、のような名前を付けますroger.remote。ユーザーグループに対しても同じ操作を行い、ユーザー名と同じ名前を付けます。
• Synologyでルートとして/ etc / passwdを編集し、roger.remoteのUIDを1000に、GIDを1000に変更します
• / etc / groupを編集し、グループroger.remoteも1000に変更します
• Synology Web UIで、squashを「管理するすべてのユーザー」に設定して保存します
• 再度ルートとして、/ etc / exportsを編集し、UID / GIDを anonuid=1000,anongid=1000
• NFSを再起動します /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• これもちょっとハッキーですが- chmod 777 /volume1。ホームディレクトリをマウントすると、多くの奇妙な問題が発生しました。glibc access()関数は、マウントされたNFSディレクトリで拒否されたアクセスを返すため、KDEは起動しません。（ただし、サブディレクトリはすべて機能します）Firefoxにも同様の問題があり、アクセスチェックのためにマウントされたディレクトリへのファイルの保存を拒否しました。パーミッションが正しくても、マウントされたディレクトリ内のファイルをタッチ/作成/書き込みできました。親の/ volume1ディレクトリを誰でも書き込み可能に変更すると、この問題が解決され、クライアントアプリが書き込みに失敗する問題が修正されました。
• 共有からすべてのファイルシステムACLを削除します。多くのランダムな実験を通じて、これらのACLが作成されたファイルのモードマスクに問題を引き起こすことがわかりました。私はACLマスターではないので、もっとエレガントなソリューションがあるかもしれません。Synologyのルートとして、実行しますsynoacltool -del /volume1/myshare。+ls -lの出力からシンボルが削除されているはずです。
• 共有の所有権を新しいユーザーに変更します。 chown roger.remote:roger.remote /volume1/myshare
• モードを755に変更します。 chmod 755 /volume1/myshare
• クライアントにボリュームをマウントし、アクセス許可をテストします。動作するはずです！ファイルも同様にタッチし、bash umaskが正しく適用されていることを確認してください。

$ umask 
0002
$ cd / mnt / myshare
$タッチテスト
$ ls -l test
-rw-rw-r-- 1ロジャーロジャー0 Oct 21 18:15テスト

Synologyには以下が表示されます：

＃ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 Oct 21 18:15 test

楽しい！