*quota* now correctly reports the grace time
Previously, the integer type was misinterpreted if the *quota* tool displayed the grace time for an NFS-mounted file system if the soft quota limit for the current user was exceeded, and the grace quota time already expired. As a consequence, the "quota" command incorrectly reported a large number of days instead of the `none` value. This update fixes the misinterpretation of the integer type used to transfer grace times over the network. In addition, this update limits the range of possible values to 32-bit signed integer boundaries to ensure interoperability between NFS servers and clients with a different CPU word size. As a result, the *quota* tools correctly report grace time that differs from the server time in the range from -2^31+1 to 2^31 seconds. Lower values are reported as expired, and higher as a maximal possible time that stays unchanged until the difference is in the correct range.
+++ This bug was initially created as a clone of Bug #1066516 +++
Description of problem:
Trying to check the quota of a users from an nfs client, (the directory resists on an nfs filesystem), you get a huge value for grace period, instead of none.
Version-Release number of selected component (if applicable):
RedHat 6.4
How reproducible:
Always
Steps to Reproduce:
1. Set up an NFS server, with a local filesystem ext4, with quota enabled
2. Run quota -v <username> on nfs server and you get the following output
[root@server]# quota -v user1
Disk quotas for user user1 (uid 3059):
Filesystem blocks quota limit grace files quota limit grace
/dev/mapper/HomeVG-StudentLV
178000 491520 501760 7771 0 0
/dev/mapper/MailVG-MailLV
254548* 244800 256000 none 1104 0 0
3. On an nfs client, that mount the above filesystem (with nfsv4 protocol)
if you issue the command
quota -v user1, your get a huge number for grace period instead of none
[root@nfsclient~]# quota -v user1
Disk quotas for user user1 (uid 3059):
Filesystem blocks quota limit grace files quota limit grace
csfs9:/mail/
254548* 244800 256000 49703days 1104 0 0
csfs7:/home/students/
178000 491520 501760 7771 0 0
[...]
Additional info:
The same output can be verified on both redhat linux 5 and 6, with nfs protocol v3 and v4.
For users that their grace period has not been expired, you get the correct number of days.
The grace period has also been defined on nfs server.Running edquota -t on nfs server you get the output below :
Grace period before enforcing soft limits for users:
Time units may be: days, hours, minutes, or seconds
Filesystem Block grace period Inode grace period
/dev/mapper/HomeVG-StudentLV 7days 7days
/dev/mapper/MailVG-MailLV 7days 7days
[...]
--- Additional comment from Petr Pisar on 2014-02-20 10:12:31 GMT ---
I forwarded the problem the upstream, as all versions of quota tools are affected and there is no bullet-proof solution due to badly designed RPC protocol the quota tools use.
[...]
--- Additional comment from Petr Pisar on 2014-03-05 09:37:24 GMT ---
How to test:
(1) Create an file system with enabled quotas.
(2) Export the file system over NFS and mount the NFS file system.
(3) Set quota limits for a user. Use soft limit lower than hard limit.
(4) Create file large enough to exceed the soft limit.
(5) Set grace time to a slightly more than 60 seconds:
$ setquota -u root -T 60 0 /mnt/quota/
(6) Verify 1 minute of grace time is reported by quota(1) tool on the server and
on the client:
# quota
Disk quotas for user root (uid 0):
Filesystem blocks quota limit grace files quota limit grace
/dev/loop0 21* 20 40 00:01 3 0 0
127.0.0.1:/mnt/quota/
21* 20 40 00:01 3 0 0
(7) Wait until the grace time (60 seconds) expires.
(8) Verify that the grace time is reported as `none' on both server and client.
Before:
Disk quotas for user root (uid 0):
Filesystem blocks quota limit grace files quota limit grace
/dev/loop0 21* 20 40 none 3 0 0
127.0.0.1:/mnt/quota/
21* 20 40 49697days 3 0 0
After:
# quota
Disk quotas for user root (uid 0):
Filesystem blocks quota limit grace files quota limit grace
/dev/loop0 21* 20 40 none 3 0 0
127.0.0.1:/mnt/quota/
21* 20 40 none 3 0 0
-------
RHEL-7 is affected
Patch accepted by the upstream as:
commit d850a85b2374fe1b83779c0fc61463057eeca4ab
Author: Petr Písař <ppisar>
Date: Mon Feb 24 15:54:32 2014 +0100
Prevent from grace period overflow in RPC transport
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-2195.html