1

I'm managing a WordPress install with Capistrano and Composer. Everything is setup and working well, its quite fast on my ngix / php-fpm setup.

However, I ran into an issue when attempting to update plugins from the admin area, WordPress asks for FTP credentials. A quick google, and its clear this is because WordPress can access web services on my server.

I SSD'd into my server and did the following:

ps aux | grep 'nginx'

nginx is running under the www-data user. That's normal.

Here's my problem: to use Capistrano you create a deploy user and give them passwordless sudo priviledges. Ok fine. I did that. Capistrano works well.

Problem is the files have to be owned by this deploy user. To do that I just chown like so: sudo chown -R deploy:www-data /srv/www/mysite.com

After that I wanted to make sure all new files and directories inherit the group ownership: sudo chmod g+s /srv/www/mysite.com

This way when capistrano adds new files they all inherit the correct permissions.

I also added the deploy user to the www-data group in an attempt to avoid the problem I'm having with WordPress.

I confirmed this by running groups deploy

When I recursively chown the directory to www-data:www-data everything works fine. I can update and download plugins from the backend BUT I can't deploy with Capistrano.

What do I have to do to nginx access to my wordpress install and solve this problem?

Thanks.

Ken Prince
  • 113
  • 5

3 Answers3

3

If you use chmod g+s instead of g+w, then all future file creations will use the specified group as the default. But that's a manual fix, which isn't really the point of using Capistrano.

I had the same problem and with a little help from stackoverflow I managed to hook a task after the deploy is finished to modify permissions of just the current/www dir (leaving the rest of the deploy structure untouched.

This has to be in the deploy namespace:

  task :mod_group do
    on roles(:all) do
      execute "chown -R :#{fetch(:group)} #{fetch(:deploy_to)}/current/www && chmod -R g+s #{fetch(:deploy_to)}/current/www"
      info "Group permission of #{fetch(:deploy_to)}/current/www modified to #{fetch(:group)}"
    end
  end

  after :finished, 'deploy:mod_group'

You also need to set :group, 'www-data' or whatever group name you want in the configs before the task runs. As other people have suggested, I'd also recommend using deploy user instead root.

In the case of Wordpress, it may be the app, not www, path that you want to mod - which would probably mean you can just set roles(:app) too.

Edit: As I commented, an alternative is to use within release_path do to change into the specific path to run the commands. However, I found that method doesn't play nice with the command formatted as one string, so you have comma separate the args for execute. As follows:

  task :mod_group do
    on roles(:all) do
      within release_path do
        execute 'chown', '-R', ':www-data', 'www'
        execute 'chmod', '-R', 'g+s', 'www'
        info "Group permission of www modified to www-data"
      end
    end
  end

In that example I also set the group name inline, because its a bit redundant using such a generic config that you only call once.

Teeks
  • 51
  • 5
  • Actually I just found out the 'release_path' is exposed to Capistrano tasks, so you can execute commands within a relative path more easily than in my example, by wrapping the command in `within release_path do`. – Teeks Nov 24 '14 at 10:09
1
  • change ownership to www-data:www-data

    sudo chown www-data:www-data /path/to/wp -R
    
  • add your deploy user to the www-data group

    sudo usermod -a -G www-data deploy
    
0

Sounds like you may have forgotten to give group write permissions:

$ sudo chmod g+w /srv/www/mysite.com
EEAA
  • 109,363
  • 18
  • 175
  • 245
  • Thanks for the answer. I gave that a shot but it didn't work. I did set my base permissions ```chmod -R 775 /srv/www/mysite.com``` without success. Also tried granting 777 permissions on the whole directory...Only thing that seems to solve this is changing the owner to www-data. I did have the idea to just run nginx as the deploy user, but I'm not sure what other problems this would cause. – Ken Prince May 19 '14 at 20:35
  • Only solution I've found so far is chown to www-data, which breaks Capistrano deploys. – Ken Prince May 20 '14 at 17:15
  • Still haven't found a working solution. May just have to run all my web services under deploy:www-data. I'll report back with results. – Ken Prince May 21 '14 at 16:14
  • UPDATE: It looks like I've uncovered at least one issue: I store individual sites in ```/srv/www``` The ```/srv/www``` directory was owned by root:www-data, and did not have group write permissions. – Ken Prince Jun 11 '14 at 15:32