Permission Denied During BLT Sync #2641
Comments
|
If this is syncing from a remote server to the local environment, it looks like the remote dump is failing, and it doesn’t have anything to do with the local environment. Can you verify the remote Server has a writeable temp dir for whatever user you’re ssh’ing as? Also I’ve never seen |
|
It's worth noting that this behavior isn't occurring with the previous version of Drush / BLT / etc. It's only been introduced after this update. Having said that, I wasn't trying to do the sync from inside the vm itself, i always did it from outside with the remote execution. The tmp folder on the remote server would appear to be set to 777? |
|
Can you execute the drush command directly and see if it works? |
|
I encountered this same issue. I was running |
|
|
|
@grasmash i did try and run the command directly with drush and I experienced the same failure. |
|
Can you also try with |
|
Ok, so that means to me that this is likely a Drush bug. This is suspiciously similar to drush-ops/drush#3417, the fix for which contained: drush-ops/drush@997f8d3#diff-fb2c277772bf5979ffd2cd9676de3c88R139 It looks like 'auto' is being incorrectly used as the file name. This might prevent the dumped file from being downloaded. |
|
Pinging @weitzman and @greg-1-anderson for visibility. |
|
The root issue here seems to be that drush is not correctly determining the filepath for the dump file. On Acquia Cloud, this means it attempts to dump `auto.gz' to a non-writable directory, hence: I'm not sure what part of drush is meant to read the |
|
I added a release note about this https://github.com/drush-ops/drush/releases/tag/9.2.1 |
|
Looks like @mikemadison13 is using 9.2.1 though? @mikemadison13 can you confirm this is the version of Drush on both local and remote? |
|
Actually, we know that Drush 9.2.1 is at |
|
Sometimes a Drush update happens on a lower environment but has not made it to the upper environment and thus a sql:sync can give this error. If both codebases are on 9.2.1 then we have more digging to do. |
|
@lcatlett has a suggested workaround @mikemadison13. Define the absolute path to drush and to the root dir it your drush alias: |
|
@weitzman i am pretty sure based on the status calls i've done that the cloud environment is still running drush 8.1.15. |
|
Great. Everything makes sense. Thanks for your time @weitzman. @mikemadison13 I'm going to close this issue. It seems like the resolution is to deploy Drush 9.2.0 to your remote env. In the mean time, I'm committing a workaround: #2642 It seems like there is also another that @lcatlett and @malikkotob encountered that has to do with Drush alias discovery and Drupal root settings. Let's address that in a separate issue once the issue can be described. |
|
FWIW I have updated BOTH local and cloud (test) to drush 9.2.1 and simply have This is working for me. I didn't need an absolute path. |
|
If you're updating Drush locally, and haven't deployed that remotely, you can also avoid this problem by setting the following in your |
My system information:
Output of
blt doctor:When I run this command:
I get the following output:
And I expected this to happen:
The database to sync.
I'm executing these commands inside of a newly created VM (nuked the old one and re-created after updating to BLT 9 / Drush 9).
I am using self as the alias.
Setup executes without incident.
I have confirmed that my /tmp directory is modded 777 and tried changing owner from root to vagrant without any success.
@malikkotob ran into a similar issue, he may have additional information to contribute.
cc @geerlingguy
The text was updated successfully, but these errors were encountered: