Bug 244577 - rpc.rquotad failes to find proper nfs exported file system
rpc.rquotad failes to find proper nfs exported file system
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: quota (Show other bugs)
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Ondrej Vasik
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2007-06-17 11:40 EDT by Nicolas Mitsis
Modified: 2013-04-12 15:11 EDT (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2008-0637
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-30 09:08:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (525 bytes, patch)
2007-08-10 10:47 EDT, Pawel Salek
no flags Details | Diff
Backported patch from upstream (4.81 KB, patch)
2008-07-17 16:49 EDT, Ondrej Vasik
no flags Details | Diff

  None (edit)
Description Nicolas Mitsis 2007-06-17 11:40:06 EDT
Description of problem:

rpc.rquotad failes to find proper nfs exported file system.

Version-Release number of selected component (if applicable):


How reproducible:


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

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.
Comment 1 Pawel Salek 2007-08-10 10:47:24 EDT
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.
Comment 6 Jeff Layton 2008-01-29 15:01:10 EST
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

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...
Comment 14 Ondrej Vasik 2008-05-12 09:25:53 EDT
Here is upstream discussion about the issue :

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.
Comment 16 Ondrej Vasik 2008-07-17 16:49:34 EDT
Created attachment 312080 [details]
Backported patch from upstream

This is backported version of upstream patch.
Comment 23 errata-xmlrpc 2008-07-30 09:08:14 EDT
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.


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