Quota Problem -- I think?

I am having what I believe to be a quota issue that has came up.

While troubleshooting the issue where PHP5 was disabled, I had backed up/restored this virtual server several times, and also moved the directory and some files.

Currently I have the problem that I get an error daily: Insert into log table failed at Friday 29th of January 2010 12:10:02 PM. It is possible that your disk is full.

Today I was contacted that one of the "Additional Admins" could not upload content to their public_html directory.

As the Admin I am able to upload files, and have confirmed that I can upload a file to the .usermin folder, but can not upload to public_html when logged in as the virtual host admin.

When I run Administration Options/Disk Usage/home directory The stats show the Quota for public_html and other directories as "0". I have edited the sites Quota to unlimited, to 10 Gb with no change on the Quota.

Thanks in advance.

Closed (fixed)


What error message (if any) are the extra admins getting when they try to upload files?

The error is:

Failed to write to /home/plaearesources/public_html/podcasts/E2T2_Website-small.mov : Bad file descriptor.

Logged in as a VirtualMin administrator I can upload the same file without an issue.

Does the directory /home/plaearesources/public_html/podcasts exist, and if so what permissions does it have?

You may need to make it writable with a command like :

chmod 775 /home/plaearesources/public_html/podcasts

The owner and group are 'plaearesources' Permissions are 0775 as checked from the Webmin File Manager.

I also tried to use the Webmin file manager to move a file to the /home/plaearesources/public_html/podcasts folder, the error was permissions denied.

I also did run the command chmod 775 /home/plaearesources/public_html/podcasts

No effect on the problem.

When you are using the file manager module, which user are you logged in as?

I was logged in as one of the "Additional Admins". I decided to test plaearesources user to see if the problem is there, but I am unable to login as plaearesources.

I did "Change Domain Name" several times with the previous problem. There were times I saw errors with "User Already Exists"

Is the login problem just a password issue, or something out of sync with the virtual host and the username?

There are now Two 'plaearesources' groups.

I did try to change the password from Webmin/Users and Groups, Still unable to login as plaearesources.

What if you run :

chmod 777 /home/plaearesources/public_html/podcasts

to make the directory writable by anyone .. can he upload now?

And if so, which user ends up owning the uploaded file?

With security set to 0777 Login as edzim - An additional Admin

I am able to upload the file. File Owner 'plaearesources' Group 'plaearesources'

File access on the new file 0644

Ok .. and what is the owner of the new file after you uploaded it?

The file owner is 'plaearesources'

Is there more than one entry for plaearesources in your system's /etc/passwd file ?



plaearesources:x:1011:1008:Web 2.0 tools hosted at FD:/home/plaearesources:/bin/sh

Ok, that is a problem.

What is the history of this domain? Was it converted from a sub-server to a top-level server or vice-versa at some point in the past?

There was a previous ticket where what happened was an upgrade disabled PHP5. I made the wrong assumption on the problem (The only sites that appeared affected were sites imported from a GPL version of VirtualMin) I had done a lot of things to that domain including "Changing Domain Name" with and without changing the administration name. I also deleted and restored from backup. There were occasions I did get errors that the Admin User already existed.

That was a few weeks ago, and this seems to be a remnant from my blind troubleshooting.

I don't remember changing it to a sub-server though.

Ok, try SSHing in as root and running :

virtualmin validate-domains --domain plaearesources.com --all-features

assuming the domain is called plaearesources.com . I would be interested to know what that outputs..

Administration user : Administration group plaearesources has GID 1008, but the domain's GID is 1013

Home directory : Home directory /home/plaearesources is owned by group plaearesources instead of plaearesources

Apache website : Missing Apache block for HTML directory /home/plaearesources/public_html

When the PHP5 was not loading I started removing code from the Apache config file. Then I copied code from another working virtual server to see if that was the problem.

So for that group warning, are there two plaearesources groups in the /etc/group file?

And if so, what do their lines contain?

from etc/group

plaearesources:x:1008:www-data plaearesources:x:1013:www-data

Ok, so there are two groups.

Remove the line for the group with the wrong GID (1008), and it should get better.

OK, I am down to this error. There were a couple of others that I was able to correct.

Home directory : Home directory /home/plaearesources is owned by plaearesources instead of plaearesources

I tried a few things, but am still stuck with this error.

Looks like you have a duplicate user as well.

Run the command virtualmin list-domains --domain plaearesources.com --multiline to get the correct UID for the domain, and then delete the line from the /etc/passwd file with the incorrect UID.

After I did that, then cleaned up the file permissions validating the domain comes back OK.

I think the last thing is that I can not log in as plaearesources on the :10000 port of the server.

This may be a side-effect of the same issue.

Make sure there is only one entry for the user in the /etc/shadow file .. either one can be deleted if there are two. Then change the domain's password to something different, and change it back again.

That did it, I think everything looks normal again.

Thank you for putting up with my lack of knowledge on the product.

That did it, I think everything looks normal again.

Thank you for putting up with my lack of knowledge on the product.

Cool, glad you got all that fixed!

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