Bug 1054124

Summary:	nfs-ganesha: "root-squash" enabled and "ls -l" for file and directory displays user:group as a numeral instead of "nfsnobody"
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	Saurabh <saujain>
Component:	nfs-ganesha	Assignee:	Bug Updates Notification Mailing List <rhs-bugs>
Status:	CLOSED NOTABUG	QA Contact:	storage-qa-internal <storage-qa-internal>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	2.1	CC:	ansubram, asriram, jthottan, mzywusko, nlevinki, skoduri, vagarwal, vbellur
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	After files and directories are created on the mount point with root squash enabled for nfs-ganesha, executing ls command displays user:group as 4294967294:4294967294 instead of nfsnobody:nfsnobody.This is because the client maps only 16 bit unsigned representation of -2 to nfsnobody whereas 4294967294 is 32 bit equivalent of -2. This is currently a limiatation in upstream nfs-ganesha 2.0 and will be fixed in future release.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-11-27 09:21:24 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1035040, 1087818

Description Saurabh 2014-01-16 09:57:02 UTC

Description of problem:
enabled root squash for nfs-ganesha process. after that I tried to create files and directory inside a directory having permissison for all.
The new files and directory are created, but "ls -l" displays that the user:group are "4294967294:4294967294", instead of "nfsnobody:nfsnobody"


Other nfs solutions display "nfsnobody:nfsnobody"

Version-Release number of selected component (if applicable):
glusterfs-3.4.0.57rhs-1.el6rhs.x86_64
nfs-ganesha-2.0.0.1-5.el6rhs.x86_64

How reproducible:
always

Steps to Reproduce:
1. mount the volume over nfs on a client
2. mkdir dir
3. chmod 777 dir
4. enable root-squash for nfs-ganesha process
5. create file or directroy inside the directory "dir", while logged in as root.
6. ls -l <mount-point>/dir

Actual results:
step 6 result,
[root@rhsauto002 ~]# ls -l /mnt/nfs-ganesha/root-dir/
total 0
-rw-r--r--. 1 4294967294 4294967294  0 Jan 16 04:21 at
drwxr-xr-x. 2 4294967294 4294967294 36 Jan 16 04:21 dir


Expected results:
the user and group should be nfsnobody nfsnobody, uid and gid for nfsnobody is usually uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

Additional info:

Comment 2 Meghana 2014-02-07 11:03:17 UTC

The permissions that are seen when root squash is enabled is based on anonymous UID and GID values used by NFS-ganesha. The default values for both  
anonymous UID and anonymous GID is -2. When this is converted to a 32 bit unsigned integer, we get the large number,  i.e., 4294967294 that is seen in the permissions. The expected value of 65534 is the 16 bit equivalent of -2. 

Please move this bug to Denali.

Comment 3 Shalaka 2014-02-10 09:17:21 UTC

Please add doc text for this known issue:

Comment 4 Shalaka 2014-02-18 10:56:33 UTC

Please review the edited doc text and sign off.

Comment 5 Soumya Koduri 2014-07-07 12:20:13 UTC

Not a blocker for Denali.

Comment 7 Soumya Koduri 2015-11-27 09:21:24 UTC

As mentioned in the doc_text, all UIDs are mapped to unsigned 32-bit integer which includes anon-uid/gid which have value '-2' by default. Since it doesn't map to nfsnobody user ID on the client machine, client shall display integer value instead. This is by design of nfs-gansha. In case if those anon IDs have to be mapped to nfsnobody, configure those values in the nfs-ganesha export file explicitly.