Pleasanton Web Design

In trying to resolve my problem with getting a Disk quota exceeded (122) error on MYSQL Database apps, I received the following email from 1&1 Internet support (in my spam folder, as usual):

Thank you for contacting us.

This case needs to be escalated since we dont root access on our server.

As a temporary workaround, you can create a php.ini file on folder where
your script is running. The file should have like this.

session.save_path = physical path of the temporary folder where you want to save the seesion on your webspace

If you have any further questions please do not hesitate to contact us.

I have nearly 20 database aps and don’t really want to do this for each one as a temporary workaround, so I waited for the permanent fix. Unfortunately, this is the next email I received:

We are always glad to assist you in a timely manner as possible.
We see since you’ve opted to change a file to a .Ini, this has resolved
the issue.
Your disk quota is fine from our end and all looks good from here.

Please clarify if you need any additional assistance regarding this
issue.

Thanks for your patience and for choosing 1&1.

If you have any further questions please do not hesitate to contact us.

I didn’t opt to do anything. I am waiting for them to fix it, so looks like time for some more emails! This is the typical 1&1 support approach. Classic. That’s why I don’t have any client sites on 1&1 Internet. Right now I am recommending WestHost.

I just started receiving the the following errors on all my websites hosted on 1&1 internet that have MYSQL databases.

Warning: session_start() [function.session-start]: open(/tmp/sess_x, O_RDWR) failed: Disk quota exceeded (122) in /path/page.php on line 20

The result is that no session is created, so things that require a session don’t work too well.

Since I am nowhere near my allocated storage capacity, I’m not sure why this is occuring, and feel pretty confident that 1&1 support won’t tell me, even if they know. The support people that I’ve talked to so far don’t even have root access to the server, so I hope they fix it sometime soon. The temporary workaround is just to point the session.save_path somewhere else.

Luckily I use 1&1 for development only, as they are not reliable enough to host client websites, so no customers are effected.