Installer cannot create upgrade directory

I am having exactly the same “Could not create directory” problem. It started out of the blue a few days ago on one installation of WP 3.0.1. I have 3 other sites running 3.0.1 on the same server which are all working fine, but this one just won’t play nice for some reason.

On a connected note. I see some folks advising us to set perms at 777 without knowing if its a DSO or SuPHP server, which can be very helpful. If you set 755 under SuPHP, the permission used is “7” and 777 under DSO the permission used is “7” so in the case of 755 on SuPHP verses 777 on DSO, it is exactly the same thing! If you want to set something to 777, you set it to 755 on SuPHP. So if on a SuPHP machine you actually set it to 777, you instead actually set 000 —- NO ACCESS — oops!

Now to get back to trying to find the REAL cause of the problem and a REAL solution.

Do you have a wp-content/upgrade folder? If not: create it. If yes, and it still does not work chmod the upgrade folder and anything in it. This is what did the job for me. The problem is usually the file protection settings by the server of the web hoster. Another problem might be that the folder exists but is owned by “nobody”. Any decent hoster has a facility to “chown” the nobody files to its rightful owner.

By the way even if the upgrade folder can be created, plugin upgrading might still not work. One error message could be “cannot delete old plugin files”. The solution described here worked for me.

@ad Lagendijk — I had already tried all those standard fixes before writing here. In the end, I just fixed it a few moments ago by adding one “putenv” line to my wp-config.php file…

putenv(‘TMPDIR=’ . ini_get(‘upload_tmp_dir’));
define(‘FS_CHMOD_DIR’, (0755 & ~ umask()));
define(‘FS_CHMOD_FILE’, (0644 & ~ umask()));

The other two definitions I just put in for housekeeping reasons. They work in a SuPHP machine but I have no way to tell if they will be effective in a DSO machine, but I expect they won’t.

OK – I tried that – still got the same message. I have a very basic problem. I’m a novice and I have no idea what SuPHP and DSO means? My Host is BlueHost, who is the Host I had before I discovered WordPress.

I have also used BlueHost for WordPress without any problems.Su stands for single user. BlueHost uses a single-user environment.

Make sure your folder permissions are 755 and your file permissions are 644 within your WordPress install and in wp-content and in the uploads folder in there.

Then, in your WordPress Dashboard, go to Settings > Media and make sure that “Store uploads in this folder” is set to: wp-content/uploads

Make sure there is NOT a slash before, or after: wp-content/uploads

@reviveam — Google is your friend…

The Apache HTTP Server is a modular program where the administrator can choose the functionality to include in the server by selecting a set of modules. The modules can be statically compiled into the httpd binary when the server is built. Alternatively, modules can be compiled as Dynamic Shared Objects (DSOs) that exist separately from the main httpd binary file. DSO modules may be compiled at the time the server is built, or they may be compiled and added at a later time using the Apache Extension Tool (apxs).

suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.

@terrence
geezzz, thanks a lot for this line:

define(‘FS_CHMOD_DIR’, (0755 & ~ umask()));
define(‘FS_CHMOD_FILE’, (0644 & ~ umask()));

My server using suPHP and i don’t know why only today i’m having this problem, yesterday i can update/download plugins without problems at all.

I do try to test what permission wordpress apply when creating “upgrades” folder and it is “0644” which is not suitable for suPHP. i know this is the main problem because wordpress doesn’t recognize the apache module being run by servers untill i found this topic.

do you have any idea if this is a default behavior in wordpress creating directories as “0644”?

@nike.stars — files yes, but folders no, they should be 755 which is what putting those two lines in your wp-config.php file should ensure.

yes, putting that line would forced files & folders created with correct permissions. however i’m confused with the fact that i have that problem just yesterday, previously it was working fine though :-/

Whether we understand it or not, the universe is right on time.

lol, i’m familiar too with that words ??

Hey guys, none of this is working. My son who’s a WEB developer, is looking into it. He said he’s never had to do anything more than the “777” on the directory.

What I really don’t get is why is there a problem at all. I have a new site and have installed three plugins with NO problem. My previous site had over two dozen plugins and never a problem. So why now am I not able to install any more plugins on my new site?

OK – I got it! The way I got the clue was to go to Yahoo Search and ask the same question. This question has been asked over, and over, and over……..

The best response was a person who admitted to being a bonehead. And the solution was to follow the rules and deactivate ALL plugins when adding any new ones.

I’ve also kept two ideas. Deleting the upgrade folder and recreating it under new ownership with ‘777’ permissions. I also kept the wp-config.php code from Terence to add one “putenv” line plus two CHMOD defines for directories and files. What can it hurt after all?

i changed the pureftp to proftp in whm panel ftp server sellection page. all problem are fixed