web-dev-qa-db-ja.com

nfsは、Linuxクライアント上のすべてのユーザーのrwnexenta共有をマウントします-失敗します

状況：

NFSファイル提供（nfs v3）にはNexentaアプライアンスを使用しています。匿名の読み取り/書き込みアクセスのパスを共有しています。

エクスポートされた読み取り/書き込み共有をマウントし、そのクライアントマシン上のマウントされた共有への匿名の読み取り/書き込みアクセスを許可するLinuxホストがあります。残念ながら、最終的に発生するのは、rootは共有に書き込むことができますが、特権のないユーザーは書き込むことができないということです。

次の方法を使用して共有をマウントします。

# mount -t nfs -o rw 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount -t nfs -o rw,users 10:10:xx:xx:/path/to/share /mnt/mounted_path
# mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -o rw

共有での匿名使用に使用する予定の特定のユーザーがいます。そこで、そのユーザーとしてボリュームをマウントしようとしました。

# su - shared_user
$ Sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw
mount.nfs: an incorrect mount option was specified

行って読んだ： http://nfs.sourceforge.net/nfs-howto/ar01s06.html 。

マウントしようとしたときに進行中のエラーが発生する次の試行を行うことにしました。

# mount -t nfs -orw,no_root_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path 
mount.nfs: an incorrect mount option was specified
# mount -t nfs -orw,nroot_squash 10:10:xx:xx:/path/to/share /mnt/mounted_path  # for grins and giggles.
mount.nfs: an incorrect mount option was specified
$ Sudo mount.nfs 10:10:xx:xx:/path/to/share /mnt/mounted_path -w -o user=shared_user,rw,no_root_squash
mount.nfs: an incorrect mount option was specified

私はただSOLですか、それともここで根本的に欠けているものがありますか？これは私が見つけようとしている聖杯ですか？私はNFSを頻繁に使用したことがないので、少しここでの損失、今。TIA！

linuxnfsreadwrite
2
Jim

OK。理解した。まず、私が使用しているNexentaのバージョンは3.1.3.5です。 Nexentaは、CIFS、NFS、Rsync、WebDAV、およびFTPを介してブロックストレージを提供するOpenSolarisベースのアプライアンスです。この例では、NFS専用に使用しています（v3がデフォルトです。v4はこのバージョンでは使用できません）。

したがって、tl; dr;ネクセンタ側：

RootとしてNexentaにログインします。

$ ssh [email protected]
Password:
Last login: Wed Aug 24 11:17:33 2016 from xx.xx.xx.xx
nmc@nex01:/$ option expert_mode = 1

nmc@nex01:/$ !bash
You are about to enter the Unix ("raw") Shell and execute low-level Unix command(s). Warning: using low-level Unix commands is not recommended! Execute?  Yes

root@nex01:/volumes#
root@nex01:/volumes# grep nfs /etc/passwd
nfs:x:60001:60001:NFS Anonymous Access User:/:/bin/sh

最初のx:#####:#####の後の数字に注意してください-これらはそれぞれuidとgidです。

クライアント側：ユーザーの作成：

# groupadd nfs -g 60001 && useradd nfs -g 60001  ## untested. I did it the long way through natural process of elimination, so be careful here.

今はすべて良いです。

ボリュームをマウントし、新しく作成したnfsユーザーがNFSボリュームに書き込めることを確認します。

ロングバージョン：

私の知る限り、NFS側を正しく設定しました。ドキュメントは役に立ちましたが、ある意味ではパンくずリストを分割するだけでした。

"この共有への匿名アクセスを許可します。共有トップレベルディレクトリには、匿名ユーザー 'nfs'の読み取り/書き込みアクセスが許可されます。再帰共有モードがtrueに設定されている場合、このプロパティは既存のサブフォルダーに伝達されます。匿名読み取りに注意してください。/writeアクセスは継承できません-明示的に要求されるまで、将来のサブフォルダーへの匿名アクセスは許可されません。匿名ユーザー名は「nfs」です。」

私のshared_userは最終的に「nfs」になりましたが、それでも失敗しました（OPを参照）。ロングショットだと思ったので、クライアント側のUIDをアプライアンスの「nfs」のUIDと一致させることにしました。アプライアンスにログインし、bashシェルを起動してから、idコマンドを実行してUID（私の場合は60001）を取得する必要がありました。

クライアントで、アプライアンスのUIDと一致するようにnfsユーザーを変更しました。どうやら、アプライアンスはこれが機能するためにそれ自身と一致するUID/GIDを必要とします。 NFSサーバーはそれを無視すると思いました。これが明らかに問題の核心でした。

現在、アプライアンスはuser：groupにnfs：nobodyを使用しています。クライアント（Linux）側のnobodyは別のUIDであり、誰のためにもUIDを変更することはもう少し複雑であり、そのグループIDを変更することによって不注意に何に影響を与えることができるかわからないので、触れないでください。クライアントマシンのnfsユーザーは、私がいじり始める前は存在していなかったので、何かを壊すリスクはありませんでした。クライアント側にはnfsnobodyがあります。私はそれを使用してテストしませんでした、そして、ドキュメントがユーザーIDに特定されているので、それが機能しなかったであろうとかなり確信しています。

また、アプライアンスが認証にsysauthを使用するように特別に設定されていることもここで述べておきます。 NFSv3はそれを好まないようであるため、auth = noneを使用することはオプションではありませんでした。 :)

それがすべてです。

2
Jim