Bug 966659 - hostname based nfs mounts fail when setting 'volume set nfs.addr-namelookup on'
hostname based nfs mounts fail when setting 'volume set nfs.addr-namelookup on'
Status: CLOSED NOTABUG
Product: GlusterFS
Classification: Community
Component: nfs (Show other bugs)
mainline
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Vivek Agarwal
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-23 11:50 EDT by John Smith
Modified: 2016-02-17 19:03 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-11 04:34:21 EDT
Type: Bug
Regression: ---
Mount Type: nfs
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Smith 2013-05-23 11:50:59 EDT
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
Comment 1 John Smith 2013-06-30 11:24:56 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.