Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center."drush site-upgrade @alias" fails at step 1 reporting:
"Parent directory for site alias root not found: [path/to/root/parent]; this folder must exist before running site-upgrade. See example.drushrc.php"
The root's parent directory DOES exist.
Running a simple "drush @alias status" works fine and reports the Drupal root correctly with the rest of the status data, i.e. Drupal version, etc.
Any ideas as to why site-upgrade can't figure out the remote's root but status can? If this works for others, any ideas why this might be failing on my environments? Where should I start to look first?
| Comment | File | Size | Author |
|---|
Comments
Comment #1
greg.1.anderson CreditAttribution: greg.1.anderson commentedNever seen this before. I presume that the path reported in the error message is correct? Site upgrade is just running
if (!file_exists(dirname($target_alias['root']))); I don't see how that could be going wrong if the parent folder exists and the path is reported correctly. I presume that the path is an absolute path (begins "/path", not "path")?Comment #2
texas-bronius CreditAttribution: texas-bronius commentedI'm hot on @DFMs heels with this same situation. Maybe I can provide some additional info or at least corroborate the story:
I too am trying a remote site-upgrade. My alias's path 'root' looks identical to the one on remote where it is working, so it should be ok. Also, it *looks* correct :) Same with @DFM, I am able to do a
drush @env7 st, and have experimented and confirmed that mucking with the value of 'root' does prevent that status from showing for the site... going to poke around with what greg responded with to see if it's a false-positive or what.. Maybe it's something to do with permissions or what "/" really means to an ssh tunneled session.. paths..
I'm on drush 5.8, fresh download of drush_sup (not sure how to confirm its version)
Comment #3
texas-bronius CreditAttribution: texas-bronius commentedHi Greg- Is it possibly something about the not operator "!" getting lost in pipe-ness? I'll try to say it in picture:
Maybe it's not so clear.. but the same command, one with single the other with double quotes, gets interpreted two different ways. You can see that bash thought I didn't really want "!" in my 2nd command, so it stripped or ignored or did something that removed it.
Here it is in text:
drush @env7 php-eval 'print (!file_exists(dirname("/home/egt/my.target.site/www")))'vs
drush @env7 php-eval "print (!file_exists(dirname('/home/egt/my.target.site/www')))"The first one executes as expected: path exists, so "!" skips over. Second one, "path exists" and so it executes the drush_error routine that follows.
Could it be something along these lines (when dealing with remotes)?
Comment #4
DigitalFrontiersMediaHi Greg,
Yes, the path is correct. As I mentioned, a remote drush status using the alias works and reports correct information. When I got the error message, I tried it both with and without the starting slash and multiple variations since but it originally failed using a starting slash and full path to the drupal site root. Using the same path with "cd" puts me right there with all the Drupal goodness. Drush is simply not realizing that the path is correct for some reason.
Info I (duh) should have provided with the original post: Running Drush 5.8 and drush_sup-7.x-2.0-beta1 on OWL (Open Wall Linux).
I think texas-bronius is on to something. The code you have
!file_exists(dirname($target_alias['root']))is checking if the parent directory of the destination exists on the same/current server as the origin and will set the error even if the root DOES exist on the remote.
Not sure that's the case with me. I think it has to do with permissions and the file_exists function. Both sites/environments are on the same server but have different owners and is somewhat containerized (using OpenVZ, I believe). So, despite the fact that the origin path may be /home/X/Y/Z and the destination path may be /home/X/A/Q on the same server, permissions may keep file_exists from reading the file's presence, and it should go about the task as if trying to find this path on a remote server. Perhaps you should run a check to see if "remote-host" matches between the destination alias and the @self alias. And if not, perform the necessary checks using a remote protocol.
Comment #5
DigitalFrontiersMediaSwitching this to a bug report unless the intent of the tool was that it would only work if both sites are on the same server within the same environment. Change back if this assumption is in error.
Comment #6
greg.1.anderson CreditAttribution: greg.1.anderson commentedYour target site must be local. Make a local copy of your source site, upgrade it locally, test it, and then deploy remotely.
I will improve the error checking in site upgrade to better report on this limitation.
Comment #7
texas-bronius CreditAttribution: texas-bronius commentedThe dream is dead!
Thanks guys for being so quick to respond on this thread.
For anyone else following along, I had also tried executing sup from new-remote to from-old-local.
drush @remoteenv6 site-upgrade @env7where @env7 had to be an alias locally defined on remote original D6 site.
That was no better of course, same point of failure and message.