ONTAP Discussions
ONTAP Discussions
I've managed NFS from 7-mode for a while now, and have recently started getting into Cluster Mode as well. Unfortunately the transition has been a little rocky, in that CDOT seems to do some things very differently than 7-mode with respect to NFS. I'm trying to get good general information, as well as an understanding of how to configure NFS on CDOT.
Our problems originated when we configured an NFS export for a subnet containing a few RHEL systems. We are not using kerberos or NIS. The hosts would only be attempting access as root, so we used system manager and configured the subnet 192.168.10.128/25. We configured no ReadOnly access, Unix (sys) for RW access, and Unix (sys) for root access. When a host attempted to mount this, they got Permission denied by the server. All the general troubleshooting checks came up clean...we checked to make sure it was coming across as the correct IP, rpcinfo was fine, etc.
All our vservers configured for NFS access only have GID 0 (root) and UID 0 (root) configured.
I attempted to track down the equivalent option of nfs.mountd.trace from 7-mode in CDOT but couldn't find it anywhere. I did find the diag secd trace options, but this is tracing for file access, not host mount access. If anyone knows if this is possible and where it is, I would be very appreciative.
My questions, in no particular order:
I have read through the NFS on ClusterMode whitepaper along with a couple of other resources on how NFS authentication is supposed to function. What I'm seeing on this system doesn't jive with what I'm understanding is "supposed" to be happening.
Default security flavor used by Linux is AUTH_SYS and your error message is related to access to exported resource, not to UID - it is not yet as far as to compare UID. Assuming you checked allowed IP addresses, common cases are incorrect path to mount or NFS v3 vs. NFS v4 (recent Linux versions default to NFS v4).
Can’t give more specific answers about cDOT, sorry.
Thanks, that is what I thought. Turns out the issue was actually related to my question #5. At least in cDot (on our version 8.1.2P2) you are required to give ReadOnly access on an export policy even if access will be RW. So a policy that is RO=never, RW=host, root=Host would not allow that host to mount the export. I'm wondering if this is expected behavior or not...if it is, then the options should probably be called Read, Write instead of ReadOnly, ReadWrite.
At least in 7-mode the only time I would explicitly state ro= is if I was wanting to keep a host to ReadOnly.
And to my #6, None was not required. Once we set ReadOnly to Unix (sys) the export worked fine.
This could be related the below bug
http://support.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=429128
Balaji
8.3RC1 seems to require -rorule to be set to somthing other than none before a linux client can mount. Mac OS X client (Yosemite) seems to be able to mount either way.