[v3.0.0-rc.1] Drush not found in Drupal recipes

[uberhacker]

Bug Report

$ lando drush
/bin/sh: 1: drush: not found

It appears that the home directory for the normal user has changed from /var/www to /user and when you ssh into the container and cd to the home directory, it is still /var/www. This wouldn't normally be a problem but since drush has been installed in /user/.config instead of /var/www/.config, the path to the drush executable cannot be found. See below:

$ lando ssh -u root
root@576ca18fb27f:/app# find / -name drush | grep bin
/user/usr/local/bin/drush
/user/.config/composer/vendor/bin/drush
root@576ca18fb27f:/app# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/www/.composer/vendor/bin

$ lando ssh
www-data@576ca18fb27f:/app$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/www/.composer/vendor/bin
www-data@576ca18fb27f:/app$ cd
www-data@576ca18fb27f:~$ pwd
/var/www

System specs:

$ uname -a
Linux Lenovo-Y70-70-Touch 4.15.0-33-generic #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID:	LinuxMint
Description:	Linux Mint 18.2 Sonya
Release:	18.2
Codename:	sonya
$ lando version
v3.0.0-rc.1
$ docker -v
Docker version 18.06.1-ce, build e68fc7a
$ docker-compose -v
docker-compose version 1.22.0, build f46880fe

Contents of .lando.yml:

name: mysite
recipe: drupal7
config:
  webroot: .
services:
  database:
    type: mysql:5.6
  appserver:
    type: php:5.6
    via: apache:2.2

Symptoms when executing lando start for the first time or lando rebuild:

...
Creating mysite_appserver_1 ... done
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   599    0   599    0     0   1693      0 --:--:-- --:--:-- --:--:--  1696
100 4482k  100 4482k    0     0  1842k      0  0:00:02  0:00:02 --:--:-- 2716k
 PHP configuration      :                  
 PHP OS                 :  Linux           
 Drush script           :  /tmp/drush.phar 
 Drush version          :  8.1.16          
 Drush temp directory   :  /tmp            
 Drush configuration    :                  
 Drush alias files      :                  

mv: cannot create regular file '/usr/local/bin/drush': Permission denied
error: Looks like one of your build steps failed with [object Object]
warn: This **MAY** prevent your app from working
warn: Check for errors above, fix them, and try again

[dsnopek]

I'm also getting this error, but I was testing with the 'drupal6' recipe. Here's my .lando.yml:

name: drupal-6-git
recipe: drupal6
config:
  webroot: .
  php: '5.6'

I had some other weirdness, but this is issue is critical enough (need to run drush!) that I reverted to Lando -beta47, and haven't had a chance to dig deep enough into the other issues to give a good report.

[dustinleblanc]

@uberhacker do you see this with:

name: mysite
recipe: drupal7
config:
  php: '5.6'
  webroot: .

? I can't reproduce using our example in the repo

[uberhacker]

Hey @dustinleblanc: Thanks for the feedback. It happens if I add php: '5.6' in the config section also, even on a newly init'd site. Seems to happen intermittently, however. It almost always happens the first time the site is launched (ie. via lando start or lando rebuild but after subsequent lando rebuild attempts, the issue is intermittent (sometimes it works, sometimes not). I wonder if this is another case of the node asynchronisms? I thought maybe the quotes around '5.6' might make a difference but that doesn't seem to be the case.

[dustinleblanc]

If it's intermittent, I'd imagine its a case of the drush install process just being flakey. If you see a rando failure again can you try to pull a lando logs -s appserver and see if there are any delicious details of Drush failing to install?

@dsnopek I haven't tested the d6 recipe yet, but if you have a chance, we should have a d6 example in the examples folder, if you can reproduce it there too I'd be more concerned, but it's on my todos to do that.

[dsnopek]

@dustinleblanc Yep, it happens for me with the example too! However, apparently it is intermittent. When I was testing before, I must have just gotten unlucky and had it happen every time. If I just lando restart or lando rebuild a bunch of times, it'll happen some percentage of those times.

Here's the output from Lando on the command line:

