WP-CLI error installing plugins/themes. “Could not create directory”. Permissions error? Ubuntu 14.04 x64

0 Views

I’ve been searching for a few days now trying to figure out a solution to this problem, but I’ve given up and its time to ask for some help.

I’m running WordPress on an Ubuntu 14.04 x64, using a Vagrant server created with PuPHPet (an automated GUI for creating boxes with Vagrant, Puppet, and Hiera for those who are unaware). I use Mark Jaquith’s WP-Skeleton WordPress folder set up, and have two shared folders set up; /var/www/wp (sitename/www/wp on the host) for WordPress core files, and /var/www/content/ (sitename/www/content on the host) for a custom content directory which is the purpose of WP-Skeleton.

Read More

When SSH’ing into the VM and running WP-CLI, everything seems to work correctly as far as WP-CLI knowing the Path to my Content directory, and WordPress core files. The problem is when trying to install plugins or themes, as shown below-

[07:20 PM]-[vagrant@packer-virtualbox-iso-1422601639]-[/var/www]-[git master]
$ wp plugin install jetpack
Installing Jetpack by WordPress.com (3.3.2)
Downloading install package from https://downloads.wordpress.org/plugin/jetpack.3.3.2.zip...
Unpacking the package...
Warning: Could not create directory.

My first, and only thought so far is that this is a permissions error, but with my limited knowledge of this area, I’ve only been able to do so much, however, I can say that I’ve tried changing the permissions of the Content directory to 755, then 765, and even 777 using chmod -v 755 /var/www/content/.

That also didn’t work, even with the permissions set to 777. So what else could be wrong? I know this probably has to do with permissions for www-data, but like I said, I have limited knowledge of what to look for, or change. I’m sure this is something simple, and I’m sure this isn’t directly related to WP-CLI, as I have a feeling if I used any other web app to try and install to the www folder that I’d have the same problem.

If anyone needs any information from me, I’ll include it such as my congif.yaml file (which when using Hiera with Puppet stores all of the info that would normally would be in the Vagranfile, and automates installing Puppet modules). It also includes info about the Ubuntu box, folder set up, etc.

Thanks in advance,
P.J.

Update:

I would like to add that adding sudo wp plugin install jetpack --allow-root will work when I use WP-CLI, however, I shouldn’t have to use sudo if I’m the root user, should I?

Post Views: 0

Related posts

Leave a Reply

3 comments

  1. I found an answer here to make it work on my local MBP OSX Server. Add define('FS_METHOD','direct'); to wp-config.php.

    Make sure all files and folders are 775 (did not reduce the permissions yet but I am positive less is workable – i.e. 664 for files – locally too) and all files and folders are owned by your user and group _www.
    Inside the project folder run:

    sudo chown user:_www  *
sudo chmod -R 775 *

    This should allow you to run wpcli and create directories without issues and without using root.

    NB _www is for OSX Apache user group. For Ubuntu you need www-data

    NBB Running Mod PHP here, with (Fast) CGI (Shared) Hosting setup 755 for directories and 644 for files normally works well.

  2. Maybe you have to define in your config.php file where is located the content directory. Depending on configuration of your server, try adding one of this two line of code:

    define('WP_CONTENT_DIR', realpath(dirname(__FILE__) . '/content'));

    or

    define('WP_CONTENT_DIR', realpath($_SERVER['DOCUMENT_ROOT'] . '/content'));

    Try with the first, if it doesn’t work try with the second. I’ve found the same error configuring wp-deploy and this worked for me.

  3. For me, all I had to do was sudo chmod -R 775 wp-content. The owner did not affect the plugin update for me and I did not have to make any other changes.

    Regarding what @helgatheviking was saying about “hardening”… If you’re worried about security and want to be secure as possible change it back to 755 afterwards! I’d say that this is a good thing to do as long as you don’t mind changing the permissions with every WP-CLI plugin update.