MySQL access denied problem

Since drush is bootstrapping Drupal with the current user account, it would seem that your site is trying to reach the database with the default account, which normally would be the webserver account.

One thing to try is to change the $db_url in your settings.php file so that it contains an explicit username/password for a MySQL account that is known to work on the site database.

Other than that, your MySQL server may be configured to restrict access in other ways, but that is certainly not a drush issue.

here's a strange one for you:

Im on drupal6 hosted at dreamhost and connect to mysql via mysqli. My site's up and running and I know my settings.php file is good. Drush is configured properly but dumps html. I think I've found what the culprit may be...

My mysql user password contains an '%' symbol. I need to encode this as '%25' in my mysqli connect string in settings.php.

Will Drush encode '%25' into a '%' ?

thx for a great module and toolset!
pp

On Dreamhost, this happened to me when using the php4 php-cli binary, (the one in path). Everything works with php5, which I think they keep in /usr/local/php5/bin/php. This is strange as I did not see anywhere that drush is php5 only. Maybe string handling between php4 and php5 is different on Dreamhost, causing problems if you setup your site to use php5 and use php4 on the command line.

Wth php5 on Pair Networks, drush cannot bootstrap the database, but does not dump html. Same codebase on Mediatemple, no problems. This looks related to database security and how php is allowed to interact with the rest of the system. It would be interesting to get to the bottom of these errors and pinpoint the settings that block drush.

Also running across something similar here, one interesting point is that drush was able to bootstrap before sync'ing to HEAD.

Running this on a debian lenny local server, using virtual sites. Some minor things I've toyed with since upgrading to HEAD.

1. Updated drush_extras to alpha1
2. The mysql site uri needed to be set explicitly.
3. After reading ppmax's issue, I tried wrapping the $db_url in rawurlencode(), no dice.
4. Made sure that sites/default/default.settings.php wasn't interfering with the real settings.php

The last obvious thing is that this test install has the correct auth. It's otherwise working great. Definitely willing to help out with debugging if anyone has anymore ideas.

Its also curious that the drush pm commands are now gone from the 'drush help' cli.

Commands:
help
dl
sql conf
sql version server
sql version client
sql dump
sql query
sql load
sql cli

Just an update to this thread. I may be chasing my tail on this one. Since it appears that the old style of drush pm commands may be deprecated, I shouldn't even be attempting to use the drush_extras package.

Since all the old extras includes are being merged into drush HEAD, I was just having collisions.

Wanted to throw that out there, just in case others were in-between upgrading 6.x-1-2 -> HEAD.

After a lot of head banging I have come to the conclusion that a lot of seeming database issues are in fact file permission issues.

Drush works by invoking a lot of code of Drupal itself. As the user id of the different php processes is different on different hosts etc., it is possible that the cli version of php simply has not enough permissions to run some files, (be it because simply it has not even got read access to files!). Then drush may throw an error message stating database connection failures, etc. In fact, it has not had the opportunity to even run the relevant Drupal function.

So you may have to add group or world permissions to some files in order to get up and running.

executing drush with HEAD from april 14 also gives me MySQL access denied. Ludovicof, could you explain further what you mean with changing file permissions? Are you referring to permissions on the settings.php file?
Thanks

[edit] Never mind, I found out that my problem is caused by what ppmax mentions above: I have an $ in my database password which is preventing drush from bootstrapping the database. Opening a new issue (#433652: special shell characters in password aren't being escaped, triggering MySQL access denied), didn't mean to hijack this one.

Perhaps Adrian can see if we are handling decoding of these passwords properly.

no open issue here.