How to Troubleshoot File-system Quota Issues

It is often essential to enable and set user and/or group disk usage limits/quotas in order to allocate/share disk space resources efficiently amongst all users. Unfortunately this often causes confusion and all sorts of problems when these limits are exceeded.

The following command displays quota limits for user “luser” …

~# quota -s -Q luser 
Disk quotas for user luser (uid 1137): 
    Filesystem   space   quota   limit   grace   files   quota   limit   grace
   tubal:/home    610M   3900M   4000M           12616       0       0        

Quota limits have two important settings, soft and hard and these are represented by columns “quota” (soft) and “limit” (hard) in the above display. The column “blocks” displays the current usage.

Unfortunately this display is somewhat cryptic and can be in fact a little noisy. The “Filesystem” column displays the affected file-system although you likely are unfamiliar with the name and might have to use the df command to establish correspondence, e.g.:

$ df -h | grep home
tubal:/home                          2.0T  1.1T  922G  55% /home/bic
tubal:/mail                          100G   82G   19G  82% /home/mail

Once the soft limit is attained, you should see the limits displayed in your shell environment. As an example, I will reduce the quota limits for user “luser” in order to trigger the soft limit, something like this:

$ quota -Q luser
Disk quotas for user luser (uid 1137): 
     Filesystem  blocks   quota   limit   grace   files   quota   limit   grace
    tubal:/home  4093952* 3993600  4096000   7days    12801       0       0

The take home message here is that you have 7 days to clean up! That’s your grace period. You will find below some tips on how to identify disk or file-system usage.

Once the grace period had been exceeded, you may see something like this instead:

$ quota -s -Q luser
Disk quotas for user luser (uid 1137): 
     Filesystem   space   quota   limit   grace   files   quota   limit   grace
    tubal:/home   3998M*  3900M   4000M 49705days    12801       0       0        

The 49705days is nonsense and should in fact say “none” but as I said, the display can be somewhat cryptic. When you are within the grace period, you can attain the hard limit (in this instance 4000M MB) but once the grace period is exceeded, and whether or not the hard limit is attained, your only option is to move or remove files as you will otherwise not be able to write to the file-system anymore.

Note that once you have exceeded the hard limit and/or the grace period, this will affect all your running applications that require write access to the affected file-system.

Ok, so now how you identify the disk space usage ? The following command may help …

$ ncdu ; $ ncdu -h # for more info

If you like the find command, try the following (as ncdu is not installed by default but you should find it on your path in our environment)

$ find . -maxdepth 1 -type d -exec du -ks {} \; | sort -n -r

The previous cryptic shell command will help you identify disk space usage for a particular directory (and sub-directories as well) - in this instance directory “.”

Replace “.” with a directory of your choosing and experiment!

You could also encapsulate this command within a small shell script as I have already done. So for those of you lucky enough to have a user account at the BIC, you can simply use the following command:

$ top_du .
741104 .
263784  ./.cxoffice
167272  ./Downloads
152920  ./.local
129860  ./.VirtualBox
98804   ./.spamassassin
87844   ./.mozilla

Those more versed in shell scripting can create their own, type the following to see the contents:

$ cat `which top_du`

The following proposes a solution to alleviate such quota limitations: How to deal with a full home folder

There may have been some corruption following an exceeded quota on /home/bic/.

So for those of you using the xfce4 desktop environment, the following should resolve such corruption issues resulting in your local window manager configuration having been corrupted:

  • logout from the graphics console

  • login to the first virtual console by typing Ctrl-Alt-F1

  • login and type the following command:
    rm -f .cache/sessions/xfce4-session*

  • logout from the virtual console

  • login to the graphics console by typing Ctrl-Alt-F7

If this still doesn’t fix the issue, you can be a little bit more brutal and replace the removal/rm step above with:

Beware: this will remove any desktop cutomization you might have done.

rm -rf .cache .config/Thunar .config/xfce4*

If you need help, contact us at bicadmin AT bic.mni.mcgill.ca.