I have a bunch of sites on my local machine and have been using Drush (v5.4) happily for a long time to administer them.

All of a sudden, with no changes made to one such site, Drush reports these errors:

Command pm-disable needs a higher bootstrap level to run - you will need invoke drush from a more functional Drupal environment to run this command.

The drush command 'dis addthis' could not be executed.

Drush was not able to start (bootstrap) the Drupal database. Hint: This error often occurs when Drush is trying to bootstrap a site that has not been installed or does not have a configured database.

Needless to say the site in question is running fine on the local machine with no errors (and is completely installed). Drush works fine for every other site on the machine.

What can cause Drush to suddenly misbehave like this for one particular site?

  • What is the output of drush status?
    – Sam Becker
    Jul 9, 2012 at 13:07
  • It says there's a permissions problem with the site's settings.php...I've checked, there isn't
    – Clive
    Jul 9, 2012 at 13:10
  • Not to worry, running it as root fixes the error. Will just have to live with it for this site I guess
    – Clive
    Jul 9, 2012 at 13:11
  • Have you ensured that your sites directory is owned by the correct user and has the correct permissions?
    – Sam Becker
    Jul 9, 2012 at 13:49
  • @Sam152: Yep, permissions are the same as every other site on my machine and Drush works fine on all of those
    – Clive
    Jul 9, 2012 at 13:50

2 Answers 2


Drush, being run from the command line might have different permissions than the web server. Essentially your site can work correctly but some files might be in accessible from drush. If you are running into errors you might want to ensure that the group permissions of your entire Drupal site are set correctly by running:

chown -R owner:group sites_directory

If you run into permission denied errors as the result of running chown, run it as sudo or contact your system administrator.

  • Just be careful when you do this. Doing it on sites/ can cause sites/default/files (or whatever your files dir is) to become unwritable by the webserver. I typically follow the above command with shown -R apache.apache sites/default/files/
    – mpdonadio
    Jul 10, 2012 at 1:05
  • I guess it depends on the server setup. My understanding is that the webserver should be running as the user that is the account is setup under, in a cPanel environment anyway.
    – Sam Becker
    Jul 10, 2012 at 2:05
  • Having Apache be able to write to the site code is a bit of a security risk. Ideally, it should be limited to write access to the private and public file paths.
    – mpdonadio
    Jul 10, 2012 at 10:34

I cannot answer why this happens, but I have a site that periodically does this with drush pm-enable. I think this site has trouble doing the nightly module update check, and something bad gets cached. A drush cc all always fixes it.

  • Thanks, unfortunately drush cc all also fails with the same error message. Weird
    – Clive
    Jul 9, 2012 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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