3

I'm rsyncing just the files directory (rest of the site is done through git) from my local Ubuntu setup to my centOS server. It worked at least (thankfully), but produced a ton of errors.

First it said:

rsync: failed to set times on "/home/myuser/mycentossite/sites/default/files/ctools": Operation not permitted (1)

Then tmp files and js files stated play up (sometimes happens on Ubuntu setup when clearing cache also)

rsync: mkstemp "/home/mycentosuser/mysite/sites/default/files/js/.js_ouzQFXPVCjfNTxl3b4ONpKTE.js.nghTEc" failed: Permission denied (13)

rsync: send_files failed to open "/home/myubuntuuser/websites/mysite/sites/default/files/tmp/file5GjL": Permission denied (13)

I fixed the permissions errors gradually with CHOWN and things started to work on the site. Though I'm wondering what is the correct way to go about rsyncing between local/remote in regard to permissions? And what happens if I rsync again - will it overwrite the stuff I've changed the permissions for? Or just add the new files?

Somewhat related.. My CentOS setup which uses the DSO PHP handler is also nagging me whenever I visit a page which generates a new folder of some kind. Is there way to set this up without having to go around putting CHMOD 777 on everything? (I'm the only user, so 777 in itself is not a problem for me...)

Thanks for any thoughts :)

Improve this question

2 Answers 2

Reset to default
1

Permissions issues are fairly complicated.

First off, the "failed to set times" message occurs because only the file owner can perform this operation. The solution to this problem, then, is to insure that the 'remote-user' element of your Drush site alias is the same as the owner of the files on the target machine. When pulling files to the local machine with drush rsync, it works best if you run Drush as the same user that the files are owned as.

What specific sets of permissions you choose after that is largely up to you, as there are a number of options that will work fine. What I do is make all web server code files owned by a 'www-admin' user on the live site, and owned by my local user on my dev site. On both live and dev, the files group is the webserver group, usually www-data, with directories that the webserver can write to being group-writable (and all others are set to not be group-writable, of course). Any file created by the webserver will by necessity be owned by the webserver, of course.

This works well for most situations; however, it does mean that if you rsync %files from dev to live, you won't be able to overwrite anything that was uploaded by the webserver. You might consider this a useful feature, though, as it prevents accidental overwrites.

Improve this answer
2
  • Thanks! Bare with me a little longer! Getting stuck into linux more recently! Checking local Ubuntu setup I see most of the files and dirs are owned by "www-data" (both user and group). My remote user is set to the correct user (lets call him "mycentosuser"). All the actual files seem to be owned by mycentosuser after the transfer, though the dirs were owned by nobody, so I chowned them to mycentosuser and set them to 777 so it was writable. Considering that setup, how would I add this www-admin user? (its a cpanel setup). The "nobody" thing on apache servers and who owns what is confusing!
    – KlineAl
    Commented Jun 10, 2014 at 22:36
  • You can't add users on cpanel, as far as I know (not a cpanel user, sorry). In your instance, you would just use 'mycentosuser' instead of 'www-admin'. It does not matter what you call your admin user; the name you are using (as dictated by your ISP) is fine.
    – greg_1_anderson
    Commented Jun 10, 2014 at 22:49
1

This is a pretty old post, but these days the Stage File Proxy module removes the need to rsync files from production environments to other environments.

Improve this answer

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.