Description of problem: quota can not handle mounted NFS filesystems without quotas Version-Release number of selected component (if applicable): 4.05-7.fc31 How reproducible: everytme Steps to Reproduce: 1. NFS Server (centOS 7) with 2 exported FS XFS via NFS4. One mounted with option usrquota one with option noquota 2. mount both FS on fc31 client 3. start quota Actual results: quota: error while getting quota from fs-linux:/theorie/local for holm (id 100001): No such file or directory Expected results: Output of quota -f /home/holm Additional info: quota-4.04-11.fc29 work correct.
I assume fs-linux:/theorie/local is the file system without enabled quotas. The change in behavior you observe is intentional. The "-f" option for "quota" tool is meant to ask for quota data of a file system specified with the option. If any error occurs, including when the file system does not have enabled quota, the error is reported. It's how it has been working for local file systems and this change starts handling network file systems the same way. Here is the description from the quota author: commit a4b0af23e1e3761825e9d4ac075e3fcae8ab91cb Author: Jan Kara <jack> Date: Fri May 24 12:03:27 2019 +0200 Make messages about failures for NFS consistent with local filesystems Currently, some types for failures when fetching quota information for NFS filesystem were silent (e.g. when rpc.rquotad was not running) while others were reporting error message (e.g. when rpc connection failed). There's no big difference in these for the user / administrator and also is inconsistent with how we deal with local filesystems - there we report error if the filesystem was explicitely specified on command line and silently ignore it for "scan all" operations. So change error reporting for NFS to report errors about quota not being supported if and only if filesystem was explicitely specified on command line. Signed-off-by: Jan Kara <jack>
Ok, I can accept this argumentation. But if one filesystem does not support quotas, all other filesystems are ignored. No output at all. So what the normal dummy user expect is the error message AND the output of quota -f ... Currently one gets only "No such file or directory". Not very helpful.
(In reply to Jürgen Holm from comment #2) > But if one filesystem does not suppor quotas, all other filesystems are ignored. No output at all. I don't understand. If you use "-f" option, then only that one file system is inspected. Status of other file systems is irrelevant. I worry you talk about some other command. > So what the normal dummy user expect is the error message AND the output of quota -f ... The output of quota -f is the error message. What other output do you expect?
Output of quota-4.04-11.fc29: Enterprise: ~>quota -s Disk quotas for user holm (uid 100001): Filesystem space quota limit grace files quota limit grace fs-home:/theorie/home/holm 125G 151G 198G 409k 0 0 fs-scratch1:/theorie/scratch1 1318G 2548G 3622G 273k 0 0 Output of quota-4.05-7.fc31: Enterprise: ~>/usr/bin/quota -s quota: error while getting quota from fs-linux:/theorie/local for holm (id 100001): No such file or directory Enterprise: ~>
Thanks for the details. Now I understands what happens and I confirm I can reproduce it. This bug seems to be introduced by a later change that optimized handling of the RPC errors and it optimized it to much. I forwarded the bug report to a quota author <https://sourceforge.net/p/linuxquota/bugs/136/> together with a proposed fix. I will apply the fix to Fedora in a few minutes.
FEDORA-2020-0133fc2657 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0133fc2657
quota-4.05-8.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0133fc2657
quota-4.05-8.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.