I randomly got this error and it shows the username for my database.

PDOException: SQLSTATE[28000] [1045] Access denied for user '******'@'localhost' (using password: YES) in lock_may_be_available() (line 165 of /home/*****/public_html/******.com/includes/lock.inc).

What exactly do I do? It's completely random. I accessed the site last night. No problems. Now this. Suggestions?

Comments

same error ... mine spits out Dreamhost shenanigans.

PDOException: SQLSTATE[28000] [1045] Access denied for user '***'@'apache2-**.dreamhost.com' (using password: YES) in lock_may_be_available() (line 165 of /home/**/**.INFO/includes/lock.inc).

Thanks everyone!

I was having the same error message when starting an existing project on another computer. As the repository wasn't online already, I had to copy the whole D7 folder from PC1 to PC2, and import the database in phpMyAdmin. I've got this error as result when accessing my (localhost) homepage. So I went looking in the users table where I found the problem, the Drupal user for the database was missing.
To solve this problem, I started with removing the whole database. Next step I created a new user and database in phpMyAdmin, following this steps. When the users has been created, the next step is to import the existing database. To do so, I've deleted the (empty) database to prevent error messages about the database already existing. Now you can import the database of your project and you're ready to go.
I realize this might take some detour, but it's a pretty basic solution and not hard to understand for newbies like me. And it worked for me!

This proposal above worked for me, thanks!

In summary, this is what I did:

  • I deleted the old database tables (make sure you have a backup copy!)
  • I deleted the /sites/default/settings.php file (again, make sure you have a copy). This forces Drupal to recreate the site.
  • When the empty site is working, delete the database tables, and copy the backup database back onto them.

drupalshrek
Maintainer of the Flipcard module visible in use at the website to learn French and learn Thai

Followed same steps to re-install Drupal n then Backing my exported DB..

Thanks Buddy ...

shree yesare

In the first place, make sure you checked the property "Add DROP TABLE / VIEW / PROCEDURE / FUNCTION" on the Structure part of phpMyAdmin export, and not leave it with default properties.
If you not sure, go back and make the export to the database again.

I fiddled with settings, removed and added databases, nothing worked. I had to remove all users (both through phpadmin and through cpanel) then re-add the users. It didn't want to accept the users I created on my computer, using localhost.

Got this error after site was disabled, put offline during a backup.
When site came online this error showed for the Drupal MySQL DB.

The system thinks the drupal 'user' is still logged in and that user account in the database has a 'lock' set for it. If you are a database person, you may be able to merely reset the lock within the database; else, reset the account for drupal by swapping it with a new user account.

1. Locate the 'settings.php' file (should be in [drupal home dir]/sites/default/settings.php)
a. Find the "$databases = array ( 'default' => ..........." entry
b. The above should have the name of your database and user account information.

2. Create a new user account for the identified drupal database.
a. In my case I also gave it the exact same password, that is found in the settings.php.
b. Give it the same permissions as the original account that is listed in the settings.php.

3. Change the settings.php file 'username' entry to the new account name you created.
a. NOTE: the settings.php file has permissions set to read-only. You will have to temporarily change this to Read-Write to modify it - then change it back when done.
b. Enter the password IF you gave the new account a different password.
c. Save changes

4. Test that you can now access your site / database.
a. You can probably delete the old account name from the MySQL database after all is verified.

If this doesn't work for you, read below...some have provided more detailed actions on creating a new account name, creating a new database, and copying the old tables to the new database. Hopefully this works and you won't have to do the extra work; otherwise, it's a far better choice than rebuilding everything.

Omki Sol

A lot of interesting and helpful remedies on the entire thread. Circumstances are different for all of us -- on the installation I'm using , file/folder permissions are a total mess. That said, I used PHPMyAdmin simply to reset the password and everything came roaring back.

This took me days ...

Great Job, Thanx Omki

I have been duplicating db in order to populate new sites on a multisite and I reusing the same mysql db user.Creating brand-new user and changing the settings.php accordingly solved the issue for me. Thank you for taking the time to explain.

In my case I also gave it the exact same password

I had to do some development for the website, downloaded complete website and the db to local machine and created a new user for the database to access the imported db. Updated settings.php with this new username but I was getting the above error. I had to use the same username and password and everything started working back! Thanks!

Raj Pawan G

Thank you Omki Sol

you helped me

There are error questions here without answers despite someone posting "thanks everyone."

I received this same error. I looked at this forum http://bitnami.org/forums/forums/drupal/topics/drupal-7-install-problems-2 of a posting from someone with a similar error but nothing I modified improved the situation.

This looks like a mysql error. MySQL is not getting fed the correct logon information. Can you logon to mysql using your drupal credentials - either by command line or PHPMyAdmin or some other method. If you can't logon it's a credentials problem. Otherwise it's likely a path problem.

My web host has PHPMyAdmin but I access that by logging into my account, not specifically for MySQL. I am able to access my Drupal database using PHPMyAdmin.

That may be, but who is PHPMyAdmin logging in as? As your Drupal user? Or as root? Drupal may need to have access and permissions granted.

Thanks rpruitt625! I changed the settings.php userid to root and that resolved the problem. I then found that the drupal userid I was previously using had 'host' set to % where root had localhost. Changed my drupal userid to match root and updated settings.php with my original userid and that issue is now closed.

I am having this same issue, I have changed the MySql DB password and changed it back again, still have this problem.

I'm in the middle of developing this site so this is a real hairy problem...

I am using the Bartik Theme and was having trouble getting my logo image to display, it was properly listed but after checking and unchecking the logo display options, it still wasn't appearing so I uploaded it again (it was assigned the same filename, drupal/mysql appended _0 on the end of the file name) the logo displayed.

I changed the filename in the path (still in theme settings here) back to the original filename (no appended _0) and boom, the logo wouldn't display...yes, both files are still on the server in their original locations.

That's when I logged into the DB via phpmyadmin (pair networks) to take a look at how the DB was handling the image info (path and whatnot) (I was at a loss for why this was happening and just wanted to start ruling out weirdness possibilities)

I went back to my drupal site to play with Bartik theme some more (after not finding any DB weirdness)

AND BAM!!

that's when i got this message too - referencing the same line of code.

Hope this helps because I really don't want to lose several days of constant work...

Don't panic! Whatever you do, don't panic! Unless, of course, you didn't make a backup - then by all means freak out...

