RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1066516 - Wrong value for expired grace period retrieved over network
Summary: Wrong value for expired grace period retrieved over network
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: quota
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Petr Pisar
QA Contact: qe-baseos-daemons
URL: https://sourceforge.net/p/linuxquota/...
Whiteboard:
Depends On:
Blocks: 1070830 1072404
TreeView+ depends on / blocked
 
Reported: 2014-02-18 14:54 UTC by M.T
Modified: 2014-10-21 09:05 UTC (History)
3 users (show)

Fixed In Version: quota-3.17-21.el6
Doc Type: Bug Fix
Doc Text:
Cause: Displaying grace time using quota(1) tool for NFS-mounted file system with enabled disk quotas while the soft quota limit for current user is exceeded and grace quota time has already expired. Consequence: The `quota' command reports a large number of days instead of `none'. Fix: A misinterpretation of integer type used to transfer grace times over network has been fixed. In addition, range of possible values has been limited into 32-bit signed integer boundaries in order to ensure interoperability between NFS servers and clients differing in CPU word size. Result: Grace time values whose difference from server time is in range from -2^31+1 to 2^31 seconds are reported by quota tools on NFS clients correctly. Other values are reported as expired or maximal possible time respectively.
Clone Of:
: 1067352 1067353 1072769 1072858 (view as bug list)
Environment:
Last Closed: 2014-10-21 09:05:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Proposed fix (4.68 KB, patch)
2014-02-24 16:24 UTC, Petr Pisar 		no flags Details | Diff
Proposed fix ported to 3.17 (4.72 KB, patch)
2014-03-05 09:06 UTC, Petr Pisar 		no flags Details | Diff
View All

Description M.T 2014-02-18 14:54:40 UTC 
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

Actual results:


Expected results:


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
Comment 2 Petr Pisar 2014-02-20 08:02:59 UTC 
Thank you for the report. I can reproduce the issue with quota-3.17-21.el6.x86_64.
Comment 3 M.T 2014-02-20 08:12:00 UTC 
Hello Petr

Many thanks for the reply. 

So we will expect for a new updated version of the quota rpm?


Maria
Comment 4 Petr Pisar 2014-02-20 08:18:47 UTC 
I cannot make any promise. However you can increase chance for updating the quota package by contacting Red Hat support.
Comment 5 Petr Pisar 2014-02-20 10:12:31 UTC 
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.
Comment 6 Petr Pisar 2014-02-24 16:24:51 UTC 
Created attachment 867047 [details]
Proposed fix

Posted to upstream for review.
Comment 8 Petr Pisar 2014-03-05 09:06:20 UTC 
Created attachment 870875 [details]
Proposed fix ported to 3.17
Comment 10 Petr Pisar 2014-03-05 09:37:24 UTC 
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
Comment 11 Joe Orton 2014-10-21 09:05:23 UTC 
This bug was resolved in a RHEL 6.5 errata per bug 1072404.

https://rhn.redhat.com/errata/RHBA-2014-0313.html
Note You need to log in before you can comment on or make changes to this bug.