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:
On a general linux system (RHEL, CentOS, etc.) when an export is mounted and accessed as root, will the authentication be seen as AUTH_SYS (Unix, sys) or AUTH_NONE (anonymous, none)? I was under the impression that it would be AUTH_SYS using UID 0 (with the understanding that root access is not allowed by default and is instead "converted" to anonymous access unless the root= directive is used).
On an ESX system when an export is mounted and accessed as root, will the authentication be seen as AUTH_SYS (Unix, sys) or AUTH_NONE (anonymous, none)? I was under the impression that it would be AUTH_SYS using UID 0 (with the understanding that root access is not allowed by default and is instead "converted" to anonymous access unless the root= directive is used).
Assuming that either of the previous cases are AUTH_NONE, we would need to configure anon=0 in order to allow them access. However if they both use AUTH_SYS (which my understanding is that they do), they should be coming across as UID 0, and if root access is allowed via sys there should be no UID conversion going on...yes/no? This is confusing because during the course of troubleshooting my problem, a different vserver with NFS access from ESX is showing this issue https://kb.netapp.com/support/index?page=content&id=2017005 but we have root access enabled.
If the output from a server on attempting to mount an NFS export is "Permission denied" does this always mean that there is a problem with the IP addresses allowed list? Or can it also be a problem with access credentials? (mount: 192.168.10.253:/ftp failed, reason given by server: Permission denied)
In CDOT, when configuring an export that will be used only for RW, is it necessary to allow RO access also even though it won't be used?
In CDOT, when configuring an export that will be used by root from an ESX or Linux host, is it necessary to include "None" along with "Unix" in the rw/root permissions?
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.