dsnopek@bonobo:~/prj/lando/examples/drupal6$ lando rebuild
? Are you sure you want to rebuild? Yes
Killing d6_database_1  ... done
Killing d6_appserver_1 ... done
Removing d6_database_1  ... done
Removing d6_appserver_1 ... done
Going to remove d6_database_1, d6_appserver_1
Pulling appserver ... done
Pulling database  ... done
appserver uses an image, skipping
database uses an image, skipping
landoproxyhyperion5000gandalfedition_proxy_1 is up-to-date
Creating d6_appserver_1 ... done
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   599    0   599    0     0   1906      0 --:--:-- --:--:-- --:--:--  1901
100 4482k  100 4482k    0     0  3115k      0  0:00:01  0:00:01 --:--:-- 9506k
 PHP configuration      :                  
 PHP OS                 :  Linux           
 Drush script           :  /tmp/drush.phar 
 Drush version          :  8.1.16          
 Drush temp directory   :  /tmp            
 Drush configuration    :                  
 Drush alias files      :                  

mv: cannot create regular file '/usr/local/bin/drush': Permission denied
error: Looks like one of your build steps failed with [object Object]
warn: This **MAY** prevent your app from working
warn: Check for errors above, fix them, and try again
Starting d6_appserver_1 ... done
Creating d6_database_1  ... done
Waiting until database service is ready...
Waiting until appserver service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...

BOOMSHAKALAKA!!!

Your app has started up correctly.
Here are some vitals:

 NAME            d6                                       
 LOCATION        /home/dsnopek/prj/lando/examples/drupal6 
 SERVICES        appserver, database                      
 APPSERVER URLS  https://localhost:32828                  
                 http://localhost:32829                   
                 http://d6.lndo.site                      
                 https://d6.lndo.site                     

Here's the logs from the above attempt, but there's nothing useful in there.

On v3.0.0.beta-47, I sometimes see Drush fail to download because of some certificate verification thing. But I've never seen this (a permission denied issue) on any previous version of Lando.

[uberhacker]

I'm guessing this issue has something to do with the user home directory. Which is the intended end result in the Lando container? Is it /user or /var/www? I'm thinking maybe the images need to be updated to match what Lando is expecting or vice versa.

[dustinleblanc]

@uberhacker the user's home is /var/www (as the default user is www-data). /user is where we mount the host user's home directory for things like SSH key forwarding magic.

In @dsnopek's output I see mv: cannot create regular file '/usr/local/bin/drush': Permission denied

Which tells me there is an issue with the permissions script not getting run. @dsnopek are you on Linux? Your logs output seems to indicate that the permissions script is firing at the beginning, but if my memory serves me correctly, Linux is prone to more permissions snafus in Lando world, and I know @uberhacker bleeds penguin blood ;)

[uberhacker]

@dustinleblanc: Thank you for the feedback. That is good to know. Permission snafus are most likely due to Lando and not Linux. If the problem was consistent, I might blame Linux. Penguin defended. :-P

[dsnopek]

@dustinleblanc Yep, Linux, but I've never had any permission issues with Lando in the past (and I've used a lot of different versions over the last year :-))

[dustinleblanc]

@uberhacker I meant we haz more problems on linux :p

@dsnopek yeah we definitely have more of them on Linux, and I think it's because Docker is native, and therefore permissions things are handled more transparently, where on OSX things are more managed.

Either way, helps to describe what is happening a bit more, thanks!

[uberhacker]

@dustinleblanc: It sounds like maybe Lando is trying to use the Mac overlay to manage permissions on Linux? Maybe you need to bypass that when using native Docker? Sometimes it helps to "cut out the fat". ;)

[dustinleblanc]

@uberhacker we run this script at the startup of every container to normalize permissions: https://github.com/lando/lando/blob/master/plugins/lando-engine/scripts/user-perms.sh

This is container side only, but I know on Linux, that means something different, I am not positive but I believe the permissions bleed through to the host or something. The difference is just in how docker behaves on different hosts.

I don't know anything for certain, but this just feels like it is related to that difference unless we start seeing some Mac/Win issues that match.

Regardless, still something we'll need to fix as the penguin is a first class citizen of Cloud City.

[uberhacker]

Thanks for focusing on this issue @dustinleblanc. For awhile there, I was thinking this: https://i.imgflip.com/2iotfh.jpg.

[dsnopek]

