Red Hat Bugzilla – Bug 966659
hostname based nfs mounts fail when setting 'volume set nfs.addr-namelookup on'
Last modified: 2016-02-17 19:03:06 EST
Description of problem: As soon as you set 'nfs.addr-namelookup on' for a volume, all nfs mounts using that hostname fail, even after 'volume set nfs.rpc-auth-allow <hostname>'. Using the ip address in the 'nfs.rpc-auth-allow' and the mount works as expected. Version-Release number of selected component (if applicable): mainline, latest git clone master How reproducible: Always Steps to Reproduce: 1. service glusterd start 2. gluster volume create patchy host1.localdomain:/d/backends/patchy force 3. gluster volume start patchy 4. gluster volume set patchy nfs.addr-namelookup on 5. gluster volume set patchy nfs.rpc-auth-allow localhost 6. mount -t nfs -o vers=3,nolock,soft,intr localhost:/patchy /mnt/nfs/0 Actual results: The nfs mount fails : mount -t nfs -o vers=3,nolock,soft,intr localhost:/patchy /mnt/nfs/0 mount.nfs: access denied by server while mounting localhost:/patchy Expected results: nfs mount succeeds
I did some more testing using current git master. At least now, it looks like it works as long as the specifier used in 'volume set' exactly matches the specifier used in the mount command. In other words, if you 'volume set patchy nfs.rpc-auth-allow localhost', the mount command needs to use 'localhost:/nfsmount' as well. And if you use 'nfs.rpc-auth-allow host.domain', the mount command must use 'host.domain' as well. And if you 'nfs.rpc-auth-allow' 'localhost', you also need to mount 'localhost' as well. The same is true for the ip address. If you 'nfs.rpc-auth-allow' the ip, then you also need to use the ip when making the nfs mount. Using any combination of different names in 'nfs.rpc-auth-allow' and 'mount', like allowing 'host1.localdomain' and then using the ip in the mount command, fails. At least on my test system, your mileage may vary.