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" <[email protected]>
Date: 17 avril 2009 13:15:21 HAEC
To: [email protected]
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 :
[email protected]/24:@192.168.254.0/24,[email protected]/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.
[email protected]/24,[email protected]/24
I've tried all of the following variants (and many others) with no
success :
sharenfs=on
sharenfs=rw
sharenfs=rw,anon=0
[email protected]/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,[email protected]/24:@192.168.254.0/24,[email protected]
/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.
_______________________________________________
zfs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