I am not positive but I believe the permissions bleed through to the host or something.

Yeah, on Linux, the permissions set on mounted volumes are changed on the host immediately, because they are literally the same files (just bind mounted to a different place).

Anyway, looking at the user-perms.sh script, this definitely looks like a race condition!

# Do a background sweep
  nohup chown -R $LANDO_WEBROOT_USER:$LANDO_WEBROOT_GROUP /var/www/.ssh &>/dev/null &
  nohup chown -R $LANDO_WEBROOT_USER:$LANDO_WEBROOT_GROUP /var/www &>/dev/null &
  nohup chown -R $LANDO_WEBROOT_USER:$LANDO_WEBROOT_GROUP /usr/local/bin &>/dev/null &

We care about the 3rd one down: changing permissions of /usr/local/bin. But these are all run asynchronously in the background! When this script has finished, there's no guaranty that those chown commands have finished running. Why is this done like this? I imagine it makes this script run faster, but it'll also make it totally unpredictable. Could these just be changed to run normally?

[uberhacker]

Nice detective work @dsnopek! I'll add that the first line is not needed since the chown is done recursively on the second line and will pick up the /var/www/.ssh directory.

[pirog]

@uberhacker @dsnopek see #1211 (comment)

@dsnopek note that /usr/local/bin proper is set synchronously further up the script but not recursively. Perhaps we need that to be recursive although im honestly not sure why that would matter?

[dsnopek]

@dsnopek note that /usr/local/bin proper is set synchronously further up the script but not recursively.
Perhaps we need that to be recursive although im honestly not sure why that would matter?

Ah, sorry, I didn't notice that. So, perhaps this script isn't even the problem and something else later is messing up the permissions on that directory? Alls I know is this bug happens so frequently that I can't switch to rc1. I wish I could be more help in solving it!

[pirog]

@uberhacker @dsnopek this is definitely one of the major things i want to get fix before the "official" RC release. Definitely something i am keen to replicate and help resolve once i return from 🇷🇺 and have access to a linux box

[dsnopek]

Thanks, @pirog!

If I were to characterize why this bug is so disruptive in a little more detail:

Lando has had weird intermittent problems for a long time, but they mostly happened on the first run of starting Lando on a new project. I'm used to running lando start then lando restart once or twice when first using a project on my computer - but then everything works fine on subsequent lando stop and lando start. That's annoying, but it only affects the first run with a project, not the on-going day-to-day usage, so it's not really a big deal.

With this problem, it does affect the on-going day-to-day usage. I'm constantly switching between projects, which means starting and stoping a lot, and that's failing a high percentage of the time.

[pirog]

In RC1 we changed the way build steps are handled. they should run only once (when you start your app for the first time) or if you explicitly run lando rebuild. The caveat here is if one of the build steps fail then lando will report the failure and try to run the steps again on subsequent starts until it succeeds. I think this is the correct approach and actually a big improvement over the less defined way we did things pre RC1 eg now there is a clear distinction between a restart and a rebuild and consequently more stability between restarts on apps that have run through their build steps. I'd also recommend checking out https://docs.devwithlando.io/config/build.html

All that said, RC1 has big changes in it so its not surprising to see some bugs, especially on Linux/Windows. This is why we listed rc1 as a "prerelease" instead of an official version.

[uberhacker]

@pirog: That does sound like the most elegantly engineered approach. I would like to point out this is not the only issue with permissions in Linux. It appears, due to the intermittent behavior, that permission problems are related to recursive permission changes done asynchronously vs synchronously (aka via nohup). I have confirmed that removing the nohup on these operations assures the permissions are set prior to executing any other system commands. Now if I can only get you to ditch that slow Mac and start using Linux as a first class citizen on this project. :-P

[dsnopek]

@pirog Those changes sound great! Looking forward to being able to take advantage of them (... once this bug is fixed ;-))

[pirog]

@dsnopek i also await that glorious and righteous day of deliverance

[nylen]

I'm having the same issue, but with wp. I came here from #493.

$ lando version
v3.0.0-rc.1
$ uname -a
Linux machine 4.11.0-rc2+ #6 SMP Mon Oct 15 00:34:03 CDT 2018 x86_64 GNU/Linux

Here is a workaround:

