NFS共有へのアクセスを単一のクライアントシステムに制限するためにSolaris 11.0サーバーを取得することはできません。
shareZFSファイルシステムのプロパティには、次のような値がありますtank/mail。
name=mail,path=/tank/mail,prot=nfs,none=*,[email protected],sec=sys
10.0.23.43 (Solaris 11.3 実行) のクライアントに共有をマウントできません。私はこれを試みます：
mount -F nfs keisha:/tank/mail /tmp/mnt
次のエラーが発生しました。
nfs mount: mount: /tmp/mnt: Permission denied
アンインストールすると、none=*クライアントが正しくインストールされます。しかし、私が理解したところによると、そうすることでクライアントへのアクセスが許可されます。どのブロックしたい住所（たとえば、住所をなりすましすることは可能ですが、すべての制限を追加することをお勧めします）
none合計の順序を逆に変更しましたが、rw何も変わりませんでした。私はそれを試しましたが、[email protected]/32それも動作しません。
サブネット全体を開こうとしましたが[email protected]/16、それ動作しません。また、お客様の住所が正しいことを再確認しました。サーバーのDNSエントリはIPv4専用で、名前でアクセスするため、クライアントはIPv6を使用してサーバーにアクセスできません。
クライアントアドレスを制限すると、特定のクライアントへのアクセスもブロックされる可能性がある理由明示的に許可住所？どうすれば解決できますか？
答え1
Ridgyのコメントは答えを示唆しています。必要なのは、削除してnone次を離れることです。
name=mail,path=/tank/mail,prot=nfs,[email protected],sec=sys
（省略することもありますが、@文書上要求するため、今後の解釈がより制限的になる場合を備えて保管しておくのが最善だと思います。）
これは文書が不十分な場合です。マニュアルページには次のように指定されています（強調）。
none
すべてのクライアントアクセスは禁止されています。roまたは、オプションをrwオーバーライドすることもできますnone。
none=access_list は、
アクセスリストと一致するクライアントへのアクセスを許可しません。 ただし、アクセスリストがアスタリスク（*）の場合は例外です。この場合はオーバーライドroできます。rwnone
これは、10.0.23.43にある私のクライアントがアクセス権を得なければならないことを非常に明確にするだけでなく、none（そうでなかったにもかかわらず）実際にあなたがアクセス権を得たことを意味します。必要 nonerwリストにないクライアントが少なくとも何らかのアクセス権を取得できないようにするには、none=*適用範囲例外が（おそらく）実装されるのはなぜですか？ これは重複しています！
テストする他のNFSクライアントがないので、クライアントのIP番号を変更し、それがnone正しいことを確認しました。いいえこれは、他にリストされていないクライアントへのアクセスを拒否するために必要です。確認するためにroテストを追加しましたが、別のアドレスにあるクライアントは読み取ることはできますが、書き込めませんでした。
これが解決策のように見えますが、文書には私がやっていることが開放的であることを示唆しているので満足できません。実際、暗黙の意図に固執するために、将来のリリースでこれを行うことによってそれ自体を修正することができます。文書として。 （少なくとも外部ファイアウォールがあります。）
答え2
1つのホストにのみ共有されている場合、Ridgyはあなたの質問に答えたようです。複数の場合は、セミコロンを使用するか、ネットグループを作成できます。
追加のブロックが必要な場合、または必要に応じて、OpenBSD PF（pkg：/ network / firewall）のipfiltersまたはSolarisファイアウォールの使用を検討してください。