When querying for quotas over NFS (just type quota or quota -v from the command line to reproduce) it shows the following errors: quota: error while getting quota from hostname:/homenfs for root (id 0): Connection refused The same happens for plain user instead of root. Backporting to quota-4.03 (which is already in Cauldron) fixes the problem and then the quotas are shown correctly. Reproducible: Steps to Reproduce:
CC: (none) => luigiwalser
Looking into this, I see this change in Fedora: http://pkgs.fedoraproject.org/cgit/rpms/quota.git/commit/?id=03d375b2cc9bf6a129954785a7c98b51ce3156b4 which makes me think that updating to 4.03 may have only "fixed" it for you because it restarted the rquotad service. The real fix is probably to change nfs-rquotad.service in the nfs-utils package.
Assignee: bugsquad => guillomovitch
Indeed I got the same under three different hosts, and got the same problems either restarting manually rpc as well as nfs several times. What you get on the server are also these kind of messages in the hosts: rpc.rquotad[25918]: Denied access to host 0.0.0.0 which don't appear with quota 4.03.
So if you restart the rpcbind service and then restart the nfs-rquotad service, it still doesn't work? Does "rpcinfo -p" show the rquotad service available? Is there something in /etc/hosts.deny or /etc/hosts.allow messing it up?
I thought it was misconfigured or behind some firewall, so I disabled everything from tcpwrapper as well as shorewall but the problems were still there. On the other hand if there was some tcp wrapping around the same configuration should interfere with quota 4.03, which indeed doesn't. Anyway, rpcinfo -p shows rquotad is started: 100011 1 udp 4004 rquotad 100011 2 udp 4004 rquotad 100011 1 tcp 4004 rquotad 100011 2 tcp 4004 rquotad systemctl restart rpcbind.service systemctl restart nfs-rquotad.service then the same messages as before. Even killing the process of rpc.rquotad and then restarting nfs-rquotad.service gives the same problems above. If we gonna go deeper to see exactly what was fixed we should diffying the 4.03 vs 4.02. Indeed doing so the diff is much more consistent than the rpc-rquotad.service; there were 3 new sources rquota.c, rquota.h and rquota_clnt.c; the changelog from 4.02 to 4.03 says also "Fix building of rquota.c|h files" and furthermore 4.02 rquota part is of 2013, which sound much more older than the nfs 1.3.0.
(In reply to Giuseppe Ghibò from comment #4) > On the other hand if there was some tcp wrapping around the same > configuration should interfere with quota 4.03, which indeed doesn't. Not if you backported the quota 4.03 package from Cauldron before today. libwrap wasn't enabled. Anyway, it does indeed sound broken, so we do need to update it.
I used the Cauldron quota of yesterday evening. I'll retry with the version of today.
I retried with current svn backport of quota package, and I confirm works.
This is very strange. There aren't that many commits between 4.02 and 4.03: https://sourceforge.net/p/linuxquota/code/commit_browser and as you already noted, the only one that mentions rquota is the "Fix building of rquota.c|h files" one, but it only does this: https://sourceforge.net/p/linuxquota/code/ci/b971998d92381492e3d182987356fb3dbaed5f3a/tree/Makefile.am?diff=4d38a6af4f6aad3621506fb91a4a282ca2ec188e which makes no code changes, only build system changes that *sound* from its description like it only fixes a possible build error. It is not apparent what really makes 4.03 work for you and 4.02 not.
Indeed I think that looking there will not show all the differences. If you take the quota 4.02 and 4.03 sources, and you compare them just before the compilation stage, you'll see that there are a lot of difference in code and even code that in old version was not existing (or not generated) at all.
Does building the Mageia 5 4.02 package with the commit from Comment 8 added make it work?
Adding just those lines it doesn't.
Hi Joeghi, Thank you for having taken the needed time to report this issue and work on it. We regret if this issue never got fixed in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, but non-security bugs have no chance of still getting fixed. (In reply to Giuseppe Ghibò from comment #0) > The same happens for plain user instead of root. Backporting to quota-4.03 > (which is already in Cauldron) fixes the problem and then the quotas are > shown correctly. So this is fixed in Mageia 6 and later => closing as OLD
Resolution: (none) => OLDCC: (none) => marja11Status: NEW => RESOLVED