Description of problem:
With a fresh setup, setting the volume option "nfs.rpc-auth-allow" or "nfs.rpc-auth-reject" with hostname is behaving erratically.
The behavior in my observation was as follows:
1. nfs.rpc-auth-allow "hostname" : rejects the client in the hostname from mounting via nfs.
2. nfs.rpc-auth.reject "hostname" : allows the client in the hostname to mount via nfs.
3. After enabling nfs.addr-namelookup (off by default):
nfs.rpc-auth-allow "hostname" : allows the client in the hostname to mount via nfs.
nfs.rpc-auth-reject "hostname" : rejects the client in the hostname from mounting via nfs.
4. After resetting nfs.addr-namelookup (off by default):
behavior is the same as in #3 whereas it should be same as #1 and #2
5. A restart of nfs server on all nodes also yields the same outcome as #4
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Set the volume option "nfs.rpc-auth-allow" and/or "nfs.rpc-auth-reject" with the hostname
2. Try mounting the volume on the client whose hostname is provided in the auth options
3. Set the nfs.addr-namelookup option to "on"
4. Repeat step 2
5. Reset the nfs.addr-namelookup option
6. Repeat step 1
As explained in the description.
With the nfs.addr-namelookup option off, nfs auth options do not work as intended. But with nfs.addr-namelookup option on, nfs auth options should work as expected. Although nfs.addr-namelookup option was set "on", after resetting that option, the nfs auth options should go back to not work as intended.
Providing a hostname which is different than what is used after setting the option nfs.addr-namelookup "on" and then resetting it also seems to resolve the new hostname.
Please share the RHGS-3.4.0 triage results.
(In reply to Sunil Kumar Acharya from comment #2)
> Please share the RHGS-3.4.0 triage results.
I guess this has been triaged as part of the NFS-team? Maybe Jiffin can comment on it.