[MAJOR BUG] Disc Quota Reported Wrong

[cinique]

Setting up a new large site for a client and discovered the the disc usage is being reported incorrectly. This has a major impact on how quotas are used. I believe the issue is with
/usr/local/cwpsrv/htdocs/resources/admin/modules/user_quota.php
and/or
/usr/local/cwpsrv/htdocs/resources/admin/modules/user_quota.php
Being encrypted, I can't offer a bug fix.  I can determine the root cause, however: the quota for the user space is not being parsed and is returning the overall /home usage.

Code Select Expand

# du -bs /home
10290553724 /home
# du -bs /home/username
2855987724 /home/username


The result is that the user is over quota if , for example 5GB is set.

[cinique]

https://imgur.com/a/pcX6DLf

[josemnunez]

Hi Remember that any file that belongs to this user affects the quota even if it is not inside / home / user / this can happen when a backup is made on the same server disk

[cinique]

Hi,
I can assure you that the used space doesn't get updated, for some reason, even after removing a 6GB (bz2) file.
Hasn't updated overnight either - I had wishful thinking that a cron task might update that mysterious quota value.
Is there a means/method to force an update of the reported used space? Even if it means resetting the allocation and/or filesystem quota config; I don't care.

[Edit] Just deleted the uncompressed (yuk!) files for that user in /backup/daily (/backup is a separate partition) and it made not one bit of difference to the reported used space.

[cinique]

Latest update (CWPpro version: 0.9.8.1024) didn't fix the issue

Code Select Expand


Filesystem              Size  Used Avail Use% Mounted on
devtmpfs                1.9G     0  1.9G   0% /dev
tmpfs                   1.9G     0  1.9G   0% /dev/shm
tmpfs                   1.9G   57M  1.8G   3% /run
tmpfs                   1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/mapper/sys-root    9.8G  4.2G  5.3G  45% /
/dev/vda1               488M  231M  222M  52% /boot
/dev/mapper/sys-tmp     2.0G  3.5M  2.0G   1% /tmp
/dev/mapper/sys-var     5.8G  1.8G  3.9G  32% /var
/dev/mapper/sys-home     30G  2.6G   27G   9% /home
/dev/mapper/sys-backup  7.4G  2.5G  4.9G  34% /backup
tmpfs                   379M     0  379M   0% /run/user/0

Note that adding up all the used space, is close to what is reported for the user. 

For completeness, here's the mount points with journaling set as recommended by CentOS

Code Select Expand


/dev/mapper/sys-root    /                       ext4    defaults        1 1
/dev/mapper/sys-backup  /backup                 ext2    defaults        1 2
UUID=681c0990-91f3-4fdf-9d1b-2b470c111111 /boot                   ext4    defaults        1 2
# /dev/mapper/sys-home /home ext4 rw,seclabel,relatime,quota,usrquota,grpquota,data=ordered 0 0
/dev/mapper/sys-home /home ext4 rw,seclabel,relatime,usrjquota=aquota.user,grpjquota=aquota.grp,jqfmt=vfsv0 0 0
/dev/mapper/sys-tmp     /tmp                    ext2    defaults        1 2
/dev/mapper/sys-var     /var                    ext4    defaults        1 2
/dev/mapper/sys-swap    swap                    swap    defaults        0 0


[cinique]

Now that 0.9.8.1025 has been released to bring the end user File Manager back, I noticed this at the bottom..

Usage: 10204.75 MB / 12000.00 MB

Nope.

[Edit]
I ran

Code Select Expand

quotacheck -cugv /home

to recreate the quotas (done this a few times previously) and it now appears to be reporting correctly.
Interestingly, the user File Manager now doesn't have any disc usage status at the bottom. 
[Edit2] Some time later the status appears back. :-/ Shows correct usage.
All very strange!

[cinique]

This is still a problem!

Newly created server that I'm migrating a user over from another server. Temporarily, the quota for the user is exceeded when a zip file is descompressed.
Removing the zipfile doesn't return the user to under quota.

How does one force a quota update?

[josemnunez]

Hello

With which migration module does this happen?

[cinique]

Hello

With which migration module does this happen?

None. I was just explaining where a large data set suddenly arrived from: a 5GB zip from another server, which was then extracted.
Nothing to do with migration modules, much to do with how CWP handles quotas. To reiterate..
How does one force a quota update?

Try it for yourself.
1. Give a (test) user a disc quota of 100MB
2. Copy/upload files to the user's home, that is at least 100MB
3. Check what quota says - should say over quota
4. Delete the files from user
5. Check what quota says.

[cinique]

This is still an issue.
Has anyone else experienced this, or even tried to see if the used space gets updated properly once quota has been exceeded?

[Namaste]

Best thing to do is set up a new server and try to reproduce.  No one is going to test on a live server.  That would be asking for big trouble.  Thats pixelpadres two cents.

[cinique]

Best thing to do is set up a new server and try to reproduce.  No one is going to test on a live server.  That would be asking for big trouble.  Thats pixelpadres two cents.

All one needs to do is create a test account, with a small quota, then fill that quota. Remove some files and is the account still over quota. Delete the test account, when done. No lasting damage, as this doesn't affect other accounts - I've already checked.

[dp41646]

Use this
https://github.com/betterapp/cwp-users-quota

I am really not satisfied with CWP disk usage stats - they are simply off.

[cinique]

Use this
https://github.com/betterapp/cwp-users-quota

I am really not satisfied with CWP disk usage stats - they are simply off.

You appear to be missing the point: CWP has user quotas built-in which doesn't work correctly, with adverse affects.

[dp41646]

Yes, I know that quotas are not working correctly, that's a reason why I looked for alternative
But, of course, even with this module, problem is present in user panel, where my clients don't see real disk usage...but hoping for fix from CWP side soon