Skip to main content
s/server/web server/, this is mainly encountered with web servers, and not with other common services
Link

what What is the proper solution to a web server trying to write to a directory?

Tweeted twitter.com/#!/StackUnix/status/293750687651729408
Source Link
patrick
  • 131
  • 1

what is the proper solution to a server trying to write to a directory?

So, I have a box with a "deploy" user. This deploy user owns a code repository and wordpress is running on this box...

When wordpress attempts to do something like upload a plugin, it is using the user "www-data" to write to "wp-content/plugins".. Apparently it is uploading a zipfile, unarchiving, and then removing the zipfile.

I kept running into problems where wordpress was unable to do these things.. Since my entire code repository was set to be the owner and group: "deploy:deploy", obviously www-data is not able to access this.

So, my first attempt was to add www-data to the deploy group.

usermod -a -G deploy www-data 

Immediately after issuing this command, I found that I could no longer ssh into the box.. Totally confused as to why-- can anyone fill me in on that? So I ended up doing:

chmod -R go-w ~ 

And then could ssh in again... doing "groups www-data" showed deploy as one of the options, so I thought hooray... I went and made sure the wp-content and plugin directories all had write access for the group, and they did... Double horray, it should work perfectly!

However, no... Failure upon trying to upload a plugin.

After much annoyance, I just went into the apache config and changed the APACHE_RUN_USER & GROUP to "deploy"

Problem solved... Sort of. Except the idea of apache running as the main user, I think is awful.

Anyway, so after making this change, uploading a plugin was successful and I saw:

drwxr-xr-x 8 deploy deploy 4096 Oct 22 21:28 wp-crm 

So, the group has no write access-- I thought maybe this is a hint to why this was failing... But then, the fact that it's writing with deploy, means that's not really a hint... Because that's just due to how deploy's umask is set to.. I assume...

So... I am just lost as to what the solution is...

Should my wp-content group be www-data instead?

Or am I missing something else here?