A faculty member is having difficulties with a instructional wordpress install. Fixing individual permission problems has been hit and miss, and have become a perennial pain, so I'll ask here. What can I do to make WP Just Work? The kinds of errors they get:

Installing Plugin: Lightbox 2 2.9.2 Downloading install package from http://downloads.wordpress.org/plugin/lightbox-… Unpacking the package… Could not create directory. /home/CIM140/public_html/wordpress/wp-content/upgrade/lightbox-2.tmp

When I su as www-data (the user apache runs as in Ubuntu), I can make that directory just fine. My test wp instance installs this plugin just fine, so I'm at a loss as to why it fails for them.

6 Answers 6



I had the same problems running mod_php with WordPress and I finally figured it out.

# chown www-data:www-data  /home/CIM140/public_html/wordpress/ -R

As long as YOU control the box this won't cause any security issues.


You might also need to change your umask to 022 so new directories created by WordPress will have 755 permissions and files will have 644 permissions.

Another option is to override default file permissions in wp-config.php:

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

You can also force the filesystem method for updates.

  • (Primary Preference) "Direct" forces it to use Direct File I/O requests from within PHP, this is fraught with opening up security issues on poorly configured hosts, This is chosen automatically when appropriate.
  • (Secondary Preference) "ssh" is to force the usage of the SSH PHP Extension.
  • (3rd Preference) "ftpext" is to force the usage of the FTP PHP Extension for FTP Access, and finally
  • (4th Preference) "ftpsockets" utilises the PHP Sockets Class for FTP Access.

These can be defined in wp-config.php with: define('FS_METHOD', 'ftpext');

You can get all the currently defined constants by executing the print_r(@get_defined_constants()); command in php.

  • Done that already =(
    – jldugger
    Commented Sep 24, 2010 at 19:39
  • example: drwxrwsr-x 6 www-data www-data 4096 2010-09-22 23:15 wp-content
    – jldugger
    Commented Sep 24, 2010 at 19:40
  • Try changing them to drwxr-xr-x 7 www-data www-data 4096 Sep 24 09:38 wp-content
    – Chris_O
    Commented Sep 24, 2010 at 20:01
  • Also I have never used the SGID attribute on a directory ie: chmod g+s I don't think that is needed. Someone correct me if I am wrong.
    – Chris_O
    Commented Sep 24, 2010 at 20:13
  • Ah, after getting in touch with the faculty, it looks like it's defaulting to SSH while my test instance hits up direct IO. So it's his user that doesn't have rights to create the directory.
    – jldugger
    Commented Sep 24, 2010 at 22:17

For me (on Ubuntu) I had to add umask 002 to /etc/apache2/envvars in order to get Wordpress to upload plugins/images with 775 permissions instead of 755 (i.e. allow anyone besides Apache and root to change the uploaded files)


In order to understand why you're having these problems, you need to understand the underlying concepts of ownership.

Basically, you know that apache is running as the www-data user. This is why setting everything to be owned by that user works, because WordPress is verifying that it can create files as the user that owns its own files. So, what you're doing is to make everything owned by the user that owns the files.

If you have full and total control of the machine, this is fine. On the other hand, if it's a shared hosting server, then you have created a security hole.

Normally, web servers run as some user (like www-data) which then runs code by other users (like "otto", my user account). In this situation, the webserver would not have the ability to create files as "otto", and thus would not be able to properly create files as my account. Thus, this check by WordPress as to creating properly owned files and thus being able to install plugins or update files would fail, correctly, because having my files owned by the shared webserver user would be a security risk.

In such a case, WordPress should correctly prompt me for FTP credentials, or something to that effect. These would be a way to work around the user account issue by authenticating as the user that should be writing the files, and then writing them as that user.

Now, you're trying to solve this problem by changing all the WordPress files to be owned by the same account that the webserver writes the files as. The more normal approach for this is to change how the webserver writes files, to allow the PHP process to be "owned" by the user account that it is running the files as.

The general answer to this is "suphp". This version of PHP sets the user that the PHP process runs as to the same user as the owner of the PHP files it is running. This is safer on shared hosting setups, because it ensures that a PHP process being run by the shared webserver runs as the owner of the PHP files, and thus can't read other users accounts and the like.

On Ubuntu, I believe this is the general way to do it:

Install suphp:

$ sudo apt-get install libapache2-mod-suphp

Disable the old mod_php

$ sudo a2dismod php5 

Restart Apache

$ sudo /etc/init.d/apache2 restart

And voila. Now, have your WordPress PHP files owned by the Normal owner of them. No special tricks, no changing permissions or ownership or anything like that. Since the PHP process will run as the owner of those files, then it will be able to write to them as that owner. Directories should be 755, files should be 644 (note, suphp doesn't like when files are writable by group, so 755/644 is the correct permission set).


I have sometimes had sites where correcting the directory and file permissions was not enough to fix this problem. I've then discovered that one or more directories have the immutable flag set. This can be easily solved by running chattr -R /var/www/sub.domain.tld as root.


You need to give write permissions to the relevant directories. Ideally, you should do it only for the relevant file or folder and then revert the permissions back so as to not leave your site vulnerable.

You can fix this using the following commands from the command line (assuming that you are in the Wordpress root folder):

# cd wp-content
# chmod -R a+w plugins
# chmod -R a+w themes
# chmod -R a+w upgrade

The safest solution is to add apache to the same group as the owner of the Wordpress installation and change all group permissions to writeable.

  • 1. If there is more detailed solution, add it here, instead of linking to it. 2. no, the webserver should be in no way in a position to directly write to the code directories, unless you enjoy being hacked. Commented Apr 17, 2016 at 7:14
  • 1
    @MarkKaplun but then extension updates don't work, which bulk of WP users considers "normal" way to run a site. A little too strong of a statement. Server being able to write over wp-content is relatively worse for security, but by itself it's not a huge problem.
    – Rarst
    Commented Apr 18, 2016 at 6:36
  • @MarkKaplun: Even the accepted answer basically says the same thing - the only thing that it is specific to Apache while mine is generic.
    – Varun
    Commented Jun 23, 2016 at 4:31
  • 1. If your answer is the same, what is the point of having it? 2.Who said the accepted answer is great? Commented Jun 23, 2016 at 5:54
  • @Rarst, it is also less convenient to lock the front door of the house and close the windows. If people prefer to look for hacked files all over their server instead of just in the uploads directory they can do what the answer suggested. Wordpress plugin/theme updates is best done via an ftp server if you can not be bothered to use an sftp client app. Commented Jun 23, 2016 at 6:03

Here very easy solution is : change the permission of opt folder by running command sudo chmod -R 777 /opt.

  • 1
    Please edit your answer, and add an explanation: why could that solve the problem? Why do you think it's a good solution to let everyone read, write, and execute files in these directories?
    – fuxia
    Commented Jan 8, 2021 at 0:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.