Account Disk Quota Exceeded - But isn't - or is it??
One of accounts hosted on our server is alerting saying it's over its disk quota of 100GB.
When I look at the modify disk quota for the account is shows the account is using 102GB
When I SSH into the server and do a [du -sh *] to attempt to find where he's over the site is only using approximately 52GB
Thinking that maybe he exceeded his quota, removed data, then called me but the WHM was just stuck caching something... I ran Initial Quota Setup on WHM. The account owner says he sees it change to 52GB. But on the WHM I still see him using 102GB and over his disk quota. I've had to increase his disk quota to get his mobile app working again BUT something else is going on. help!
-
His databasee usage is in there too, does he have a really big database? 0 -
His databasee usage is in there too, does he have a really big database?
Thanks for the reply! No, when looking at his cpanel/mysql databases it shows his database to be 20.02MB0 -
You likely have files somewhere outside his home folder that is owned by that user like a backup file moved somewhere else. Often hard to find. You can us ethis command to look find / -user {username} Might want to add |more because you'll scroll too fast when it gets to the /home area. 0 -
You likely have files somewhere outside his home folder that is owned by that user like a backup file moved somewhere else. Often hard to find. You can us ethis command to look find / -user {username} Might want to add |more because you'll scroll too fast when it gets to the /home area.
BAM! Nice job @GOT Why would his virtfs be 64GB?? Isn't this just an account's shell environment? Through this search I found several virtfs that ranged from 14GB-64GB. I gotta clean this up if I can.0 -
Actually, the virtfs should not contribute to user quota, though should be links. You cannot just remove those files if you do then you could potentially remove them from teh users account as well. I have seen times where these links end up actually being files in which case it can cause this. I would suggest putting a ticket in with support before you go and delete them. 0 -
Actually, the virtfs should not contribute to user quota, though should be links. You cannot just remove those files if you do then you could potentially remove them from teh users account as well. I have seen times where these links end up actually being files in which case it can cause this. I would suggest putting a ticket in with support before you go and delete them.
Okay. I'm going to keeping searching and consult someone local next week and see if I can find it before I submit a ticket. Thanks so much for your help!!0 -
I agree with @GOT 's assessment here - I would add that if the user does not have Jailshell (or shell access at all for that matter) you could run the following (this won't have any effect if they do have jailed shell access nor will it remove any data) /scripts/clear_orphaned_virtfs_mounts --user=$USER
From /home/$user you could run the following to get a real time report of the usage:du -s .[!.]* * | sort -nr | awk '{print $2}' | xargs du -hs
A more thorough command that we use internally for finding combined usage of /home/ MySQL and Quota usage is:[root@server myuser]# user=$myuser; echo -ne "\nHome dir usage:\t"; du -hscgrep ^$user /etc/passwd |cut -d: -f6
|grep total; echo -ne "MySQL usage:\t"; du -hsc /var/lib/mysql/$user* |grep total; echo "Quota report: "; repquota -a |head -n5; repquota -as |grep ^$user' '; echo Home dir usage: 12G total MySQL usage: 45M total Quota report: *** Report for user quotas on device /dev/vda1 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- myuser -- 11968M 0K 0K 240k 0 0
For $USER owned files outside of the /home directory we use the following frequently:find / -path /home/virtfs -prune -o -path /home/$USER -prune -o -user $USER -ls > files_outside_homedir.txt 2>/dev/null0
Please sign in to leave a comment.
Comments
7 comments