Disk Quota Mismatch in WHM (Disk Usage Too high)

[bmcpanel]

Disk Quota Mismatch
disk quota problem
quotas wrong
/// I have seen this problem over and over again, but never did find all of the info in one place about how to find the source of the problem, and then to fix it. So, this post is a how to for other users to find in the future if they use the search function.///

PROBLEM
A customer complains that their reported disk usage is too high, that they are not using so much space. What do you do?

1. Get their username and login to WHM to see if WHM is actually reporting the amount of space usage they say. If WHM does show extreme disk usage....

2. Login to SSH and cd to their home directory
cd /home/theirusername

du -h

This will give a human readable display of folder by folder listing and space usage, with a total at the end. THIS WILL BE ACCURATE.

3. So, du -h shows a lower number than WHM? Then their is probably a backup file somewhere on the server with the same UID as this user.

4. Now, you need to locate the uid of the customer. You will need to know their username.

vi /etc/passwd

5. Once that file is open, run a search on their username

/theirusername

That will show a 5 digit number and a smaller number. The larger number should be the UID.

6. Now, go to shell and run the following command (where, in this example, 33025 is the UID of the user)

find / -uid 32025

A folder by folder listing will be displayed. It may take some time to process. When completed, you should scroll back through the output to find the files. Files in /home/username are fine as well as /etc/valiases, etc. LOOK for files in your backup directory that may have the same UID as your user. If found, that is usually the culprit.

[RegisterHosting]

Sometimes urchin files problem.
Check User Urchin data files.
cd /home/username/tmp/urchin/data/history/
than wright command rm -f -r *
This is very urgent command all urchin history files after delete.

Than use : /scripts/updatenow
/scripts/upcp
/scripts/fixquota

[thehostinghut]

3. So, du -h shows a lower number than WHM? Then their is probably a backup file somewhere on the server with the same UID as this user.
4. Now, you need to locate the uid of the customer. You will need to know their username.

vi /etc/passwd

5. Once that file is open, run a search on their username

/theirusername

That will show a 5 digit number and a smaller number. The larger number should be the UID.

6. Now, go to shell and run the following command (where, in this example, 33025 is the UID of the user)

find / -uid 32025

A folder by folder listing will be displayed. It may take some time to process. When completed, you should scroll back through the output to find the files. Files in /home/username are fine as well as /etc/valiases, etc. LOOK for files in your backup directory that may have the same UID as your user. If found, that is usually the culprit.

I done this and there is a very serous issue. It looks like it copied this users home dir into another user home dir. Here was some of the output:

./home2/anotheruser/home/thehosti/public_html/shopping/download/Baseball.zip

thehosti is the account with the quota problem. and anotheruser is where it copied the stuff to.

Those files are in there as I went to their (anotheruser) home dir and looked.

Has anyone had this problem before?

I think I have a few other accounts that this has happened to.

Tracy

[jaderrosa]

This is exactly! Thank you very much!

[shacker23]

Rather than futzing around in /etc/passwd, try this instead:

ls -ln /home/[username]

The "n" flag will give the UID of the file's owners rather than the account name.

[cPanelTristan]

Actually, you could just grep the username in /etc/passwd as well. The issue with doing:

ls -ln /home/username

If /home/username had been mistakenly chowned to the wrong user, which has happened, you'll get the wrong UID and GID. It's better to just grep the password file:

grep username /etc/passwd

That will show the UID and GID for that user.

To show an example, let's say I have the user monkey I created and want that user's UID and GID, but someone mistakenly chowned the /home/monkey directory to the system's bug4 user. When I do ls -ld, I would get:

# ls -ln /home/monkey
total 48
drwx------  8 513 510 4096 Oct 17 14:12 ./
drwx--x--x 16   0   0 4096 Oct 17 14:12 ../
lrwxrwxrwx  1 513 510   30 Oct 17 14:12 access-logs -> /usr/local/apache/domlogs/bug4/
-rw-r--r--  1 513 510   33 Oct 17 14:12 .bash_logout
-rw-r--r--  1 513 510  176 Oct 17 14:12 .bash_profile
-rw-r--r--  1 513 510  124 Oct 17 14:12 .bashrc
drwxr-xr-x  2 513 510 4096 Oct 17 14:12 etc/
drwxr-x---  8 513 510 4096 Oct 17 14:12 mail/
drwxr-xr-x  3 513 510 4096 Oct 17 14:12 public_ftp/
drwxr-x---  3 513 510 4096 Oct 17 14:12 public_html/
drwxr-xr-x  9 513 510 4096 Oct 17 14:12 rails_apps/
drwxr-xr-x  7 513 510 4096 Oct 17 14:12 tmp/
lrwxrwxrwx  1 513 510   11 Oct 17 14:12 www -> public_html/

I might then mistakenly believe 513 is the UID and 510 the GID for the monkey user. If I instead check /etc/passwd, I get this:

# grep monkey /etc/passwd
monkey:x:32009:32011::/home/monkey:/usr/local/cpanel/bin/noshell

Then to see the 513 UID, I would do:

# grep 513 /etc/passwd
bug4:x:513:510::/home/bug4:/usr/local/cpanel/bin/noshell

As a final note, it's better if you just want to see the top level of a directory to add the -d flag to ls, so you'd do:

# ls -lnd /home/monkey
drwx------ 8 513 510 4096 Oct 17 14:12 /home/monkey/

This way you don't see all the contents.

[shacker23]

Good points cpdaniel. My main concern was using vi on /etc/passwd, and the chance of accidentally editing and then saving out of habit. Grepping it is much safer.

(though I can't say I've ever accidentally chowned someone's home to the wrong user, thankfully!

[djmerlyn]

Just thought I'd chime in with a similar issue on a openvz environment. A simple reboot fixed it for me as the error was coming from the vzquota which was recalculated with a reboot. There might be a more elegant way to do it but considering a reboot takes about 45 seconds on openvz, seemed like there was a lot of better things I could do with my time like post this response.

[chiefme]

I have exact problem, du and cpanel mismatches disk quota usage.
Accurately followed all suggestios, but unfortunately my problem still exists.

Concretion:
Cpanel displays total used quota: ~500MB


So I performed following steps:

root@srv [/]# du -sch /home/oranzine
196M /home/oranzine
196M total
root@srv [/]#



root@srv [/]# du -h --max-depth=1 /var/lib/mysql/ | grep oranzine
172K /var/lib/mysql/oranzine_db



Olso run this:

find / -type f -uid 503 -exec echo -n -e {}"\0" \; | du -hc --files0-from=-
195M total



conclusion:
So mismatch is around 300MB



Any suggestions ?

[cPanelTristan]

Hello chiefme,

Do you have backups on a different partition than / on the system? Sometimes, /backup is mounted individually and the cpbackup will store files for the user under that user's UID rather than storing them as root user.

If that is not the case, please open up a ticket using WHM > Support Center > Contact cPanel or using the link in my signature so we can try to determine why there is a discrepancy. Please post the ticket number here upon opening one.

Thanks!