Bug 966659

Summary:	hostname based nfs mounts fail when setting 'volume set nfs.addr-namelookup on'
Product:	[Community] GlusterFS	Reporter:	John Smith <lbalbalba>
Component:	nfs	Assignee:	Vivek Agarwal <vagarwal>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	mainline	CC:	gluster-bugs, sankarshan, vagarwal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-09-11 08:34:21 UTC	Type:	Bug
Regression:	---	Mount Type:	nfs
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.