Aug 142011

AN Hosting recently relocated to a Seattle datacenter. As part of this process, my site is now running on a much more modern server (AMD Opteron 6100-series Magny Cours vs. Intel Xeon 5400-series Harpertown).

Unfortunately, a new server and new install can mean software changes. AN Hosting has tightened up the security settings on PHP. Better security is always a good thing, but it means the Drupal command line utility drush no longer works out of the box. (For those that don’t know drush – please give it a chance. It provides near foolproof Drupal core/module/theme upgrades as well as command-line control of your Drupal sites.)

This was the error I received when running drush status:

The following restricted PHP modes have non-empty values: [error]
disable_functions. This configuration is incompatible with drush.
Please check your configuration settings in /usr/local/lib/php.ini or
in your drush.ini file; see examples/example.drush.ini for details.

The fix is easy – you simply have to give drush its own php.ini file with looser security. The benefit here is that the Apache web server will run PHP in a more locked-down mode, but drush will operate with full permissions. SSH into your server and run the following commands:

mkdir -p ~/.drush
cp -i /usr/local/lib/php.ini ~/.drush/

Note that if there is already a php.ini file in .drush/ it would be safer not to overwrite it (but hopefully you know what you’re doing if that file already exists). Leave the file as-is and modify the line below.

Edit the text file ~/.drush/php.ini and make sure the line with disable_functions is empty:

disable_functions =

That’s it! You can run drush status to make sure everything is working properly. If drush reports additional errors, you may need to make further changes to the php.ini file.

These instructions aren’t strictly limited to the AN Hosting servers. This should work on any host which provides shell access (required to use drush). Much of this flexibility is not limited to drush – PHP has long been configured to use separate php.ini files for the shell and the web server. This allows logged-in users to have greater permissions than the public-facing web server. Take a look at the drush README for additional tricks, such as passing command-line parameters to PHP and running different versions of PHP than the web server uses.

  16 Responses to “Drush on AN Hosting – Fix Using Custom php.ini”

Comments (16)
  1. Hey Eliot

    You saved my bacon.

    Thanks a bunch.


  2. Followed the instructions and it works, but only as the root user. If I SSH into a site, drush is still using the server wide php.ini file. Do I need to create an alias or something, sorry, I’m new to this. Thanks.

    • My first guess is that you created the .drush/ directory as root. You need to create that directory in the home directory of each user you’ll be using.

      If you’re still having trouble, I believe it’s possible to tell php/drush which .ini file to use as a command-line option.

  3. super super helpful.. Thank you..

    updated my drush install.. and got all these enigmatic errors.. ; your blog came up w. a google search and was exactly what I needed.. thanks..

  4. If you run into this issue, Technical Support would be happy to help you out by making this adjustment to your accounts php.ini file.

    Just email us


  5. Just what I needed. Thanks for the tip.

  6. Awesome. Just had the same issue on AN Hosting. Thanks!

  7. Thanks a lot :) ! It works great !

  8. I just used the php.ini trick for GreenGeeks shared hosting. I had to uncomment the safe_mode and magic_quotes lines and it worked! Thanks a million.

  9. Excellent!

    I searched and searched, and yours was the answer I needed.


  10. Thank you very much for your help!!!

  11. Thanks for help!

  12. It works like a charm.

    Thank you!

  13. Thank you so much for this. I knew it would involve cloning php.ini but I don’t have the system admin knowledge of knowing what to actually change in that file to make the errors go away.

    Drush was actually working fine, it would just clutter up the command line but screaming errors everytime it would try to execute a task.

    Thank you so much for this guide Elliot, not only by providing the step-by-step instructions on how to fix this problem but also explaining it clearly so that anyone reading this learned something new rather than just copying and pasting an answer and hoping for the best.

    Kind Regards,
    Peter Macinkovic | Melbourne, Australia

  14. It worked again after having forgot your initial instructions to me.

    Thank you very much for taking time out to help others!! To have a clear procedure to do something like this is very rare. But to have this together with the reasoning behind it is unheard of. Thanks again!

    -Frederico Garza

  15. This is brilliant. Thanks! I didn’t think this would work on a very limited, locked down shared hosting account, but no problem. I usually have at least a VPS to work with and haven’t tried running drush on shared hosting in many years, so I thought I was just screwed, but this was a lifesaver.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(to be displayed above your comment)

(for moderation; your e-mail address will not be made public)