+++ This bug was initially created as a clone of Bug #519184 +++ This is a RHEL 5 report for bz 225507. The report is based on the upstream thread http://linux-nfs.org/pipermail/nfsv4/2007-December/007321.html To recreate: 1) On the server, set anonuid/anongid as 4294967294 # cat /etc/exports /export *(rw,insecure,fsid=0) /export/data *(rw,anonuid=4294967294,anongid=4294967294) Restart nfs to export the filesystem 2) On the server create a file with uid set to 4294967294 mkdir /export/data/test touch /export/data/test/a chown 4294967294 /export/data/test/a 3) Mount the nfs4 export on a client mount -r nfs4 server:/data /mnt 4) cd /mnt/test/ 5) ls -l The system will hang. The upcall by the nfs module uses a signed number. Thus the uid 4294967294 gets translated to -2 which confuses rpc.idmapd. --- Additional comment from sprabhu on 2009-08-25 11:05:50 EDT --- Patch available at http://linux-nfs.org/pipermail/nfsv4/2007-December/007321.html --- Additional comment from sprabhu on 2009-08-25 11:09:39 EDT --- A test kernel with the patch from c#1 was tested successfully by the user. --- Additional comment from jlayton on 2009-09-10 13:46:37 EDT --- Patch looks straightforward and obviously correct. I've added it to my test kernels here to get some soak time: http://people.redhat.com/jlayton/ ...I also think I see the problem with idmapd that causes it to stop responding. For most error conditions, the nfsdcb() function does not requeue the event (i.e. call event_add() again). That means that once we hit an error condition idmapd stops watching that file descriptor. I've got a patch that should help fix that, but it needs to be tested a little more and I want to get some upstream feedback on it. --- Additional comment from jlayton on 2009-09-10 15:46:44 EDT --- Patch for idmapd sent upstream. If it gets accepted I'll plan to clone this bug and we'll get this patch into RHEL too: http://marc.info/?l=linux-nfs&m=125261173214324&w=2
Committed in nfs-utils-1.0.9-43.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0284.html