Hello,
I have a buddypress install an I have been testing it out before launch and one thing I noticed is that each new blog gets the following error when uploading media.
Unable to create directory /var/.../wp-content/blogs.dir/2/files. Is its parent directory writable by the server?
Hello,
I have a buddypress install an I have been testing it out before launch and one thing I noticed is that each new blog gets the following error when uploading media.
Unable to create directory /var/.../wp-content/blogs.dir/2/files. Is its parent directory writable by the server?
I've encountered issues like this before, and although I can't explain them, it usually fixes it for me if I delete the directory, then remake it with the same name and chmod the permissions. Seeing you probably haven't uploaded anything yet, this directory is empty, so try deleting blogs.dir and chmodding it, see if that helps.
If blogs.dir is 755 no blog directory created
If blogs.dir is 777 the blog directory is create with a chmod of 777 but the files directory "cannot" be created.
This is really strange, could it be so strange server setting?
7430 pointsLike some sort of WPMU DEV GodMindblowingly helpful memberLifetime member
Erstwhile founder
—
15th December 2009 (2 years ago)
#
So blogs.dir/2/ is set to 777 and you're still getting a message saying the directory isn't writable? If that's the case then it may be an ownership issue. Blogs.dir should be owned by whichever user runs your webserver.
Just to add to this. If PHP is configured to run as a module the blogs.dir directory is most likely owned by nobody sine that's the user apache runs as. If that's cool with you it should work fine.
However, if you switch (I switch to fCGI to fix mail sending issues on my server) then WPMU won't be able to access those directories since they are still owned by "nobody" and not the site user like everything else.
To fix the ownership you can ssh into the server and chown it (as the SU).
**Change to the wp-content directory chown siteuser:siteuser blogs.dir -R
Where siteuser is the unix user you assigned to the account.
If you can't ssh into the box then you can go the long route and download the entire blogs.dir directory, then rename it (don't delete it yet) and reupload it via ftp. This should reset the ownership to the correct account. You may then have to double check your permissions. Once it all works then delete the old directory.
To let you guys know, jwpegram's very last solution worked for me on Rackspace Cloud Sites. The only difference was I had no content in blogs.dir, so I deleted and recreated myself. Voila, uploads working. Slightly different steps, same concept I assume. (Hopefully, this will save someone the two hours it took me to find the answer.)
I also just ran into this on WP MS 3.0.4 and I have NO INTEREST in enabling any sort of CGI and would prefer to keep PHP running as an apache module. If you share this desire, simply make sure PHP Safe Mode is turned OFF for the domain. Some control panels like Plesk have it enabled by default.
Responses (22)
Erstwhile founder — 15th December 2009 (2 years ago) #
Hiya,
Make sure that blogs.dir and sub-directories are set to 755.
Thanks,
Andrew
Member — 15th December 2009 (2 years ago) #
Right now they are set to 777 but there is no files directory.
Am I going to have to create this directory for every new user?
Erstwhile founder — 15th December 2009 (2 years ago) #
Hiya,
That directory should automatically be created.
Thanks,
Andrew
Member — 15th December 2009 (2 years ago) #
Any idea why it is not?
Member — 15th December 2009 (2 years ago) #
I've encountered issues like this before, and although I can't explain them, it usually fixes it for me if I delete the directory, then remake it with the same name and chmod the permissions. Seeing you probably haven't uploaded anything yet, this directory is empty, so try deleting blogs.dir and chmodding it, see if that helps.
Member — 15th December 2009 (2 years ago) #
Jonathan,
Just tried this and no change.
If blogs.dir is 755 no blog directory created
If blogs.dir is 777 the blog directory is create with a chmod of 777 but the files directory "cannot" be created.
This is really strange, could it be so strange server setting?
Erstwhile founder — 15th December 2009 (2 years ago) #
When the blog directory (blogs.dir/2/ etc) is created what are the permissions?
Thanks,
Andrew
Member — 15th December 2009 (2 years ago) #
777
Erstwhile founder — 15th December 2009 (2 years ago) #
So blogs.dir/2/ is set to 777 and you're still getting a message saying the directory isn't writable? If that's the case then it may be an ownership issue. Blogs.dir should be owned by whichever user runs your webserver.
Thanks,
Andrew
Member — 15th December 2009 (2 years ago) #
user and group are apache ant not my user, is there a setting in WPMU to change that?
Member — 15th December 2009 (2 years ago) #
You need to change on server, if you have ssh just do chown user:user /pathtoyourfile
(where user is you username, you can find the username in path )
find more info about chown @ http://en.wikipedia.org/wiki/Chown
Member — 16th December 2009 (2 years ago) #
So I am going to have to do this for every new blog?
Lead Developer — 16th December 2009 (2 years ago) #
Is php safemode on on your server?
Member — 4th January 2010 (2 years ago) #
Just so if others run into this problem with Media Temple (dv) servers.
The solution is to set up php as fCGI because the default is and apache module.
Doing this will make it so the directories created by the wpmu script will have the proper user/group and permissions.
Erstwhile founder — 4th January 2010 (2 years ago) #
Thanks for sharing that. Media Temple is a popular host so I'm sure that will help other users!
Thanks,
Andrew
Member — 7th January 2010 (2 years ago) #
Just to add to this. If PHP is configured to run as a module the blogs.dir directory is most likely owned by nobody sine that's the user apache runs as. If that's cool with you it should work fine.
However, if you switch (I switch to fCGI to fix mail sending issues on my server) then WPMU won't be able to access those directories since they are still owned by "nobody" and not the site user like everything else.
To fix the ownership you can ssh into the server and chown it (as the SU).
**Change to the wp-content directory
chown siteuser:siteuser blogs.dir -RWhere siteuser is the unix user you assigned to the account.
If you can't ssh into the box then you can go the long route and download the entire blogs.dir directory, then rename it (don't delete it yet) and reupload it via ftp. This should reset the ownership to the correct account. You may then have to double check your permissions. Once it all works then delete the old directory.
Member — 16th May 2010 (2 years ago) #
Where do I "set up php as fCGI because the default is and apache module." in a media temple dv?
Thanks in advance
Lead Developer — 16th May 2010 (2 years ago) #
Google ;-)
http://www.danmyers.name/wp/2009/08/run-php-as-a-fastcgi-on-a-mediatemple-dv-3-5-server/
http://obj-a.com/content/setup-fastcgi-media-temple-dv-real-w-extra-troubleshooting-tips-including-dealing-w-fastcgi
Member — 8th October 2010 (1 year ago) #
To let you guys know, jwpegram's very last solution worked for me on Rackspace Cloud Sites. The only difference was I had no content in blogs.dir, so I deleted and recreated myself. Voila, uploads working. Slightly different steps, same concept I assume. (Hopefully, this will save someone the two hours it took me to find the answer.)
Member — 12th January 2011 (1 year ago) #
I also just ran into this on WP MS 3.0.4 and I have NO INTEREST in enabling any sort of CGI and would prefer to keep PHP running as an apache module. If you share this desire, simply make sure PHP Safe Mode is turned OFF for the domain. Some control panels like Plesk have it enabled by default.
Keeper of the Dark Chocolate — 12th January 2011 (1 year ago) #
Actually I could have sworn that safe mode was recommended to be turned off.
Messes up the autoupgrade as well it appears: http://wordpress.org/support/topic/get-around-php-safe-mode
We don;t have safe mode activated on any of our boxes.
edit: I knew I wasn't dreaming of jeanie:
Safe mode went away as of php v5.3:
http://php.net/manual/en/features.safe-mode.php
Lead Developer — 12th January 2011 (1 year ago) #
Ya, safemode is way outdated and isn't even effective for security.
Become a member