+++ 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

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

[...]

--- 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.

-----
All Fedoras are affected (tested with quota-4.01-10.fc20.x86_64).