• Add to .lando.yml

tooling:
  bash:
    service: appserver

• Add to bin/install-wp-cli.sh

#!/bin/bash

mkdir -p /var/www/.composer/vendor/bin
wget https://github.com/wp-cli/wp-cli/releases/download/v2.0.1/wp-cli-2.0.1.phar -O /var/www/.composer/vendor/bin/wp
chmod +x /var/www/.composer/vendor/bin/wp
wp --version

• Add to your CI script or whatever process you use to initialize and run tests

lando wp --version || lando bash bin/install-wp-cli.sh

I'm sure there is a better / more native way to structure this, but it seems to work fine this way.

[pirog]

@nylen @dsnopek @uberhacker i've finally got some free time so im going to try and check this out today

[nylen]

@pirog any update?

This is something about my local machine (possibly the kernel version) because this works totally fine on Travis CI.

I need to upgrade my kernel at some point, then I'll try again and report back.

[pirog]

@nylen i was only able to spend a few hours on it but i wasn't able to replicate using the various lando files posted above. And as you mention our tests for this run also run fine on TravisCI so it's been a bit tricky to track down.

I'm at BadCamp all week but next week our team is going to have way more dev cycles to devote back to the project so we can bump the RC1 from pre-release to official release. This issue is still high priority in my mind

[milkovsky]

solution for me - downgrade to 3.0.0-beta.47

[nathandentzau]

I'm also having this issue on Ubuntu 18.04. Here's the build output:

landoproxyhyperion5000gandalfedition_proxy_1 is up-to-date
Creating network "chromatic_default" with the default driver
Creating volume "chromatic_data" with default driver
Creating volume "chromatic_appserver" with default driver
Creating volume "chromatic_data_database" with default driver
Creating chromatic_appserver_1 ... done
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   600    0   600    0     0   1938      0 --:--:-- --:--:-- --:--:--  1941
100  303k  100  303k    0     0   300k      0  0:00:01  0:00:01 --:--:-- 1814k
Drush Launcher Version: 0.6.0
mv: cannot create regular file '/usr/local/bin/drush': Permission denied
error: Looks like one of your build steps failed with [object Object]
warn: This **MAY** prevent your app from working
warn: Check for errors above, fix them, and try again
Creating chromatic_database_1   ... done
Starting chromatic_appserver_1 ... done
Creating chromatic_nodejs_1     ... done
Creating chromatic_phpmyadmin_1 ... done
Waiting until phpmyadmin service is ready...
Waiting until nodejs service is ready...
Waiting until database service is ready...
Waiting until appserver service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Gathering patches for root package.
> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files
PHP CodeSniffer Config installed_paths set to ../../drupal/coder/coder_sniffer/
> DrupalProject\composer\ScriptHandler::createRequiredFiles

BOOMSHAKALAKA!!!

Your app has started up correctly.
Here are some vitals:

 NAME             chromatic
 LOCATION         /home/nathan/chromatic/chromatichq.com
 SERVICES         appserver, database, nodejs, phpmyadmin
 APPSERVER URLS   https://localhost:32791
                  http://localhost:32792
                  http://chromatic.lndo.site:8000
                  https://chromatic.lndo.site
 PHPMYADMIN URLS  http://localhost:32794

Here's the Lando info:

{
  "appserver": {
    "type": "php",
    "version": "7.2",
    "hostnames": [
      "appserver",
      "appserver.chromatic.internal"
    ],
    "via": "apache",
    "webroot": "web",
    "config": {
      "conf": "/home/nathan/.lando/services/config/drupal8/php.ini"
    },
    "urls": [
      "https://localhost:32803",
      "http://localhost:32804",
      "http://chromatic.lndo.site:8000",
      "https://chromatic.lndo.site"
    ]
  },
  "database": {
    "type": "mysql",
    "version": "5.7",
    "hostnames": [
      "database",
      "database.chromatic.internal"
    ],
    "creds": {
      "user": "drupal8",
      "password": "drupal8",
      "database": "drupal8"
    },
    "internal_connection": {
      "host": "database",
      "port": 3306
    },
    "external_connection": {
      "host": "localhost",
      "port": "32801"
    },
    "config": {
      "confd": "/home/nathan/.lando/services/config/drupal8/mysql"
    },
    "urls": []
  },
  "nodejs": {
    "type": "node",
    "version": "9",
    "hostnames": [
      "nodejs",
      "nodejs.chromatic.internal"
    ],
    "urls": []
  },
  "phpmyadmin": {
    "type": "phpmyadmin",
    "version": "4.7",
    "hostnames": [
      "phpmyadmin",
      "phpmyadmin.chromatic.internal"
    ],
    "urls": [
      "http://localhost:32802"
    ]
  }
}

