Bug 966659 - hostname based nfs mounts fail when setting 'volume set nfs.addr-namelookup on'
Summary: hostname based nfs mounts fail when setting 'volume set nfs.addr-namelookup on'
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: GlusterFS
Classification: Community
Component: nfs
Version: mainline
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Vivek Agarwal
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-05-23 15:50 UTC by John Smith
Modified: 2016-02-18 00:03 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-09-11 08:34:21 UTC
Regression: ---
Mount Type: nfs
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description John Smith 2013-05-23 15:50:59 UTC
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 15:24:56 UTC
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.