Exceed quota ok when backing up

Which phase of the backup failed due to lack of quota? The latest Virtualmin release switched some operations to run as the domain owner (for security reasons) which may cause operations that used to succeed to now fail due to lack of quota.

Jamie, thanks for the information. The bug definitely sounds to be related to those changes.

On my debian 6 system, this problem raised up when I updated to Virtualmin version 4.13.gpl, .

What do you mean by "domain owner" ? For instance, do you mean that the temporary backup file is recorded in each "domain owner" 's disk space, and not in the backup command issuer disk space ?

Apart from the backup failure due to "lack of quota", as root, I also get a message mailed from cron /etc/webmin/virtual-server/backup.pl which has the following pattern :

I don't know where from it got the "orginal" box hostame. Certainly not from the "hostname" command wich returns the right hostname (the one I assigned to the box). And I don't understand why it considers this is a "domain owner". By the way, the user name (original box hostname) displayed in the message in not even a user of the system. Having no existence, it probably exeeds it's "no-quota" at the firt byte it tries to write on disk…

I hope it helps and wil try to be reactive when this thread is updated.

Ok, this is a known issue in the 4.13 release - MySQL backups are now done with the permissions of the Unix user who owns the domain, which means they are subject to the domain's quota. We will be releasing a minor update soon (in a few days) to fix this.

This is not the problem. May be my first post was not clear enough.

I don't know how the script computes the user's name or user's id on behalf of whom it intents to run MYSQL Backup, but in my case, the result of it's computing is a user who doesn't exist. Exeeding the quota is just a side effect of this original bug.

The backup scripts fails at the first domain, saying "Débordement du quota d'espace disque at ../web-lib-funcs.pl line 1397" (quota exeeded). In another log, the cron mail message shows that a task has been run with the rights of an uknown user.

Moreover, considering this first domain (the one where the backup fails), the domain's disk actual use and the owner's disk actual use are far below their quota limit : 1.4 GB used, 20GB quota limit.

The issue might be then that the domain is incorrectly configured somehow (for example it's owner doesn't actually exist). You can check for this by running a full validation check on it, at Limits and Validation -> Validate Virtual Servers.

Thank you for the advice. For an unknow reason, there was a difference between the quota value recorded at the system level and the quota recorded and displayed in the server configuration.

I just modified de values in the server configuration and saved the server. "Validate virtual servers" didn't show the problem anymore. Then I reset the quotas to their initial valuer and saved the server. Still no error.

Three sub-servers, more or less created at the same time were concerned. But other sub-servers created at about the same time where not concerned. I remember that some of these sub-servers were moved from on parent server to another (on the same system). I'm not sure that the ones concerned by the quotas unconsistency problem are exactly. Anyway, this should solve the backup failure due to "false" quota exeeded.

I hope next minor update will avoid backup failure due to scarce domain owner's free disk space when run by the system administrator.

Yes, this won't be an issue in the next release.

Once the "quota exeeded" issue solved as explained in #8, a new problem appears.

The backup still fails at the first domain. The backup trace now states :

Now, the problem seems to be that the parent domain owner doesn't have the required priviledges to acces a database attached to one of it's subdomains (in this case, its first subdomain, in alphabetical order).

I rechecked "Validate Virtual Servers". All features are OK on all domains.

I also checked the priviledges through webmin > servers > MySQL where all looks like it shoud be :

That's a separate issue which the 4.132 release will fix. Or you can solve it now by editing /etc/webmin/mysql/config and added the line login=root

I'm sorry. Of course, this is another issue but I can't find the thread where it is discussed. Is there one ? If there isn't, I'll open one.

Yes, see this thread : http://virtualmin.com/node/35764

Automatically closed -- issue fixed for 2 weeks with no activity.