drush sql-sync: rsync permissions error

[gareth-fivemile]

I've spoken to @danbohea about this:

I'm getting the following error when using drush sql-sync, using the latest dev version:

$ drush sql-sync @stage @self --no-cache -y

You will destroy data in vladdb and replace with data from X.X.X.X/dbname.

You might want to make a backup first, using the sql-dump command.

Do you really want to continue? (y/n): y
rsync: chgrp "/var/www/site/vlad_aux/db_io/drush_dumps/.vladdb.sql.t0rOXh" failed: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1655) [generator=3.1.0]
Could not rsync from user@X.X.X.X:/home/user/drush_dumps/dbname.sql to /var/www/site/vlad_aux/db_io/drush_dumps/vladdb.sql  

I've tried setting different modes for the sql-sync command in the alias file ('adivvz', 'rultvz'), but no joy.

It does successfully download the db dump to /var/www/site/vlad_aux/db_io/drush_dumps/vladdb.sql, but gets no further. The vlad_aux folder was created during vagrant up. My settings file only specifies a couple of variables (ipaddress, boxname, synced folders) so everything is pretty much default.

If it's something I'm doing wrong rather than a VLAD issue, any pointers in the right direction would be much appreciated!

Cheers, Gareth

[dixhuit]

If it continues to plague you, try commenting out the following line in ~/.drush/drushrc.php

$options['dump-dir'] = '/var/www/site/vlad_aux/db_io/drush_dumps';

That'll make drush revert back to its default location for storing drush dumps which to my knowledge has never bothered us in terms of permissions. Note that dumped files resulting from drush sql-sync will then not be stored in vlad_aux.

If you're running a custom role, the following Ansible task should take care of it for you:

# sidestep chgrp error on drush sql-sync by commenting out a line in drushrc.php
- name: Revert drush dumps location to default
  lineinfile:
    dest: /home/{{ user }}/.drush/drushrc.php
    line: // $options['dump-dir'] = '/var/www/site/vlad_aux/db_io/drush_dumps';
    regexp: 'dump-dir'
  when: php_install
  notify: drush cc drush

In the meantime, I can't recreate this so let's see who else chimes into the this issue, especially after v1.1 is released and then take a closer look if need be.

[dixhuit]

Please try deleting the following 2 dirs from vlad_aux and then reprovision using latest dev:

• drush_backups
• db_io/drush_dumps

The thing that made this start working again for me was in a commit that Phil did very recently (it changed to creating these dirs with sudo and set mode 0777).

[gareth-fivemile]

Tried deleting folders / updating / reprovisioning, still no joy. However it worked fine on another machine here, so guess it's something to do with mine - I'll have to use that role for now. Cheers :)

[dixhuit]

OK, thanks for the feedback. At least you have a workable patch for the time being on that one stubborn system. Keep us posted, especially if that system gets rebuilt.

[dixhuit]

I just managed to reproduce this albeit on the more mangled of my two systems. No idea why ATM and don't have time to debug right now either. Just thought it wise to re-open the issue at least for the time being.

[dixhuit]

@gareth-fivemile If you can still reproduce this issue, can you please try the following on the system that's playing up?

Comment out or remove the following lines from the end of vlad/playbooks/roles/drupal/tasks/drush.yml:

- name: Copy example .drush_bashrc file
  command: cp /home/{{ user }}/drush-master/examples/example.bashrc /home/{{ user }}/.drush_bashrc creates=/home/{{ user }}/.drush_bashrc

- name: Source .drush_bashrc from .bashrc
  lineinfile:
    dest: /home/{{ user }}/.bashrc
    line: ". ~/.drush_bashrc"

Destroy and rebuild that box and then check to see if it displays the same symptoms.

Cheers!

[dixhuit]

I've managed to reproduce this again recently and have now answered my own question regarding the .drush_bashrc file above - it makes no difference whatsoever.

This brings us back to drush's dump-dir option, reverting this to the default is the only fix I can find for now - this could possibly be related to whatever is really behind #216 (drush writing to the host box via NFS?).

I'm going to revert this in dev for now: having things like sql-sync working more reliably easily trumps the luxury of having drush write dumps directly to a shared directory.

[dixhuit]

This needs to be retested now that most of Vlad's drush provisioning has been refactored.

[gareth-fivemile]

Ok - will try and give it a shot tomorrow if I get time!

Cheers

On 14 October 2015 at 12:08, Dan Bohea notifications@github.com wrote:

This needs to be retested now that most of Vlad's drush provisioning has been refactored.

— Reply to this email directly or view it on GitHub https://github.com/hashbangcode/vlad/issues/203#issuecomment-148019162.

Gareth Goodwin | Lead Drupal Developer

Tel: +44 (0)1256 323414 | Office address: The Innovation Centre, Norden House, Basing View, Basingstoke, Hampshire, RG21 4HG

fivemilemedia.co.uk http://www.fivemilemedia.co.uk/

Connect with us: @FiveMile https://twitter.com/fivemile | linkedin.com/company/five-mile-media http://www.linkedin.com/company/five-mile-media

[dixhuit]

That wasn't a prompt! More of a public note to self. Obviously, additional input would be welcome though :)

[dixhuit]

Turns out the dump-dir option has been removed from Drush 7+ now anyway. Closing.

https://github.com/drush-ops/drush/commit/df3980062a89436a26db20097363da69616cbb9c