Anyone have a viable solution for this.

We were using a remote DB, then it all went horribly wrong. So we've moved back to a Local Dev build.
But having hacked WAMP to get it to work with Drupal7's requirements, we have now hit this error.

My PHP is Okay my MySql is not so great. I have tried to reconfigure the DB and grant new permissions, but I'm struggling and this seems to be a bit off the beaten track for Drupal solutions - and I have wondered into DB hacking.

From what I can see there is a conflict between the permissions for WAMP and for the D7 Db. But for the life of me I can't seem to find the correct configuration. Does anyone have any pointers they might be able to suggest or where I should be looking.

Thanks in advance. Like Audster, I am in the same boat. We have a launch deadline of March 1st and still plenty left to do.

If your in the UK or near Philly, we can buy you a beer!

Thanks/Beer in advance.

I had exactly the same error, checked Google and went through every post, and found some who had sorted it by finding a discrepancy between their database and username settings.

Kept checking my settings.php file and they seemed OK and I've been tearing my hair out over this.

Eventually sorted when I realized that in my settings.php file I had typed a one letter error in my database name (It was longer on my test site, but shorter on my production site)

I know it sounds silly (I checked my file half a dozen times before seeing the error) but someone else may have same problem.

In the settings.php file

$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'MYDATABASENAME',
      'username' => 'MYUSERNAME',
      'password' => 'MYPASSWORD',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);

The databasename, username, and password all need to be correct (obviously). In my case one letter resulted in the error.

Hope this helps someone else.

10x! It's really helps! :)

In the beer - the force,
In the wine - a wisdom,
And in the water - microbes!

I managed to correct this error in about 10 minutes after reading this post. Thanks!

For some reason when I was trying to do a phpmyadmin database dump to transfer to another site the database user's password in my original settings.php file was changed. Not sure how that happened but changing it back solved the problem

Bingo. Thank you. The password was wrong in the settings.php file Since it is a read only file, I used the wrong password and made it my new password in MySQL

Again - as other on this post, I solved the problem by correcting a silly typo in settings file...look, look then look again...

--

Yep! I also checked my settings file repeatedly and didn't see the typo -- even though it was also visible in the error message. "Check the settings file one more time" was exactly the advice I needed (next time I have a problem I'll also remember to check whether caps lock is on and whether my computer is plugged in). Thank you!!

I went off on a bit of a wild goose chase because I thought that table locking might require slightly different permissions than regular database access. But I guess this is just the first database operation drupal tries, so if your credentials are wrong, it's the one that's going to fail. Seems like that would be a good place for a custom error message saying "the site was unable to access the database at all; please check your credentials."

Absolutely awesome! This is exactly the answer I needed: problem solved in less than two minutes. Thank you!

Thank you so much for that, such a simple solution of not having the correct DB password suddenly after my hosting made me change my cPanel login.

Took three days or so for the error to surface and was easily corrected by putting the correct DB password in the settings.php file.

Peter Macinkovic, Project Manager

My personal website proudly built on

