Bug 1054124 - nfs-ganesha: "root-squash" enabled and "ls -l" for file and directory displays user:group as a numeral instead of "nfsnobody"
Summary: nfs-ganesha: "root-squash" enabled and "ls -l" for file and directory display...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: nfs-ganesha
Version: 2.1
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Bug Updates Notification Mailing List
QA Contact: storage-qa-internal@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1035040 1087818
TreeView+ depends on / blocked
 
Reported: 2014-01-16 09:57 UTC by Saurabh
Modified: 2016-01-19 06:15 UTC (History)
8 users (show)

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.
Clone Of:
Environment:
Last Closed: 2015-11-27 09:21:24 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1240258 0 unspecified CLOSED The uid and gid of a file created when rootsquash is enabled on a ganesha volume, is not nfsnobody 2021-02-22 00:41:40 UTC

Internal Links: 1240258

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.


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