I've got a production site (on shared hosting for now) of which I just want to have backups at this stage. and I've got a backup instance which I want to overwrite with the prod site.

This is my /etc/drush/aliases.drushrc.php:

$aliases['bak'] = array(
        'root' => '/var/www/',
        'uri' => 'testvm',
        'db-url' => 'mysql://user:pass@localhost/drupal',
        'path-aliases' => array(
        '%dump' => '/var/bak.sql',
        '%files' => '/var/drupal_files',

$aliases['prod'] = array(
        'root' => 'livesite.com:/home1/ruser/public_html/',
        'uri' => 'livesite.com',
        'db-url' => 'mysql://ruser:pass@localhost/drupal_drp3',
        'remote-user' => 'ruser',
        'path-aliases' => array(
        '%dump' => '/home1/ruser/prod.sql',
        '%files' => '/home1/ruser/drupal_files',

And all I'm getting through drush is:

Permission denied (publickey).
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9]
Could not rsync from livesite.com:/home1/ruser/public_html// to /var/www/        [error]  

Even though I can rsync/ssh/scp with no issue to and from the live site. Certificates are in place, and working fine, but not for drush...

What I'm not seeing here???

PS I've seen What could cause remote drush commands to fail with ssh errors when ssh works in all other cases?, but the accepted answer does not make any difference for me.


I was using drush as root, so I tried creating a local user with same name as the remote user. I chowned the backup instance to the remote user.

ruser@drupal:~/.drush$ drush -v rsync @prod @bak
$options['ssh-options'] = '-o PasswordAuthentication=no -i /home/ruser/.ssh/id_rsa';

Loaded alias @prod from file /etc/drush/aliases.drushrc.php [notice]

Loaded alias @bak from file /etc/drush/aliases.drushrc.php [notice]
You will destroy data from /var/www/ and replace with data from livesite.com:/home1/ruser/public_html//
Do you really want to continue? (y/n): y
Calling system(rsync -e 'ssh ' -akzv --exclude=".git" --exclude=".gitignore" --exclude=".hg" --exclude=".hgignore" --exclude=".hgrags" --exclude=".bzr" --exclude=".bzrignore" --exclude=".bzrtags" --exclude=".svn" --exclude="settings.php" --stats --progress livesite.com:/home1/ruser/public_html// /var/www/);
receiving incremental file list
rsync: failed to set permissions on "/var/www/.": Operation not permitted (1)
rsync: failed to set permissions on "/var/www/.htaccess": Operation not permitted (1)

Number of files: 14547
Number of files transferred: 0
Total file size: 92209263 bytes
Total transferred file size: 0 bytes
Literal data: 0 bytes
Matched data: 0 bytes
File list size: 313420
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 1017
Total bytes received: 316801

sent 1017 bytes  received 316801 bytes  42375.73 bytes/sec
total size is 92209263  speedup is 290.13
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1536) [generator=3.0.9]
Could not rsync from livesite.com:/home1/ruser/public_html// to /var/www/ [error]
Command dispatch complete  

This user has certificates in place in the live site as well. But still no luck...

  • The answer you quote above should do the trick for you. Run drush with the -s (simulate) flag to see exactly what shell commands Drush is using. That should help you figure out why Drush is failing; once you get that far, post again if you can't figure out how to get Drush to emit the parameters you need for your configuration. – greg_1_anderson Mar 20 '13 at 20:18

You are not specifying a remote-user on @bak so who are you performing operations as on the server at @bak? You are also not specifying any ssh config options. In this case, you are asking @bak to authenticate with @prod via ssh/rsync but you are not using agent forwarding so @prod can't see your private key. Try specifying something like

'remote-user' => 'user_on_bak',
'ssh-options' => '-T',

So that drush will execute as 'user_on_bak' and ssh will pass along your local key to @bak so when it opens a session with @prod it will have a key to pass along.

  • almost to the day, 2 years after posted :) The site does not even exist any longer, so can't really test, but sounds like common sense to me. thanks! – Makimoto Marakatti Mar 19 '15 at 22:48

I would like to see what the permissions on /var/www and /var/www/.htaccess are. try:

ls -l /var/www /var/www/.htaccess

they should be writable. You should be able to:

touch /var/www/anewfile; touch /var/www/.htaccess

if you can't, then your local ruser user does not have permissions to those files.

sudo chown -R ruser:ruser /var/www

to change ownership of all files under /var/www

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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