Hi There We recently upgraded from FreeBSD 11.2-RELEASE-p12 to FreeBSD 11.3-RELEASE-p1. Since then, the quota command on a NFS Share doesn't work anymore, which worked very well with FreeBSD 11.2. The NFS Shares are provided by a NetApp Storage, on which the rquotad is running fine. ============================================================ Behavior on FreeBSD 11.2: [quotatest@FB112:~] $ quota -f /home/quotatest Disk quotas for user quotatest (uid 166064): Filesystem usage quota limit grace files quota limit grace /home/quotatest 96 262144000 262144000 16 400000 400000 Both are identical NFS-Mounts: x.x.x.x:/vol/xxx/quotatest on /home/quotatest (nfs, nosuid) Behavior on FreeBSD 11.3: [quotatest@FB113:~] $ quota -f /home/quotatest Disk quotas for user quotatest (uid 166064): none Both are identical NFS-Mounts: x.x.x.x:/vol/xxx/quotatest on /home/quotatest (nfs, nosuid) ============================================================ Checking the commits which could maybe be a cause of this, i only found the following: base r336017 Any help is much appreciated! :)
Anyone could verify this yet?
I took some time and manually reverted base r336017 for FreeBSD 11.3, which fixed the quota bug on NFS. As you can see below, the output of 11.3(unpatched) is broken, while the patched system reports the correct quota queried from the rquotad running on our NetApp Storage. As far as i can tell, this problem does not exist when mounting an exported ufs-FS via NFS from an other FreeBSD host. Here are the outputs befor and after the revert: == BEFOR revert (Original FreeBSD-11.3-p3) == [root@113-original:~] 1 # quota -f /home/test01/ -u test01 Disk quotas for user test01 (uid 216426): none [test01@113-original:~] $ quota|grep test01 Disk quotas for user test01 (uid 216426): /home/test01 17083181722417594* 1330618343798705 45212120835836397535435945233days 8319591592418178159* 7935465087977743732 832080836963869527799576432257295days [test01@113-original:~] $ quota -f /home/test01 Disk quotas for user test01 (uid 216426): none == AFTER revert of base r336017 (Patched FreeBSD-11.3-p3) == [root@113-patched:~] 1 # quota -f /home/test01/ -u test01 Disk quotas for user test01 (uid 216426): Filesystem usage quota limit grace files quota limit grace /home/test01 35484 524288000 524288000 434 600000 600000 [test01@113-patched:~] $ quota Disk quotas for user test01 (uid 216426): /home/test01 35484 524288000 524288000 434 600000 600000 [test01@113-patched:~] $ quota -f /home/test01 Disk quotas for user test01 (uid 216426): Filesystem usage quota limit grace files quota limit grace /home/test01 35484 524288000 524288000 434 600000 600000
I don't have a way to reproduce this; anyone who can, it would be useful to find out if both client and server are using the same RPC version for rquota. For Version 1, it should be using the structure struct getquota_args { string gqa_pathp<RQ_PATHLEN>; /* path to filesystem of interest */ int gqa_uid; /* Inquire about quota for uid */ }; to request a quota; for Version 2, it should be usingstruct ext_getquota_args { string gqa_pathp<RQ_PATHLEN>; /* path to filesystem of interest */ int gqa_type; /* Type of quota info is needed about */ int gqa_id; /* Inquire about quota for id */ }; Note that USRQUOTA is 0, which matches the behaviour from the comments above. (But it could be something else.)
(In reply to Sean Eric Fagan from comment #3) According to the NetApp(NFS Server) documentation it uses Version 1 -> see: https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.cdot-famg-nfs%2FGUID-AAA569D0-785B-46E6-B951-DA9F62C3308D.html As far as i can see the RPC Version didn't change with FreeBSD 11.3 (and neither did the NetApp Version)?
That confuses me a lot, because include/rpcsvc/rquota.x specifies two versions -- version 1 is the old standard structures, while version 2 uses the new one. This would also be the same in 12.x.
(In reply to Sean Eric Fagan from comment #5) Is there anything i can do for you to help speed this up? Is there a way to force which version is going to be used?
*bump*
(In reply to Dani from comment #7) Can you check if 11.3-STABLE (after r352576, or please manually patch your local system) fixed the issue?
(This is potentially a duplicate of bug 236179 ).
(In reply to Xin LI from comment #8) Yes this fixed it! Thanks a lot!
*** This bug has been marked as a duplicate of bug 236179 ***