Bug 126258 - NFSv4 mount with AUTH_SYS returns incorrect UID/GID info
Summary: NFSv4 mount with AUTH_SYS returns incorrect UID/GID info
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 2
Hardware: athlon
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Steve Dickson
QA Contact:
URL: http://www.vanemery.com/Linux/NFSv4/N...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-06-18 04:16 UTC by Van E.
Modified: 2007-11-30 22:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-06-30 03:02:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
A patch that the fix the uid/gids that are returned by the server (386 bytes, patch)
2004-07-15 14:15 UTC, Steve Dickson
no flags Details | Diff

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.


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