[drupov]

I can also confirm that lando drush

• works for Drupal 7 & 8 with lando-v3.0.0-beta.47
• works for Drupal 8 with lando-v3.0.0-rc.1
• does not work for Drupal 7 with lando-v3.0.0-rc.1

[mchelen]

Update When I run Lando from source of either master 79f7674 or v3.0.0-rc.1 d9fcd3c there are no permissions errors, and lando drush works correctly.

I'm getting the same error:
mv: cannot create regular file '/usr/local/bin/drush': Permission denied
With Drupal 8 and:
Lando 3.0.0-rc.1
Xubuntu 18.04
4.15.0-38-generic #41-Ubuntu SMP

From a clean checkout of https://github.com/mchelen/drupal8-lando-sample:

$ lando start
Creating landoproxyhyperion5000gandalfedition_proxy_1 ... done
Creating network "drupal8landosample_default" with the default driver
Creating volume "drupal8landosample_data" with default driver
Creating volume "drupal8landosample_appserver" with default driver
Creating volume "drupal8landosample_data_database" with default driver
Creating drupal8landosample_appserver_1 ... done
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   600    0   600    0     0   4613      0 --:--:-- --:--:-- --:--:--  4651
100  303k  100  303k    0     0   812k      0 --:--:-- --:--:-- --:--:--  812k
Drush Launcher Version: 0.6.0
mv: cannot create regular file '/usr/local/bin/drush': Permission denied
error: Looks like one of your build steps failed with [object Object]
warn: This **MAY** prevent your app from working
warn: Check for errors above, fix them, and try again
Starting drupal8landosample_appserver_1 ... done
Creating drupal8landosample_database_1  ... done
Waiting until database service is ready...
Waiting until appserver service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...
Waiting until database service is ready...

BOOMSHAKALAKA!!!

Your app has started up correctly.
Here are some vitals:

 NAME            drupal8landosample                          
 LOCATION        /home/mchelen/doc/code/drupal8-lando-sample 
 SERVICES        appserver, database                         
 APPSERVER URLS  https://localhost:32958                     
                 http://localhost:32959                      
                 http://drupal8landosample.lndo.site:8000    
                 https://drupal8landosample.lndo.site 

$ lando drush
/bin/sh: 1: drush: not found

