Description of problem: rpc.rquotad failes to find proper nfs exported file system. Version-Release number of selected component (if applicable): quota-3.13-1.2.3.2.el5.x86_64 How reproducible: Always. Steps to Reproduce: 1. Enable quota to local ext3fs. 2. Export quota enabled file system via nfsv3 3. Use quota <username> on remote machine where file system is exported. Actual results: Nothing (quota exits with return 0) Expected results: Show user quota. Additional info: On the machine which exports the file system the following is logged in /var/log/messages: rpc.rquotad: Can't stat() given mountpoint /home//home: No such file or directory strace outout (strace rpc.rquotad -F -o 762 read(5, "/dev/mapper/VolGroup00-LogVol00 "..., 4096) = 434 lstat("/home", {st_mode=S_IFDIR|0711, st_size=73728, ...}) = 0 statfs("/home", {f_type="EXT2_SUPER_MAGIC", f_bsize=4096, f_blocks=198167694, f_bfree=166179119, f_bavail=164165854, f_files=100663296, f_ffr ee=97763183, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0 stat("/dev/mapper/SAN-Users", {st_mode=S_IFBLK|0660, st_rdev=makedev(253, 5), ...}) = 0 stat("/home", {st_mode=S_IFDIR|0711, st_size=73728, ...}) = 0 read(5, "", 4096) = 0 close(5) = 0 munmap(0x2aaaae926000, 4096) = 0 stat("/home//home", 0x7fff12faaa30) = -1 ENOENT (No such file or directory) In machine A, in /etc/exports I have: /home x.x.x.x/24(rw,sync,no_root_squash,fsid=0) and in /etc/fstab /dev/mapper/SAN-Users /home ext3 defaults,usrquota,grpquota 1 2 In remote machine B in /etc/fstab x.x.x.x:/home /home nfs context=user_u:object_r:user_home_t 0 0 Version quota-3.12-6.el4.x86_64 from RHEL4 does not have this problem, all works ok.
Created attachment 161059 [details] Proposed patch I see the problem as well. Attached patch fixes the problem for me although I do not guarantee it covers all the execution routes.
The difference between RHEL4 and RHEL5 seems to be that RHEL5 added some code to account for the NFS4 pseudoroot. I think the proposed patch will probably break things so that NFSv4 quotas would no longer work (unless / was exported as fsid=0). The idea here is that we don't want to prepend the nfs_pseudoroot path to the pathname unless we're checking a quota on a NFSv4 filesystem. I need to read up on the rquotad protocol to see if we even have info about the nfs version being used... In the meantime, you should be able to work around this by not assigning fsid=0 to the export. If you're just using nfsv3, then fsid=0 has no special meaning and any other number will do. I'll have to have a look and see how we can fix this the right way...
Here is upstream discussion about the issue : http://sourceforge.net/tracker/index.php?func=detail&aid=1750416&group_id=18136&atid=118136 It got closed in February 2008, so I expect it was fixed somehow in latest upstram quota - which is now in rawhide Fedora. Will check more about that fix later this week and make backport of patch for RHEL-5 if possible.
Created attachment 312080 [details] Backported patch from upstream This is backported version of upstream patch.
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-2008-0637.html