Last updated July 17, 2013. Created by webchick on January 17, 2011.
Edited by greggles, LeeHunter, jenlampton, raincloud. Log in to edit this page.

Having the Anonymous user deleted in your site breaks Drupal in unexpected ways, including a message like:

  • "Could not login with user ID #0." error from Drush
  • "warning: Invalid argument supplied for foreach() in /includes/form.inc on line 1181." and various other strange errors from Drupal core

Fixing cases where you accidentally deleted the user

There are many ways to accidentally delete the uid 0 (Anonymous) user: a mistaken query that forgot to use "and uid != 0" or a Views Bulk Operations view that was a little too aggressive.

The technique to fix it depends on a few factors. Below are different techniques that work on Drupal 7 or Drupal 6.

Drupal 7

For Drupal 7, you can run two queries:

insert into users (name, pass, mail, theme, signature, language, init, timezone) values ('', '', '', '', '', '', '', '');
update users set uid = 0 where name = '';

This will insert a new row getting a random UID and then the update query fixes to get the right uid for the user.

For Drupal 6 using a slightly different technique

You can also insert directly with a specific value for the auto-incrementing UID if you tell your database to use a different SQL_MODE.

This pair of statements will bring the user back on Drupal 6:

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
INSERT INTO `users` (`uid`, `name`, `pass`, `mail`, `mode`, `sort`, `threshold`, `theme`, `signature`, `created`, `access`, `login`, `status`, `timezone`, `language`, `picture`, `init`, `data`)
VALUES ('0', '', '', '', 0, 0, 0, '', '', 0, 0, 0, 0, NULL, '', '', '', NULL);

Check again:
select name, uid from users where name = '';
Output should be like this:

-+------+-----+
-| name | uid |
-+------+-----+
-|      |   0 |
-+------+-----+
-1 row in set (0.00 sec)

Fixing cases where the import changed the uid values

Certain database dump programs, such as older versions of phpMyAdmin, do not respect MySQL's SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; directive. The result of this is when importing a faulty database dump, your anonymous user record gets imported as (highest user ID) +1 instead of user ID 0.

Should this happen to you, you can fix your database by issuing the following query:

UPDATE users SET uid = 0 WHERE name = '';

To check if this fix applies to you run:

select name, uid
from users
where name = '';

Output should be something like this:
-+------+-----+
-| name | uid |
-+------+-----+
-|      |  0 |
-+------+-----+
-1 row in set (0.00 sec)

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

Thanks for this comment!
It just solved a problem I was trying to fix for the last two days.

I had this issue with a Drupal 6 installation that the search index wasn't properly rebuilt by the usual cron job. After researching a lot and not finding anything helpful, I installed Drush, and Drush told me that it couldn't login as user #0. So I followed the directions above, so that I could use Drush with user #0. After I did that, Drush AND the search indexing worked perfectly fine.

So for everyone having similar problems: the Drupal search index rebuilding engine seems to rely on the Anonymous user as well.

If you came to this issue because Drush sent you here:

Drush spits out:

Could not login with user ID #0. This is typically caused by importing a MySQL database dump [error]
from a faulty tool which re-numbered the anonymous user ID in the users table. See
http://drupal.org/node/1029506 for help recovering from this situation.

This was related to a site we built where we do not allow anonymous access. So the homepage displays access denied and the login screen.

Simple solution is to run drush as admin:

Eg clear cache:
drush -u 1 cc all

Running drush as user 1 worked wonderfully for me.

drush -u 1 cc all

Does anyone know if there are any downsides/dangers to running drush as admin user? If not, is there a way to tell drush to ALWAYS run as admin?

This error suddenly started appearing while I was trying to debug migrations from the command line using XDebug + PHPStorm. The problem was that I had set a bad conditional breakpoint on a line in /includes/entity.inc -- I had used the assignment operator where I should have used the equality operator (ie. $ids=NULL instead of $ids==NULL). Big facepalm. Be careful when using debuggers!

Well, as now Drupal 7 has INNER JOIN to user_revision table, we have to keep connection between users and user_revision tables on vid, otherwise user_load won't return any user.

Only if you are using the user revision module.

What is the remedy for Drupal 8?