disk quota incorrect

C

Crusader

Verified User
Joined
Nov 29, 2006
Messages
73
After updating to 1.33 a while back I noticed that our quotas are now showing up incorrectly.

This is what it shows now: 667.2 / 3048

When before it was closer to 2.5GB usage. This is the same for all other hosted accounts.

Is this intentional or is it a bug of some sort?

Note: I don't think it's counting the files outside of public_html into account.
 
We've seen recently that the spam mailbox contents are not owned by the user. I thought that they were previously. Here's hoping John at DirectAdmin will respond and let us know if this now the case, and if so, why.

Thanks for bringing this up.

Jeff
 
No problem.

It's just a little strange, it seems that my disk quotas are just all wrong now.. I took a look and it isn't even properly detecting files within the public_html directory.

I tried this solution: http://help.directadmin.com/item.php?id=42

But apparently I can't do it with my VPS' kernel.
 
Jeff, regarding spam mail not counting:
http://www.directadmin.com/features.php?id=903

As for the actual system quotas, use the repquota mainly to see if it works. Based on your last post, if your kernel doesn't like quotas, then you're probably out of luck. A lot of data is counted manually by DA, and gets added to the system quota values. (eg mysql, apache owned files, webmail data, etc..) so there will usually always be a value greater than zero.

For the case of the vps.. if it used to work, and doesn't anymore.. perhaps the load of the quota being constantly checked was too much so the server manager shut them off.. not sure (never heard of that, but you never know). You'd have to contact the vps provider to see if they can enable quotas in the kernel if in fact they're not enabled.

John
 
Quoats seem to be semi-operational but when I try to run quoatcheck I get this:

Code: 
quotacheck: Cannot turn user quotas off on /dev/simfs: Invalid argument
Kernel won't know about changes quotacheck did.
quotacheck: Cannot turn group quotas off on /dev/simfs: Invalid argument
Kernel won't know about changes quotacheck did.
 
DirectAdmin Support said:
Jeff, regarding spam mail not counting:
http://www.directadmin.com/features.php?id=903
Click to expand...
Thanks, John. Don't know how I missed that; generally I catch anything requiring changes to exim.conf.

I'm thinking that since beginning with the next exim.conf file I can just change the code, since it's only going to work (as I release it) with Maildir.

Did you make changes to the exim.conf masters you currently offer for download, or is there some online code that makes the change on new servers, based on something at install time?

I'm curious as to whether or not I need to make changes to my SpamBlocker version 2 download repository.

Or maybe I should just delete it and let people get the old version from you, and only support the new version myself.

Your thoughts?

Thanks.

Jeff
 
Hi Jeff,

If you only provide the Maildir version, then yes, you can make the code change permanent/default.

The default exim.conf on files.directadmin.comf does not have it by default because it's the mbox version.

However, the dovecot/Maildir patch automatically adds this code, so new dovecot boxes will get the new lines when applies to the mbox exim.conf.
http://files.directadmin.com/services/exim.conf.dovecot.patch

it's the first part of the patch in the domain_filter director:
Code: 
-  user = "mail"
+  user = "${lookup{$domain}lsearch{/etc/virtual/domainowners}{$value}}"
+  group = "mail"
John
 
One more question: am i correct in presuming that this patch will NOT change the ownership of the current email; that current email will still NOT be counted?

If so, then let's discuss whether we want to suddenly start charging spambox email against our user quotas? Will we have to reaise default space for all our users? Will we lower prices for extra space? Will our users go ballistic?

Discussion is solicited.

Hopefully we can come up with a concensus for defaults, and for how to handle changing ownership.

Jeff
 
Hello,

patching does not change the ownership of the spam files.
Running the following does though:
Code: 
cd /usr/local/directadmin/scripts
./set_permissions.sh email
The spam mail was intended to be counted, but as you mention, usage will go up pending how much spam they actually have.

John
 
You must log in or register to reply here.
Back
Top