Hi there,
I''m working on a new OS 2008.11 setup here and running into a few
issues with the nfs integration. Notably, it appears that subnet
values attributed to sharenfs are ignored and gives back a permission
denied for all connection attempts. I have another environment where
permission is assigned by FQDN which works fine, but I don''t want to
have to manage individual connections for server farms.
Currently the server is running in a dedicated subnet
(192.168.100.0/24) and the machines that will require access are
running in two other subnets (192.168.0.0/24 & 192.168.254.0/24-ESX).
The client machines are ESX Server, Mac OS X, & Linux. From what
I''ve
been able to gather, I should be able to set specific permissions in
CIDR syntax with the @ prefix) in the sharenfs value. I''ve tried a
dozen different variants with no success.
The one that I think should work is :
sharenfs=rw=@192.168.0.0/24:@192.168.254.0/24,root=@192.168.254.0/24
giving access to the client machines as well as giving root access to
the ESX servers. Every connection attempt returns permission denied
to the client. Trying with just a single subnet returns the same error.
sharenfs=rw=@192.168.254.0/24,root=@192.168.254.0/24
I''ve tried all of the following variants (and many others) with no
success :
sharenfs=on
sharenfs=rw
sharenfs=rw,anon=0
sharenfs=rw=@192.168.0.0/16
I did check tp make sure that the nfs server is running, :-)
Everything looks fine from the sharemgr perspective:
sharemgr show -vx zfs
<?xml version="1.0"?>
<sharecfg>
<group name="zfs" state="enabled"
zfs="true">
<group name="n01p01/nfs01" state="enabled"
zfs="true"
changed="true">
<optionset type="nfs"/>
<security type="nfs" sectype="sys">
<option type="rw"
value="@192.168.0.0/24:@192.168.254.0/24"/>
<option type="root"
value="@192.168.254.0/24"/>
</security>
<share path="/n01p01/nfs01" type="transient"
shared="true"
shareopts-nfs="sec=sys,rw=@192.168.0.0/24:@192.168.254.0/24,root=@192.168.254.0
/24"/>
</group>
</group>
</sharecfg>
From the client side of the house it looks fine:
showmount -e 192.168.100.113
Exports list on 192.168.100.113:
/n01p01/nfs01 @192.168.254.0/24 @192.168.0.0/24
Time to file a bug report? Or is there already one for this issue?
Searching "nfs subnet" on defect.opensolaris.org returns nothing.
Any ideas appreciated,
Cheers,
Erik
On Fri, Apr 17, 2009 at 6:15 AM, erik.ableson <eableson at mac.com> wrote:> Hi there, > > I''m working on a new OS 2008.11 setup here and running into a few issues > with the nfs integration. Notably, it appears that subnet values attributed > to sharenfs are ignored and gives back a permission denied for all > connection attempts. I have another environment where permission is assigned > by FQDN which works fine, but I don''t want to have to manage individual > connections for server farms. > > Currently the server is running in a dedicated subnet (192.168.100.0/24) > and the machines that will require access are running in two other subnets ( > 192.168.0.0/24 & 192.168.254.0/24-ESX). The client machines are ESX > Server, Mac OS X, & Linux. From what I''ve been able to gather, I should be > able to set specific permissions in CIDR syntax with the @ prefix) in the > sharenfs value. I''ve tried a dozen different variants with no success. > > The one that I think should work is : > > sharenfs=rw=@192.168.0.0/24:@192.168.254.0/24,root=@192.168.254.0/24 > > giving access to the client machines as well as giving root access to the > ESX servers. Every connection attempt returns permission denied to the > client. Trying with just a single subnet returns the same error. > > sharenfs=rw=@192.168.254.0/24,root=@192.168.254.0/24 > > I''ve tried all of the following variants (and many others) with no success > : > > sharenfs=on > sharenfs=rw > sharenfs=rw,anon=0 > sharenfs=rw=@192.168.0.0/16 > > I did check tp make sure that the nfs server is running, :-) > > Everything looks fine from the sharemgr perspective: > sharemgr show -vx zfs > <?xml version="1.0"?> > <sharecfg> > <group name="zfs" state="enabled" zfs="true"> > <group name="n01p01/nfs01" state="enabled" zfs="true" changed="true"> > <optionset type="nfs"/> > <security type="nfs" sectype="sys"> > <option type="rw" value="@192.168.0.0/24:@192.168.254.0/24"/> > <option type="root" value="@192.168.254.0/24"/> > </security> > <share path="/n01p01/nfs01" type="transient" shared="true" > shareopts-nfs="sec=sys,rw=@ > 192.168.0.0/24:@192.168.254.0/24,root=@192.168.254.0/24"/> > </group> > </group> > </sharecfg> > > From the client side of the house it looks fine: > showmount -e 192.168.100.113 > Exports list on 192.168.100.113: > /n01p01/nfs01 @192.168.254.0/24 @192.168.0.0/24 > > Time to file a bug report? Or is there already one for this issue? > Searching "nfs subnet" on defect.opensolaris.org returns nothing. > > Any ideas appreciated, > > Cheers, > > Erik >Looking at the docs, I believe you have the syntax wrong. It should be either @192.168.254 or @192.168.254/24. Then again, I''m no subnetting genius so I could be completely wrong ;) --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090417/19a01c36/attachment.html>
Crossposted since I think there may be zfs folks that are new to using the direct integration with nfs and may be confounded as I was. The problem as outlined exists as long as the client machine is not referenced in any kind of name resolution service. It turns out that if I can do a reverse lookup from the DNS server for the client IP address nfs connections are permitted, or if the IP address is listed in /etc/hosts. it doesn''t matter what name you give it, just that the address resolves to a name and it will permit access. Can anyone explain this behaviour? It''s manageable as long as you know this is the case, but it strikes me as a non obvious dependency since the subnet declaration should be sufficient to permit access (or at least it would appear to be the case from reading the documentation). Cheers, Erik Begin forwarded message:> From: "erik.ableson" <eableson at mac.com> > Date: 17 avril 2009 13:15:21 HAEC > To: zfs-discuss at opensolaris.org > Subject: [zfs-discuss] sharenfs settings ignored > > Hi there, > > I''m working on a new OS 2008.11 setup here and running into a few > issues with the nfs integration. Notably, it appears that subnet > values attributed to sharenfs are ignored and gives back a > permission denied for all connection attempts. I have another > environment where permission is assigned by FQDN which works fine, > but I don''t want to have to manage individual connections for server > farms. > > Currently the server is running in a dedicated subnet > (192.168.100.0/24) and the machines that will require access are > running in two other subnets (192.168.0.0/24 & 192.168.254.0/24- > ESX). The client machines are ESX Server, Mac OS X, & Linux. From > what I''ve been able to gather, I should be able to set specific > permissions in CIDR syntax with the @ prefix) in the sharenfs > value. I''ve tried a dozen different variants with no success. > > The one that I think should work is : > > sharenfs=rw=@192.168.0.0/24:@192.168.254.0/24,root=@192.168.254.0/24 > > giving access to the client machines as well as giving root access > to the ESX servers. Every connection attempt returns permission > denied to the client. Trying with just a single subnet returns the > same error. > > sharenfs=rw=@192.168.254.0/24,root=@192.168.254.0/24 > > I''ve tried all of the following variants (and many others) with no > success : > > sharenfs=on > sharenfs=rw > sharenfs=rw,anon=0 > sharenfs=rw=@192.168.0.0/16 > > I did check tp make sure that the nfs server is running, :-) > > Everything looks fine from the sharemgr perspective: > sharemgr show -vx zfs > <?xml version="1.0"?> > <sharecfg> > <group name="zfs" state="enabled" zfs="true"> > <group name="n01p01/nfs01" state="enabled" zfs="true" > changed="true"> > <optionset type="nfs"/> > <security type="nfs" sectype="sys"> > <option type="rw" value="@192.168.0.0/24:@192.168.254.0/24"/> > <option type="root" value="@192.168.254.0/24"/> > </security> > <share path="/n01p01/nfs01" type="transient" shared="true" > shareopts-nfs="sec=sys,rw=@192.168.0.0/24:@192.168.254.0/24,root=@192.168.254.0 > /24"/> > </group> > </group> > </sharecfg> > > From the client side of the house it looks fine: > showmount -e 192.168.100.113 > Exports list on 192.168.100.113: > /n01p01/nfs01 @192.168.254.0/24 @192.168.0.0/24 > > Time to file a bug report? Or is there already one for this issue? > Searching "nfs subnet" on defect.opensolaris.org returns nothing.-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090420/d891c8af/attachment.html>