$ lando logs -s appserver     
Attaching to drupal8landosample_appserver_1
appserver_1  | user-perms.sh kicking off as user uid=0(root) gid=0(root) groups=0(root)
appserver_1  | Lando ENVVARS set at
appserver_1  | LANDO_WEBROOT_USER: www-data
appserver_1  | LANDO_WEBROOT_GROUP: www-data
appserver_1  | LANDO_WEBROOT_UID: 33
appserver_1  | LANDO_WEBROOT_GID: 33
appserver_1  | Making sure correct user:group (www-data:www-data) exists...
appserver_1  | 33
appserver_1  | 33
appserver_1  | Remapping ownership to handle Linux docker volume sharing...
appserver_1  | LANDO_HOST_UID: 1000
appserver_1  | LANDO_HOST_GID: 1000
appserver_1  | Resetting www-data:www-data from 33:33 to 1000:1000
appserver_1  | www-data:www-data is now running as uid=1000(www-data) gid=1000(www-data) groups=1000(www-data)!
appserver_1  | And here. we. go.
appserver_1  | Scanning /user/.ssh for keys...
appserver_1  | Scanning /lando/keys for keys...
appserver_1  | Checking whether /user/.ssh/id_rsa.mchelen is a private key...
appserver_1  | Checking whether /user/.ssh/id_rsa.mchelen is formatted correctly...
appserver_1  | Checking whether /user/.ssh/id_rsa is a private key...
appserver_1  | Checking whether /user/.ssh/id_rsa is formatted correctly...
appserver_1  | Checking whether /user/.ssh/config is a private key...
appserver_1  | Ensuring permissions for /user/.ssh/id_rsa.mchelen...
appserver_1  | Ensuring permissions for /user/.ssh/id_rsa...
appserver_1  | Using the following keys: /user/.ssh/id_rsa.mchelen /user/.ssh/id_rsa
appserver_1  | Enabling apache ssl modz
appserver_1  | Cert creation kicking off
appserver_1  | LANDO_CA_CERT: /lando/certs/lndo.site.pem
appserver_1  | LANDO_CA_KEY: /lando/certs/lndo.site.key
appserver_1  | CA_DIR: /usr/share/ca-certificates
appserver_1  | CA_CERT_FILENAME: lndo.site.pem
appserver_1  | CA_CERT_CONTAINER: /usr/share/ca-certificates/lndo.site.pem
appserver_1  | Generating certs...
appserver_1  | Generating RSA private key, 2048 bit long modulus
appserver_1  | ..................................................+++
appserver_1  | ...........................................................................................................................................+++
appserver_1  | e is 65537 (0x10001)
appserver_1  | Signature ok
appserver_1  | subject=/C=US/ST=California/L=San Francisco/O=Lando/OU=Bespin/CN=*.lndo.site
appserver_1  | Getting CA Private Key
appserver_1  | /usr/share/ca-certificates/lndo.site.pem not found... copying /lando/certs/lndo.site.pem over
appserver_1  | Running command docker-php-entrypoint sh -c a2enmod rewrite && apache2-foreground
appserver_1  | Enabling module rewrite.
appserver_1  | To activate the new configuration, you need to run:
appserver_1  |   service apache2 restart
appserver_1  | [Mon Nov 12 19:41:55.352923 2018] [core:warn] [pid 136] AH00111: Config variable ${BACKDROP_SETTINGS} is not defined
appserver_1  | [Mon Nov 12 19:41:55.353109 2018] [core:warn] [pid 136] AH00111: Config variable ${BACKDROP_SETTINGS} is not defined
appserver_1  | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.31.0.2. Set the 'ServerName' directive globally to suppress this message
appserver_1  | [Mon Nov 12 19:41:55.381961 2018] [core:warn] [pid 136] AH00111: Config variable ${BACKDROP_SETTINGS} is not defined
appserver_1  | [Mon Nov 12 19:41:55.382109 2018] [core:warn] [pid 136] AH00111: Config variable ${BACKDROP_SETTINGS} is not defined
appserver_1  | AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.31.0.2. Set the 'ServerName' directive globally to suppress this message
appserver_1  | [Mon Nov 12 19:41:55.419023 2018] [mpm_prefork:notice] [pid 136] AH00163: Apache/2.4.10 (Debian) PHP/7.1.22 OpenSSL/1.0.1t configured -- resuming normal operations
appserver_1  | [Mon Nov 12 19:41:55.419057 2018] [core:notice] [pid 136] AH00094: Command line: 'apache2 -D FOREGROUND'
appserver_1  | 172.24.0.2 - - [12/Nov/2018:19:42:13 +0000] "GET / HTTP/1.1" 302 553 "-" "axios/0.18.0"
appserver_1  | 172.24.0.2 - - [12/Nov/2018:19:42:13 +0000] "GET / HTTP/1.1" 302 553 "-" "axios/0.18.0"
appserver_1  | 172.31.0.1 - - [12/Nov/2018:19:42:13 +0000] "GET / HTTP/1.1" 302 2398 "-" "axios/0.18.0"
appserver_1  | 172.31.0.1 - - [12/Nov/2018:19:42:13 +0000] "GET / HTTP/1.1" 302 572 "-" "axios/0.18.0"

[kondor9]

I can reproduce this bug every time I want :) I've just installed on Ubuntu 18.04 a standalone version of Sophos Antivirus for Linux v.9. It provides so-called "on-access scanning":

Whenever you open, save or copy a file, Sophos Anti-Virus scans it and grants access to it only if it is safe.