I think I get the answer,the error happens because of the file settings.php we have copied from the backups for the upgrade.we followed upgrade steps (see http://drupal.org/node/570162),especially in step 8,they said,'Copy your backed up "files" and "sites" directories to the Drupal installation directory.'but by comparing the code of settings.php in D6 &D7,I find there are some differences between them,for example,about $drupal_hash_salt.the older version of setting.php in new installation doesn't completely work,that's why the error remains after checking the databasename, username, and password time and time again.when I copy a settings.php made automatically by D7 installation and modify for my drupal site,the problem is resolved.

here is settings.php in D6

<?php
// $Id: default.settings.php,v 1.8.2.4 2009/09/14 12:59:18 goba Exp $
/**
* @file
* Drupal site-specific configuration file.
*
* IMPORTANT NOTE:
* This file may have been set to read-only by the Drupal installation
* program. If you make changes to this file, be sure to protect it again
* after making your modifications. Failure to remove write permissions
* to this file is a security risk.
*
* The configuration file to be loaded is based upon the rules below.
*
* The configuration directory will be discovered by stripping the
* website's hostname from left to right and pathname from right to
* left. The first configuration file found will be used and any
* others will be ignored. If no other configuration file is found
* then the default configuration file at 'sites/default' will be used.
*
* For example, for a fictitious site installed at
* http://www.drupal.org/mysite/test/, the 'settings.php'
* is searched in the following directories:
*
*  1. sites/www.drupal.org.mysite.test
*  2. sites/drupal.org.mysite.test
*  3. sites/org.mysite.test
*
*  4. sites/www.drupal.org.mysite
*  5. sites/drupal.org.mysite
*  6. sites/org.mysite
*
*  7. sites/www.drupal.org
*  8. sites/drupal.org
*  9. sites/org
*
* 10. sites/default
*
* If you are installing on a non-standard port number, prefix the
* hostname with that number. For example,
* http://www.drupal.org:8080/mysite/test/ could be loaded from
* sites/8080.www.drupal.org.mysite.test/.
*/
/**
* Database settings:
*
* Note that the $db_url variable gets parsed using PHP's built-in
* URL parser (i.e. using the "parse_url()" function) so make sure
* not to confuse the parser. If your username, password
* or database name contain characters used to delineate
* $db_url parts, you can escape them via URI hex encodings:
*
*   : = %3a   / = %2f   @ = %40
*   + = %2b   ( = %28   ) = %29
*   ? = %3f   = = %3d   & = %26
*
* To specify multiple connections to be used in your site (i.e. for
* complex custom modules) you can also specify an associative array
* of $db_url variables with the 'default' element used until otherwise
* requested.
*
* You can optionally set prefixes for some or all database table names
* by using the $db_prefix setting. If a prefix is specified, the table
* name will be prepended with its value. Be sure to use valid database
* characters only, usually alphanumeric and underscore. If no prefixes
* are desired, leave it as an empty string ''.
*
* To have all database names prefixed, set $db_prefix as a string:
*
*   $db_prefix = 'main_';
*
* To provide prefixes for specific tables, set $db_prefix as an array.
* The array's keys are the table names and the values are the prefixes.
* The 'default' element holds the prefix for any tables not specified
* elsewhere in the array. Example:
*
*   $db_prefix = array(
*     'default'   => 'main_',
*     'users'     => 'shared_',
*     'sessions'  => 'shared_',
*     'role'      => 'shared_',
*     'authmap'   => 'shared_',
*   );
*
* Database URL format:
*   $db_url = 'mysql://username:password@localhost/databasename';
*   $db_url = 'mysqli://username:password@localhost/databasename';
*   $db_url = 'pgsql://username:password@localhost/databasename';
*/
$db_url = 'mysql://username:password@localhost/databasename';
$db_prefix = '';
/**
* Access control for update.php script
*
* If you are updating your Drupal installation using the update.php script
* being not logged in as administrator, you will need to modify the access
* check statement below. Change the FALSE to a TRUE to disable the access
* check. After finishing the upgrade, be sure to open this file again
* and change the TRUE back to a FALSE!
*/
$update_free_access = FALSE;
/**
* Base URL (optional).
*
* If you are experiencing issues with different site domains,
* uncomment the Base URL statement below (remove the leading hash sign)
* and fill in the absolute URL to your Drupal installation.
*
* You might also want to force users to use a given domain.
* See the .htaccess file for more information.
*
* Examples:
*   $base_url = 'http://www.example.com';
*   $base_url = 'http://www.example.com:8888';
*   $base_url = 'http://www.example.com/drupal';
*   $base_url = 'https://www.example.com:8888/drupal';
*
* It is not allowed to have a trailing slash; Drupal will add it
* for you.
*/
# $base_url = 'http://www.example.com';  // NO trailing slash!
/**
* PHP settings:
*
* To see what PHP settings are possible, including whether they can
* be set at runtime (ie., when ini_set() occurs), read the PHP
* documentation at http://www.php.net/manual/en/ini.php#ini.list
* and take a look at the .htaccess file to see which non-runtime
* settings are used there. Settings defined here should not be
* duplicated there so as to avoid conflict issues.
*/
ini_set('arg_separator.output',     '&amp;');
ini_set('magic_quotes_runtime',     0);
ini_set('magic_quotes_sybase',      0);
ini_set('session.cache_expire',     200000);
ini_set('session.cache_limiter',    'none');
ini_set('session.cookie_lifetime',  2000000);
ini_set('session.gc_maxlifetime',   200000);
ini_set('session.save_handler',     'user');
ini_set('session.use_cookies',      1);
ini_set('session.use_only_cookies', 1);
ini_set('session.use_trans_sid',    0);
ini_set('url_rewriter.tags',        '');
/**
* If you encounter a situation where users post a large amount of text, and
* the result is stripped out upon viewing but can still be edited, Drupal's
* output filter may not have sufficient memory to process it. If you
* experience this issue, you may wish to uncomment the following two lines
* and increase the limits of these variables. For more information, see
* http://php.net/manual/en/pcre.configuration.php.
*/
# ini_set('pcre.backtrack_limit', 200000);
# ini_set('pcre.recursion_limit', 200000);
/**
* Drupal automatically generates a unique session cookie name for each site
* based on on its full domain name. If you have multiple domains pointing at
* the same Drupal site, you can either redirect them all to a single domain
* (see comment in .htaccess), or uncomment the line below and specify their
* shared base domain. Doing so assures that users remain logged in as they
* cross between your various domains.
*/
# $cookie_domain = 'example.com';
/**
* Variable overrides:
*
* To override specific entries in the 'variable' table for this site,
* set them here. You usually don't need to use this feature. This is
* useful in a configuration file for a vhost or directory, rather than
* the default settings.php. Any configuration setting from the 'variable'
* table can be given a new value. Note that any values you provide in
* these variable overrides will not be modifiable from the Drupal
* administration interface.
*
* Remove the leading hash signs to enable.
*/
$conf = array(
#   'site_name' => 'My Drupal site',
#   'theme_default' => 'minnelli',
#   'anonymous' => 'Visitor',
/**
* A custom theme can be set for the off-line page. This applies when the site
* is explicitly set to off-line mode through the administration page or when
* the database is inactive due to an error. It can be set through the
* 'maintenance_theme' key. The template file should also be copied into the
* theme. It is located inside 'modules/system/maintenance-page.tpl.php'.
* Note: This setting does not apply to installation and update pages.
*/
'maintenance_theme' => 'garland',
/**
* reverse_proxy accepts a boolean value.
*
* Enable this setting to determine the correct IP address of the remote
* client by examining information stored in the X-Forwarded-For headers.
* X-Forwarded-For headers are a standard mechanism for identifying client
* systems connecting through a reverse proxy server, such as Squid or
* Pound. Reverse proxy servers are often used to enhance the performance
* of heavily visited sites and may also provide other site caching,
* security or encryption benefits. If this Drupal installation operates
* behind a reverse proxy, this setting should be enabled so that correct
* IP address information is captured in Drupal's session management,
* logging, statistics and access management systems; if you are unsure
* about this setting, do not have a reverse proxy, or Drupal operates in
* a shared hosting environment, this setting should be set to disabled.
*/
#   'reverse_proxy' => TRUE,
/**
* reverse_proxy accepts an array of IP addresses.
*
* Each element of this array is the IP address of any of your reverse
* proxies. Filling this array Drupal will trust the information stored
* in the X-Forwarded-For headers only if Remote IP address is one of
* these, that is the request reaches the web server from one of your
* reverse proxies. Otherwise, the client could directly connect to
* your web server spoofing the X-Forwarded-For headers.
*/
#   'reverse_proxy_addresses' => array('a.b.c.d', ...),
);
/**
* String overrides:
*
* To override specific strings on your site with or without enabling locale
* module, add an entry to this list. This functionality allows you to change
* a small number of your site's default English language interface strings.
*
* Remove the leading hash signs to enable.
*/
# $conf['locale_custom_strings_en'] = array(
#   'forum'      => 'Discussion board',
#   '@count min' => '@count minutes',
# );

here is settings.php in D7
<?php
// $Id: default.settings.php,v 1.51 2010/10/11 23:49:48 dries Exp $
/**
* @file
* Drupal site-specific configuration file.
*
* IMPORTANT NOTE:
* This file may have been set to read-only by the Drupal installation
* program. If you make changes to this file, be sure to protect it again
* after making your modifications. Failure to remove write permissions
* to this file is a security risk.
*
* The configuration file to be loaded is based upon the rules below.
*
* The configuration directory will be discovered by stripping the
* website's hostname from left to right and pathname from right to
* left. The first configuration file found will be used and any
* others will be ignored. If no other configuration file is found
* then the default configuration file at 'sites/default' will be used.
*
* For example, for a fictitious site installed at
* http://www.drupal.org/mysite/test/, the 'settings.php'
* is searched in the following directories:
*
*  1. sites/www.drupal.org.mysite.test
*  2. sites/drupal.org.mysite.test
*  3. sites/org.mysite.test
*
*  4. sites/www.drupal.org.mysite
*  5. sites/drupal.org.mysite
*  6. sites/org.mysite
*
*  7. sites/www.drupal.org
*  8. sites/drupal.org
*  9. sites/org
*
* 10. sites/default
*
* If you are installing on a non-standard port number, prefix the
* hostname with that number. For example,
* http://www.drupal.org:8080/mysite/test/ could be loaded from
* sites/8080.www.drupal.org.mysite.test/.
*/
/**
* Database settings:
*
* The $databases array specifies the database connection or
* connections that Drupal may use.  Drupal is able to connect
* to multiple databases, including multiple types of databases,
* during the same request.
*
* Each database connection is specified as an array of settings,
* similar to the following:
* @code
* array(
*   'driver' => 'mysql',
*   'database' => 'databasename',
*   'username' => 'username',
*   'password' => 'password',
*   'host' => 'localhost',
*   'port' => 3306,
*   'prefix' => 'myprefix_',
*   'collation' => 'utf8_general_ci',
* );
* @endcode
*
* The "driver" property indicates what Drupal database driver the
* connection should use.  This is usually the same as the name of the
* database type, such as mysql or sqlite, but not always.  The other
* properties will vary depending on the driver.  For SQLite, you must
* specify a database file name in a directory that is writable by the
* webserver.  For most other drivers, you must specify a
* username, password, host, and database name.
*
* Some database engines support transactions.  In order to enable
* transaction support for a given database, set the 'transactions' key
* to TRUE.  To disable it, set it to FALSE.  Note that the default value
* varies by driver.  For MySQL, the default is FALSE since MyISAM tables
* do not support transactions.
*
* For each database, you may optionally specify multiple "target" databases.
* A target database allows Drupal to try to send certain queries to a
* different database if it can but fall back to the default connection if not.
* That is useful for master/slave replication, as Drupal may try to connect
* to a slave server when appropriate and if one is not available will simply
* fall back to the single master server.
*
* The general format for the $databases array is as follows:
* @code
* $databases['default']['default'] = $info_array;
* $databases['default']['slave'][] = $info_array;
* $databases['default']['slave'][] = $info_array;
* $databases['extra']['default'] = $info_array;
* @endcode
*
* In the above example, $info_array is an array of settings described above.
* The first line sets a "default" database that has one master database
* (the second level default).  The second and third lines create an array
* of potential slave databases.  Drupal will select one at random for a given
* request as needed.  The fourth line creates a new database with a name of
* "extra".
*
* For a single database configuration, the following is sufficient:
* @code
* $databases['default']['default'] = array(
*   'driver' => 'mysql',
*   'database' => 'databasename',
*   'username' => 'username',
*   'password' => 'password',
*   'host' => 'localhost',
*   'prefix' => 'main_',
*   'collation' => 'utf8_general_ci',
* );
* @endcode
*
* You can optionally set prefixes for some or all database table names
* by using the 'prefix' setting. If a prefix is specified, the table
* name will be prepended with its value. Be sure to use valid database
* characters only, usually alphanumeric and underscore. If no prefixes
* are desired, leave it as an empty string ''.
*
* To have all database names prefixed, set 'prefix' as a string:
* @code
*   'prefix' => 'main_',
* @endcode
* To provide prefixes for specific tables, set 'prefix' as an array.
* The array's keys are the table names and the values are the prefixes.
* The 'default' element is mandatory and holds the prefix for any tables
* not specified elsewhere in the array. Example:
* @code
*   'prefix' => array(
*     'default'   => 'main_',
*     'users'     => 'shared_',
*     'sessions'  => 'shared_',
*     'role'      => 'shared_',
*     'authmap'   => 'shared_',
*   ),
* @endcode
* You can also use a reference to a schema/database as a prefix. This maybe
* useful if your Drupal installation exists in a schema that is not the default
* or you want to access several databases from the same code base at the same
* time.
* Example:
* @code
*   'prefix' => array(
*     'default'   => 'main.',
*     'users'     => 'shared.',
*     'sessions'  => 'shared.',
*     'role'      => 'shared.',
*     'authmap'   => 'shared.',
*   );
* @endcode
* NOTE: MySQL and SQLite's definition of a schema is a database.
*
* Database configuration format:
* @code
*   $databases['default']['default'] = array(
*     'driver' => 'mysql',
*     'database' => 'databasename',
*     'username' => 'username',
*     'password' => 'password',
*     'host' => 'localhost',
*     'prefix' => '',
*   );
*   $databases['default']['default'] = array(
*     'driver' => 'pgsql',
*     'database' => 'databasename',
*     'username' => 'username',
*     'password' => 'password',
*     'host' => 'localhost',
*     'prefix' => '',
*   );
*   $databases['default']['default'] = array(
*     'driver' => 'sqlite',
*     'database' => '/path/to/databasefilename',
*   );
* @endcode
*/
$databases = array (
  'default' =>
  array (
    'default' =>
    array (
      'database' => 'databasename',
      'username' => 'username',
      'password' => 'password',
      'host' => 'localhost',
      'port' => '',
      'driver' => 'mysql',
      'prefix' => '',
    ),
  ),
);
/**
* Access control for update.php script.
*
* If you are updating your Drupal installation using the update.php script but
* are not logged in using either an account with the "Administer software
* updates" permission or the site maintenance account (the account that was
* created during installation), you will need to modify the access check
* statement below. Change the FALSE to a TRUE to disable the access check.
* After finishing the upgrade, be sure to open this file again and change the
* TRUE back to a FALSE!
*/
$update_free_access = FALSE;
/**
* Salt for one-time login links and cancel links, form tokens, etc.
*
* This variable will be set to a random value by the installer. All one-time
* login links will be invalidated if the value is changed.  Note that this
* variable must have the same value on every web server.  If this variable is
* empty, a hash of the serialized database credentials will be used as a
* fallback salt.
*
* For enhanced security, you may set this variable to a value using the
* contents of a file outside your docroot that is never saved together
* with any backups of your Drupal files and database.
*
* Example:
*   $drupal_hash_salt = file_get_contents('/home/example/salt.txt');
*
*/
$drupal_hash_salt = 'YtocY3rtde2KsHzYohytg5edsemrzwvPgRZAZ7chIs';
/**
* Base URL (optional).
*
* If Drupal is generating incorrect URLs on your site, which could
* be in HTML headers (links to CSS and JS files) or visible links on pages
* (such as in menus), uncomment the Base URL statement below (remove the
* leading hash sign) and fill in the absolute URL to your Drupal installation.
*
* You might also want to force users to use a given domain.
* See the .htaccess file for more information.
*
* Examples:
*   $base_url = 'http://www.example.com';
*   $base_url = 'http://www.example.com:8888';
*   $base_url = 'http://www.example.com/drupal';
*   $base_url = 'https://www.example.com:8888/drupal';
*
* It is not allowed to have a trailing slash; Drupal will add it
* for you.
*/
# $base_url = 'http://www.example.com';  // NO trailing slash!
/**
* PHP settings:
*
* To see what PHP settings are possible, including whether they can be set at
* runtime (by using ini_set()), read the PHP documentation:
* http://www.php.net/manual/en/ini.list.php
* See drupal_initialize_variables() in includes/bootstrap.inc for required
* runtime settings and the .htaccess file for non-runtime settings. Settings
* defined there should not be duplicated here so as to avoid conflict issues.
*/
/**
* Some distributions of Linux (most notably Debian) ship their PHP
* installations with garbage collection (gc) disabled. Since Drupal depends on
* PHP's garbage collection for clearing sessions, ensure that garbage
* collection occurs by using the most common settings.
*/
ini_set('session.gc_probability', 1);
ini_set('session.gc_divisor', 100);
/**
* Set session lifetime (in seconds), i.e. the time from the user's last visit
* to the active session may be deleted by the session garbage collector. When
* a session is deleted, authenticated users are logged out, and the contents
* of the user's $_SESSION variable is discarded.
*/
ini_set('session.gc_maxlifetime', 200000);
/**
* Set session cookie lifetime (in seconds), i.e. the time from the session is
* created to the cookie expires, i.e. when the browser is expected to discard
* the cookie. The value 0 means "until the browser is closed".
*/
ini_set('session.cookie_lifetime', 2000000);
/**
* If you encounter a situation where users post a large amount of text, and
* the result is stripped out upon viewing but can still be edited, Drupal's
* output filter may not have sufficient memory to process it.  If you
* experience this issue, you may wish to uncomment the following two lines
* and increase the limits of these variables.  For more information, see
* http://php.net/manual/en/pcre.configuration.php.
*/
# ini_set('pcre.backtrack_limit', 200000);
# ini_set('pcre.recursion_limit', 200000);
/**
* Drupal automatically generates a unique session cookie name for each site
* based on on its full domain name. If you have multiple domains pointing at
* the same Drupal site, you can either redirect them all to a single domain
* (see comment in .htaccess), or uncomment the line below and specify their
* shared base domain. Doing so assures that users remain logged in as they
* cross between your various domains.
*/
# $cookie_domain = 'example.com';
/**
* Variable overrides:
*
* To override specific entries in the 'variable' table for this site,
* set them here. You usually don't need to use this feature. This is
* useful in a configuration file for a vhost or directory, rather than
* the default settings.php. Any configuration setting from the 'variable'
* table can be given a new value. Note that any values you provide in
* these variable overrides will not be modifiable from the Drupal
* administration interface.
*
* The following overrides are examples:
* - site_name: Defines the site's name.
* - theme_default: Defines the default theme for this site.
* - anonymous: Defines the human-readable name of anonymous users.
* Remove the leading hash signs to enable.
*/
# $conf['site_name'] = 'My Drupal site';
# $conf['theme_default'] = 'garland';
# $conf['anonymous'] = 'Visitor';
/**
* A custom theme can be set for the offline page. This applies when the site
* is explicitly set to maintenance mode through the administration page or when
* the database is inactive due to an error. It can be set through the
* 'maintenance_theme' key. The template file should also be copied into the
* theme. It is located inside 'modules/system/maintenance-page.tpl.php'.
* Note: This setting does not apply to installation and update pages.
*/
# $conf['maintenance_theme'] = 'bartik';
/**
* Enable this setting to determine the correct IP address of the remote
* client by examining information stored in the X-Forwarded-For headers.
* X-Forwarded-For headers are a standard mechanism for identifying client
* systems connecting through a reverse proxy server, such as Squid or
* Pound. Reverse proxy servers are often used to enhance the performance
* of heavily visited sites and may also provide other site caching,
* security or encryption benefits. If this Drupal installation operates
* behind a reverse proxy, this setting should be enabled so that correct
* IP address information is captured in Drupal's session management,
* logging, statistics and access management systems; if you are unsure
* about this setting, do not have a reverse proxy, or Drupal operates in
* a shared hosting environment, this setting should remain commented out.
*/
# $conf['reverse_proxy'] = TRUE;
/**
* Set this value if your proxy server sends the client IP in a header other
* than X-Forwarded-For.
*
* The "X-Forwarded-For" header is a comma+space separated list of IP addresses,
* only the last one (the left-most) will be used.
*/
# $conf['reverse_proxy_header'] = 'HTTP_X_CLUSTER_CLIENT_IP';
/**
* reverse_proxy accepts an array of IP addresses.
*
* Each element of this array is the IP address of any of your reverse
* proxies. Filling this array Drupal will trust the information stored
* in the X-Forwarded-For headers only if Remote IP address is one of
* these, that is the request reaches the web server from one of your
* reverse proxies. Otherwise, the client could directly connect to
* your web server spoofing the X-Forwarded-For headers.
*/
# $conf['reverse_proxy_addresses'] = array('a.b.c.d', ...);
/**
* Page caching:
*
* By default, Drupal sends a "Vary: Cookie" HTTP header for anonymous page
* views. This tells a HTTP proxy that it may return a page from its local
* cache without contacting the web server, if the user sends the same Cookie
* header as the user who originally requested the cached page. Without "Vary:
* Cookie", authenticated users would also be served the anonymous page from
* the cache. If the site has mostly anonymous users except a few known
* editors/administrators, the Vary header can be omitted. This allows for
* better caching in HTTP proxies (including reverse proxies), i.e. even if
* clients send different cookies, they still get content served from the cache
* if aggressive caching is enabled and the minimum cache time is non-zero.
* However, authenticated users should access the site directly (i.e. not use an
* HTTP proxy, and bypass the reverse proxy if one is used) in order to avoid
* getting cached pages from the proxy.
*/
# $conf['omit_vary_cookie'] = TRUE;
/**
* CSS/JS aggregated file gzip compression:
*
* By default, when CSS or JS aggregation and clean URLs are enabled Drupal will
* store a gzip compressed (.gz) copy of the aggregated files. If this file is
* available then rewrite rules in the default .htaccess file will serve these
* files to browsers that accept gzip encoded content. This allows pages to load
* faster for these users and has minimal impact on server load. If you are
* using a webserver other than Apache httpd, or a caching reverse proxy that is
* configured to cache and compress these files itself you may want to uncomment
* one or both of the below lines, which will prevent gzip files being stored.
*/
# $conf['css_gzip_compression'] = FALSE;
# $conf['js_gzip_compression'] = FALSE;
/**
* String overrides:
*
* To override specific strings on your site with or without enabling locale
* module, add an entry to this list. This functionality allows you to change
* a small number of your site's default English language interface strings.
*
* Remove the leading hash signs to enable.
*/
# $conf['locale_custom_strings_en'][''] = array(
#   'forum'      => 'Discussion board',
#   '@count min' => '@count minutes',
# );
/**
*
* IP blocking:
*
* To bypass database queries for denied IP addresses, use this setting.
* Drupal queries the {blocked_ips} table by default on every page request
* for both authenticated and anonymous users. This allows the system to
* block IP addresses from within the administrative interface and before any
* modules are loaded. However on high traffic websites you may want to avoid
* this query, allowing you to bypass database access altogether for anonymous
* users under certain caching configurations.
*
* If using this setting, you will need to add back any IP addresses which
* you may have blocked via the administrative interface. Each element of this
* array represents a blocked IP address. Uncommenting the array and leaving it
* empty will have the effect of disabling IP blocking on your site.
*
* Remove the leading hash signs to enable.
*/
# $conf['blocked_ips'] = array(
#   'a.b.c.d',
# );
/**
* Authorized file system operations:
*
* The Update manager module included with Drupal provides a mechanism for
* site administrators to securely install missing updates for the site
* directly through the web user interface by providing either SSH or FTP
* credentials. This allows the site to update the new files as the user who
* owns all the Drupal files, instead of as the user the webserver is running
* as. However, some sites might wish to disable this functionality, and only
* update the code directly via SSH or FTP themselves. This setting completely
* disables all functionality related to these authorized file operations.
*
* Remove the leading hash signs to disable.
*/
# $conf['allow_authorize_operations'] = FALSE;

Changing the password in php.ini worked for me.

I am on a hosting service and had the exact same problem the next day with another site.
I finally called them out of desperation - where we discovered that the problem was DB passworddid not match the password in php.ini file. In their case it was an error in the way the php.ini file was supposed to be updated when a password changed is done on a Drupal DB.

So, whether or not you are on a hosting service, looking into making sure your DB password matches what's in your php.ini file is probably a good first step.

Don't panic! Whatever you do, don't panic! Unless, of course, you didn't make a backup - then by all means freak out...

I copied my site to a localhost, and recieved this error. in [site root]/sites/default/settings.php i changed the mysql port and it worked fine after that -

I created a new database user and updated the settings.php file to regain access to the site.

Still being denied database access through myPhpAdmin though:

#1045 - Access denied for user 'root'@'localhost' (using password: NO)

Thank!

I had this problem too while i was moving site from localhost. in my case the solution was bad server address
on my cpanel i have found a note:

Remote MySQL Host
The mysql server's address is XXXX. When connecting to the mysql server you must specify this host.

good luck!

I received the exact same error. My site was working fine for three days. Then I refreshed the browser, and the error occurred. Not much more to say other than it seem to be random.

**Edit**
Problem resolved. Forgot about changing the permissions on the settings.php file.

I setup a fresh ubuntu and dumped before all DB.
then cat the sql in the fresh db
and got that error on all local websites
And phpmyadmin said: Connection for controluser as defined in your configuration failed.
and i couldnt change passwd for any user , sth like "no such record in db "

solution was to use in the old password of debian-sys-maint

just copied the former debian.cnf to my new /etc/mysql/debian.cnf

I got the same problem, and now everything is OK.
Ah, the platform I used is DirectAdmin v1.37.0, and, I didn't modify any file, just change the password through "MySQL Management".
Choose the Database used, and press "modify password" to change a new one(actually, it's the same password as the old), then, everything is OK.

But, this problem happened maybe because there is something wrong from the web host, I noted that there is a email sent to me about this from the host holder just after I resolved it.

Hope this can be useful for you.

Hi,
I'm developing on a local server using OSX.
I renamed the the local directory for the particular drupal 7 site.
Then I renamed the line in /etc/hosts and the lines for the virtual host in /apache2/extra/httpd-vhosts.conf, then tried to access the site from the browser and got the error.
Restoring the directory name and the host and vhosts.conf fixes the problem.

The behaviour is different from drupal 6, using which I am able to change the site name etc without incident.
Thanks.

cloudmaker

this message is nothing more than the credentials are wrong.
I went into phpmyadmin, selected the database I've imported previously, clicked on rights and defined my missing user and its password.

thats it.

Hi,

Just thought I'd say that this thread really helped me:) In the end, after wrestling with the first database, and checking and re-checking, it turned out all I needed to do was create a fresh one...pffft. So new at this!

If your a newbie like me, and have been following this thread, another excellent tutorial is here: http://learnbythedrop.com/drop/132#comment-2436

Good luck all!

The solution for me was similar to what another user posted. The permissions on settings.php preventing me from uploading the changes I made to settings.php with the new username and password.

After giving the file write permissions I was then able to save the new DB password to settings.php and upload the changes.

.. what i am making every day when i stop working mostly in the evening.

i make a backup of my database(s)
i make a backup of the whole "drupal" in my htdocs of "xampp" i am using.
sometimes, when i think it is necessary (through changes there) i backup some like "php" or "apche" in "xampp" or others.

when my local "baseplace" crushed through testing one and anotherone and other stuff.. and it comes to the moment that the monitor show the words "game over"...

i make a fresh database.
make a fresh drupal minimal installation.
delete all tables.
using mostly mysgldumper to restore the backup of database
copy the backup of "drupal" and the files in it to the new installation.
having a look to several files like settings.php

and i can work with it.

it takes some moments to do that. but when i am on a testing-and-learning-pc where i can damage cause i will learn this is the easiest way:

making backups!!
do not forget!

(drupal files AND the database)

i hope someone is able to understand what i mean?
(form germany, i do not really speak - or write - english)

Ce message d'erreur a certainement un grand nombre de causes possibles, ma contribution ne servira donc pas forcément à beaucoup de monde.
Je suis tombé sur ce message en voulant ouvrir mon site après l'avoir transféré chez un hébergeur.
Pour le transfert, j'avais dû ouvrir une base SQL chez l'hébergeur et fournir nom d'utilisateur et un mot de passe avant de pouvoir importer les données de la base SQL locale. Or, ils n'étaient pas identiques à ceux qui figuraient sur le fichier settings.php. En reportant sur le fichier settings les données fournies chez l'hébergeur, j'ai retrouvé l'accès à la base.

translated to English (with some added words for clarity)

That message can be caused by any number of possibilities. My solution here may not help everyone posting here.

I came across this error message when trying to access my site after moving it to another host.

For the transfer I had to open an SQL db and provide a user name and password before I could import any data from my local db copy. Since the user name and password that I created at the new host for the db no longer matched the information in my settings.php file I had to modify the settings.php file to match the user name and password I was forced to create at the new host and now I have access.

Don't panic! Whatever you do, don't panic! Unless, of course, you didn't make a backup - then by all means freak out...

It happens when one of your database login details is not correct and which can either be password, username. If your database does not required password, leave it empty.

* $databases['default']['default'] = array(
* 'driver' => $drive,
* 'database' => $databasename,
* 'username' => $username,
* 'password' => $password,
* 'host' => $localhost,
* 'prefix' => $prefix',
* );

I need help with this, ASAP. I know I've put everything in correctly. All my past databases have worked flawlessly and right away.

I used the MySQL manager to make the database. I granted the user all privileges and completed all other steps. I inputed the DB name, the user, and the password correctly and yet it rejects it. I've tried numerous databases, and all fail. I've tried making a database through MyPHPadmin, but I can't find an option to. I'm hosted on Lunarpages, at sbcforums.com. I'm new to Drupal.

I really want to get my site up. =/

You said you tried making one with PHPMyAdmin but cant find an option to. Which host are you using? Do they allow you cpanel access?

I said I was hosted by Lunarpages in my first post. Yes, they have a control panel.

I've just uninstalled Drupal and reinstalled it with new databases. Still not working. -_-

Is your settings.php writeable? (permissions)

Yes, 666.

I also got the same issue because of same name for the username and database name and i changed the username then the problem is solved.

This might happen if you add another database, and grant privileges to the Drupal user name, but with a different password, and/or forget to "flush privileges;".

I am not sure which of these two caused it, but after running this in the mysql terminal, with the original values, it works again: grant all on YOURDATABASENAME.* to 'YOURUSERNAME' identified by 'YOURPASSWORD';

No more "PDOException: SQLSTATE[28000] [1045] Access denied for user ..."

EDIT: I just did it again, and locked myself out of my root account. This fixed it:

UPDATE mysql.user SET Password=PASSWORD('YOUR_ROOT_PASSWORD') WHERE User='root';
FLUSH PRIVILEGES;

First off ask yourself, what did I change? If it worked well yesterday, how is it not working now?
If you run XAMPP like I do there's a solution described here.
XAMPP recently brought out a new security concept of authenticating access to folders. Have you actuated that?
If so the solution is simple.

  1. Remove the folder access system here.
  2. Remove the MySQL access password.

Remove the MySQL access password.

  1. Login to phpMyAdmin using your new password
  2. Once logged in click "Change Password."
  3. Use the password that you used when you had installed Drupal.
  4. Restart MySQL and Apache.

I hope this helps or at the very least gives you a new angle of attack.
Adam.

Life Liberty and the unabashed pursuit of happiness.

I found that if your password from the Old D6 was using ascii characters
converted them from the install screen to your settings.php

example:

password = Something@t643x
the @'s in the passwords would be converted to %40 for your settings.php to work
so your settings.php would have a password Something%40t643x

If like me you have one development password for several sites locally you dont want to go change every single password in every single build

D7 excepts using ascii characters directly in your settings.php unlike D6

Hope that helps someone.

To fix this
login to panel
click on ''MySql Databases"
Look in the list "users with access"
Click on a user
The list "Allowable Hosts" should have the IP of your remote machine.
Enter in the IP of your remote machine you are working on
If you don't have a fixed IP then this may change at a future date and the error will return

For me the solution was to change, in the file php.ini, the HOST from 'localhost' into 'your_local_IP_machine'.
Hope this helps someone!..

my solution was:
in pma go to needed DB
Privileges -> Edit Privileges -> in "Host" section choose "localhost" (before I used "%")

typo got me here too, i make mysql users via command line, instead of localhost i typed localhoast, doh!

My mistake was not choosing localhost when setting up the db.
I was using add new user- create DB at the same time and did not select the local host option.

absolutely nothing helped for me yet. :( I may have to build a new site ONLINE as I find the upload impossible now. Same error- nothing wrong with the setting.php file.

Support at hostgator gives up as well.

Wonder what might be the issue??? I bet you anything it's mysql craziness.

If you use a decent Drupal-specialist host their support will not give up. Many cheap hosts are a false economy for Drupal, inadequte support being only one of their problems. It is easy enough if you have shell access to the server (not sure whether hostgator offers that?) to log in from command line and test your database credentials to see whether they can connect.

If hostgator uses cPanel, remember that in cPanel you do not use phpmyadmin to add users to the database you have created. There is a seperate tool called Databases or My Databases or something of that kind on the far left of the databases section. You will have to add your user to the database before you import the database dump.

I just the changed my root password for mysql by following the instructions here:
http://gnuski.blogspot.com/2012/02/resetting-mysql-root-password-red-hat...

then, I got the above error..

Thanks for reminding the setting.php file because I had to go there and update the root password with the new one.

SOLVED!

Hello,

Actually I am totally new to this field i.e. CMS drupal. I have got no idea about php and cms. But after watching a youtube video I tried to create a website using drupal.

After completing everything I got an error message while database configuration.
i.e. Failed to connect to your database server. The server reports the following message: SQLSTATE[28000] [1045] Access denied for user 'a1354766_neha'@'localhost' (using password: YES).

I create a database using MySQL at command line and used that but it didn't work. Then I used MySQL provided by Cpanel. And created a database and username namely:

Database: a1354766_admin
username: a1354766_neha

I have updated the settings.php file and changed the privileges to 777.

I replaced all the database, username and password with these one.

But still nothing is happening.

Please help me out. :(

Did you remember to attach your databse user to your databse in cpanel? Three-step process 1. create db, 2. create user, 3. attach user to db.

Second possibility. Your db is @'localhost' . Some hosting company do not have the database servers at localhost. Therefore you may need to contact your hosting company to clarify this point.

Third possibility. The other common reason for the problem is a typing mistake in db name, username or password name.

this is happened to my once and the reason was the upgrade from drupal 6 to 7 ...produce a new settings.php file .. please check it in details..

Thanks everyone! update.php and settings.php save my life

I've got the above error just now. I've edited the settings.php, and somehow I've managed to write the mysql connect row twice (one in the middle, and one at the end) into the settings.php. After deleting one of it, my page works as usual.

I got the same error when move the project into another machine. To solve the problem, You just have to edit the sites/default/settings file. If you have multiple sites, You can edit their settings files as well. In my case, i just edit the default settings file.

find and change the following section appropriate to yours

$databases['default']['default'] = array(
'driver' => 'mysql',
'database' => 'nameOftheDB',
'username' => 'nameOfDBuser',
'password' => 'DBUsersPassword',
'host' => 'localhost',
'prefix' => '',
);

Maybe you've changed the listening address of your MySQL Server. I'll tell you my case:

I use Webmin to adminster my server, and MySQL listens on 127.0.0.1 by default (at least I remember so). I changed this with Webmin, so MySQL should listen on "Any" interface, but this doesn't write the expected "bind" option to my.cnf, this erase that option instead! This way, Webmin could access MySQL as before, but I got this error in Drupal 7. So I edited /etc/mysql/my.cnf by myself and put "bind=0.0.0.0" within [mysqld] section, restarted MySQL server and everything's working fine now.

I ran into the same error on one of my 25+ installations. I have no idea, what it it caused as this site is only in the make and pretty much no public traffic hits the site. However, I decided to just re-grant the rights on the database as explained in INSTALL.mysql.txt.
After this, everything was back to normal again. Weird, but sometime weird things do happen :)
Hope this helps some other scared souls.

Norbert

-- form follows function

Make sure you put your MYSQL host address in the proper box during installation. This option is available under the advanced tab marked as important/asterisk and may go unseen if the tab isn't clicked. Doing that will solve your problem.

Soumay Kumar

I just had this problem on my site after my IP host reset my cPanel password. I had to go into sites/default /settings.php and change the database password to the cPanel password. Everything worked fine afterwards.

That is interesting. In my experience of cPanel the database password and cPanel password are not normally the same, but maybe in some shared hosting setups they are.

It seems that the problem is file permissions on both the database file, and its parent folder.

You have to "chmod 777" the files folder, and the .ht.sqlite db file
http://stackoverflow.com/questions/3319112/sqlite-read-only-database

I had an old D6 settingsOLD.php file in my default directory, which Drupal decided to use in stead of settings.php, for some reason. As soon as it was deleted I could connect to the database.

I got this exact same error after moving hole site from a server to other
my fault was that I didn't change parameters correct for new server.
check your settings again...

kem ka ta obi, ta odja!
-grandma-

14 hours later on the PDO Exception error...

In the MySQL User database, the user permissions had to be entered multiple times for the same user name. Create one user account with a Hosts option of 127.0.0.1 another (with same user account) with hosts option of localhost and another with hosts option of the public hostname of the server. The User Permissions should now show the user name 3 times, with the 3 hosts options shown. I was using webmin to interface with ubuntu. Everything works once I followed this procedure. If you fail to generate the 3 options, you can get the PDO error.

Whew!

pg

Had the same problem for a minute, thinking it was going to be a nightmare to put back together.. What happened in my case, I used phpMyAdmin and changed my password which caused the error in the first place. Of course I made a backup of my db's and /settings.php files but all I did to resolve the issue was edit the "old" password from the "settings.php" file and uploaded with updated password.

My case might be different than yours but if you were just trying to edit your phpMyAdmin password this should do the trick. Seamed to be a quicker fix than deleting anything.

So if you're in the same predicament hope that's a quick and easy fix. :)

Basically I changed my.cnf under etc folder in Centos.

I added settings that may have caused this issue.... it killed all my website and shows this error to all my websites...

Originally I added this:

open_files_limit=3662
set-variable = innodb_file_per_table=1
set-variable =
set-variable = innodb_buffer_pool_size=20M
set-variable = innodb_additional_mem_pool_size=5000K
set-variable = innodb_log_buffer_size=5000K
set-variable = innodb_thread_concurrency=6
set-variable = innodb_flush_log_at_trx_commit=0

Retrying with this:

open_files_limit=3662
set-variable = innodb_file_per_table=1
set-variable = innodb_buffer_pool_size=5M
set-variable = innodb_additional_mem_pool_size=5K
set-variable = innodb_log_buffer_size=5K
set-variable = innodb_thread_concurrency=2
set-variable = innodb_flush_log_at_trx_commit=0

So my fix?

My Fix was to empty (delete contents in file) the file my.cnf - then I rebooted server.

Wahla.

I was getting this error after moving a copy of my website from environment 1 to environment 2. In PhpMyAdmin (environment 2) I created a new user and new database with the same name, granting the user all privileges. When completing this step, I should have set the server as 'localhost', as I was using it locally, but I used the option 'any server' (%). I have then imported the dump into the new database, but the website wouldn't load, displaying the error message reported in this thread.

Entered PhpMyAdmin again and fixed the user configuration to use 'localhost' and it worked. When updating user rights in PhpMyAdmin, just make sure you check the option to remove the old user from the users table and recreate the new one with the same privileges.

Marcos Buarque de Hollanda