Bug 126258

Summary: NFSv4 mount with AUTH_SYS returns incorrect UID/GID info
Product: [Fedora] Fedora Reporter: Van E. <garmster>
Component: nfs-utilsAssignee: Steve Dickson <steved>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: mattdm, michael.rozman, shahms
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
URL: http://www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec.html#RW
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-06-30 03:02:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A patch that the fix the uid/gids that are returned by the server none

Description Van E. 2004-06-18 04:16:41 UTC 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016

Description of problem:
NFSv4 (with auth_sys) worked fine with R/W mounts with the original
2.6.5-1.358 i686 kernel and nfs-utils-1.0.6-22.  When the server was
upgraded to 2.6.6-1.427 i686, a user on the client can only see
user=root and group=bin with the ls -l command.  When non-root users
create files on the mount, the UID/username and GID/groupname are
correct on the server, but are displayed incorrectly on the client. 
Also, users cannot delete files they create.  

The problem seems to be server-side only...there are no problems with
using 2.6.5 or 2.6.6 on the client as long as the server is 2.6.5. 
The setup I was using is documented here: 

http://www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec.html

I saw no errors in any of the logs.  There were no changes to any of
the config files, and the idmapd.conf files are identical on client
and server.

Additionally, using the sec=sys option to the mount command on the
client results in an error.  The manpage lists this as a valid option.

Thanks - Van

Version-Release number of selected component (if applicable):
nfs-utils-1.0.6-22.i386.rpm  and 2.6.6-1.427-i686 kernel

How reproducible:
Always

Steps to Reproduce:
1. Use 2.6.6-1.427 kernel on server
2. Setup NFSv4 export on server, mount on client
3. try to list or create/delete files as a regular user

Setup located here:

http://www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec.html
    

Additional info:
Comment 1 Richard Chan 2004-07-08 13:18:01 UTC 
I have observed the same behaviour with 2.6.6-1.435 errata kernel
running on server. Client is also 2.6.6-1.435.
Comment 2 Richard Chan 2004-07-09 00:33:55 UTC 
Tested configuration on 2.6.7-1.476 rawhide kernel and
observed same root.bin problem. Client/server are same
machine.
Comment 3 Steve Dickson 2004-07-12 18:30:27 UTC 
Try using the rawhide nfs-utils. It sound to be that the rpc.idmapd
daemon (the daemon doing the uid/gid mapping) is down. There was
and issue like this in earlier nfs-utils...
Comment 4 Richard Chan 2004-07-13 04:44:18 UTC 
Ok - that didn't work - upgraded to nfs-utils-1.0.6-30 from rawhide
and one of the rawhide kernels -1.471, -1.478. The same problem 
is being exhibited - all files at the mount point belong to root.bin
though on the export side the ownership is correct.

Confirm that rpc.idmapd is running; client and server machine are the
same.
Comment 5 Steve Dickson 2004-07-13 17:45:07 UTC 
hmm... are there any complains from rpc.imapd in /var/log/messages?
Is rpc.imapd even running?
Comment 6 Michael Rozman 2004-07-13 21:16:07 UTC 
I have observed the same behaviour on all FC2 kernels I tried 
except the original 2.6.5-1.358. (I am running now 2.6.7-1.486 from 
people.redhat.com/arjanv/2.6/ on both server and client, nfsv4 with krb5).
 
There are no complains in /var/log/messages. rpc.idmapd -vvv is running.
Comment 7 Steve Dickson 2004-07-15 14:15:04 UTC 
Created attachment 101940 [details]
A patch that the fix the uid/gids that are returned by the server

Please try this patch and let me know how it goes.
Comment 8 Michael Rozman 2004-07-15 17:58:56 UTC 
Steve,

your patch fixed the problem. (Tested with kernel 2.6.7-1.486)

Thanks a lot
Comment 9 Matthew Miller 2006-06-30 03:02:18 UTC 
Marking fixed as per comment #8.
Comment 10 Matthew Miller 2006-06-30 03:02:38 UTC 
Marking fixed as per comment #8.