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:
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
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
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:
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.
Tested configuration on 2.6.7-1.476 rawhide kernel and
observed same root.bin problem. Client/server are same
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...
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
hmm... are there any complains from rpc.imapd in /var/log/messages?
Is rpc.imapd even running?
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.
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.
your patch fixed the problem. (Tested with kernel 2.6.7-1.486)
Thanks a lot
Marking fixed as per comment #8.