Hey,
here's what I always do for new SVMs:
Add this rule to the default policy and only have this rule in it:
vserver export-policy rule create -vserver SVMNAME -policyname default -clientmatch 0/0 -rorule none -rwrule never -protocol nfs -anon 65535 -allow-suid true -superuser none -allow-dev true
Add a new policy for the volume in question:
vserver export-policy create -vserver SVMNAME -policyname POLICYNAME
Add rules for each client which should have access to this volume:
vserver export-policy rule create -vserver SVMNAME -policyname POLICYNAME -protocol nfs -rorule any -rwrule any -superuser any -anon 0 -clientmatch CLIENTIPMASK
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Im Auftrag von Daniel Taylor Gesendet: Mittwoch, 5. April 2017 12:08 An: toasters@teaparty.net Betreff: NFS Export Policy
Hello,
We have an volume with an export policy applied:
volA = policy1
The policy has client match rules for the ESXi hosts.
However when we try and add this volume to an ESXi host we get an error saying mount request denied.
If we add a rule to the default export policy within the same SVM the volume is then added without issue.
Similarly if we apply 'policy1' to the root volume in the associated SVM we are able to mount 'volA' on the ESXi hosts.
Doesn't this kind of defeat the object of having an export policy associated with the volume if the underlying root volume controls the export access? Or is this a bug?
We are running 9.1P1.
Thanks