Having this enabled I encounter a warning "mv: cannot create regular file '/usr/local/bin/drush': Permission denied" every time I run "lando start" or "lando rebuild". The problem vanishes when "on-access scanning" is switched off. I don't know if it is helpful but this way you can reproduce the error at least.

[dsnopek]

Hm. I haven't tested this, but this makes me wonder about something: PHPStorm uses inotify to monitor for file changes the same way an anti-virus program might...

[nylen]

I am not running any of the above programs or anything else that watches files using inotify.

[drupov]

First of all, my previous comment is not correct - I get the "drush not found" and basically cannot use lando drushfor BOTH "Drupal 7" and "Drupal 8" recipes. Sometimes it is ok, sometimes drush is not available (applies to both recipes).

To be in rather clean state of testing I remove stop and all containers and remove all docker images before spinning up these lando-projects.

Both recipes are very bare-bones, containing only

name: lando-drupal-7 # or lando-drupal-8
recipe: drupal7 # or drupal8
config:
  webroot: .

So again, this does not happen always. Cannot really find a pattern when, as these tests take some time.

What I have noticed though: on these projects it is enough to run lando destroy && lando start and drush is sometimes installed properly after that. And then there was also a case where it did not want to install.

[kondor9]

That's true. In general I face the same behaviour as @drupov does. I can confirm that running "lando rebuild" usually solves the problem but as I've mentioned earlier it doesn't work when antivirus "on-access scanning" is on.

[drupov]

Maybe we should change the title of the issue (right now it contains "Drupal 7", whereas it is not connected to a Drupal version).

I also checked now several times on a very clean Ubuntu Server 18.04 LTS (no antivirus there, no PHPStorm). Absolutely same behaviour - drush is available/unavailable inconsistently:

I tested several times by running
lando destroy -y && docker stop $(docker ps -a -q) && docker rm $(docker ps -a -q) && docker rmi $(docker images -q) && lando start && lando drush
in the project (so destroying the project, removing containers and images and starting over again). I'd say on roughly 85% of the cases drush was installed ok, the others not.

[dsnopek]

Maybe we should change the title of the issue (right now it contains "Drupal 7", whereas it is not connected to a Drupal version).

👍 to a title change!

[martin-klima]

I had this problem several times a day on D7 + D8 projects. When I got

$ lando drush
/bin/sh: 1: drush: not found

I tried to find drush in the appserver container, but drush not found.
root@e0e...57:/app# find / -name drush | grep bin
No drush relevant info in appserver log. I had to destroy project and start again + import DB every time. I used Lando v3.0.0-rc.1 and Docker version 18.06.1-ce, build e68fc7a on Linux Mint (Linux 4.15.0-33-generic GNU/Linux).
Today I upgraded Docker (sudo apt-get install docker-ce) to Docker version 18.09.0, build 4d60db4 and since then I've been constantly testing
lando stop && lando start && lando drush
on two projects simultaneously and drush works every time with no exception. I'm not sure, if it is the cause of the problem, but it seems to have helped me.

UPDATE ater 2 days:

I created a new project with only simple drupal8 recipe and got this error during first start.

Creating dcd1_appserver_1 ... done
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   600    0   600    0     0   1446      0 --:--:-- --:--:-- --:--:--  1445
100  303k  100  303k    0     0   197k      0  0:00:01  0:00:01 --:--:--  845k
Drush Launcher Version: 0.6.0
mv: cannot create regular file '/usr/local/bin/drush': Permission denied
error: Looks like one of your build steps failed with [object Object]
warn: This **MAY** prevent your app from working

After lando destroy and start again Drush was installed properly.

[jb044]

We are also facing this problem with lando, that is drush sometimes gets installed just fine and sometimes we get the permission error. Any news on when we can expect a new release candidate or other version which solves the underlying problem?

[nigelwhite]

I am also getting

lando drush
/bin/sh: 1: drush: not found

on a drupal 8 project. It was running drush fine, from the same lando.yml a few days ago.

Tried lando rebuild. No difference

Lando v3.0.0-beta.47
Docker 18.09.0, build 4d60db4

Can't work out what has changed.....

EDIT. Ah.... I updated Atom and it started working again.
EDIT some days later. Same problem on Drupal 7. Lando rebuild sorted it out.

[pirog]

Closing this in favor of #1227