Thanks, makes sense to be able to traverse down the entire path.
New client rule added to the default policy now which is only associated with the root volume, leaving the other policy assigned to the volume to control access and surprise surprise it’s all good.
From: Tim McCarthy [mailto:tmacmd@gmail.com] Sent: 05 April 2017 11:30 To: toasters@teaparty.net; Daniel Taylor Subject: Re: NFS Export Policy
You should add a rule that allows all hosts (client match=0.0.0.0/0) ro access to the root volume and its policy.
Then add the explicit host rules to the policy for the esxi volumes.
The hosts need to be able to access all volumes and junctions down the entire path including the root.
Get Outlook for iOShttps://aka.ms/o0ukef
On Wed, Apr 5, 2017 at 6:12 AM -0400, "Daniel Taylor" <Daniel_Taylor@ajg.commailto:Daniel_Taylor@ajg.com> wrote: 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