I’ve recently migrated a WordPress site from one server to another (running Plesk) and noticed that file uploads were no longer working. All existing files showed up fine, but new uploads were always aborted with a message such as “Is your uploads directory writable?” – which of course it was.
Here’s what it looked like – a familiar sight for anyone with WordPress issues:
Uploads had been working fine on the pervious server, and other sites on the new server didn’t have a problem. Puzzles like that rob me of sleep and sweet dreams. I decided to poke into any error logs on the new server (which wasn’t even that new mind you).
To my surprise I found that in /var/www/vhosts/system/domain.com/logs, there was an error log that was seemingly growing out of control very quickly. At one point it was over 500GB in size. Obviously this had a very adverse effect on the that server, which was running out of space when it shouldn’t have.
The repeating error message was this:
mod_fcgid: stderr: PHP Warning: is_dir(): open_basedir restriction in effect.
File(/) is not within the allowed path(s): (/home/www/vhosts/domain.com/:/tmp/)
in /home/www/vhosts/domain.com/httpdocs/wp-includes/functions.php on line 1501
Sure I thought, I can understand why the server had a problem with this: the path is just NOT where domain data is saved on my target server. Why was it addressing a path that may have worked on the source server? Shouldn’t WordPress adjust itself automatically?
Why yes, usually it does – unless of course there’s an old database entry that specifies this path. Many options have been removed from the WordPress admin interface over time, but the values that could be set are still in effect. Thankfully it was an easy fix – even though it took me days to think of this: that nasty path was defined under Settings – Media:
Anything in the top field is a full server path. If it starts with a slash it’s a root path, while no slash at the beginning is a relative path. A wrong path (like mine) messed up all future uploads. All I had to do was delete anything in that field.
Note that this option only shows up if a path is defined: as soon as I cleared the field, the option disappeared.
Thanks to cleasterwood for this tip, who had this problem 5 years ago (goes to show how old my WordPress installation really was):
As for that huge 500GB log file, that’s another story: simply deleting it was not enough to free up space on the server. Because Apache kept an open write connection to that file, I was still running low on space – even though the file was gone. Restarting Apache didn’t do the trick either.
What did work here was a full server restart. It took a little longer than usual, but the massive log file was gone, and over 500GB of space was back at my disposal. And more importantly, my WordPress instance was accepting uploads again.