I have set up a Drush alias for my website (hosted on a shared hosting), the alias works correctly, because commands like drush status, drush cc all, etc. work. The problem comes with drush uli. It generates the one-time login link, the domain is correct, everything looks all right, but when entered into a browser, it results in standard Drupal

Access Denied


Part of setting up the alias and some interesting issues around path-alias-es, relations to database settings, it's usage and relevancy the aliases is originally discussed in Drush issues page on GitHub.

Technical information:

  • This is a clean Drupal 7 installation, without contrib modules.
  • I can log in using password (even using password set via drush upwd using the same alias).
  • I have checked all possible sources (like truncating sessions table, etc.) discussed in similar but yet different issue on StackExchange.
  • I have tried different browsers and cleared browser caches and cookies as suggested in various similar discussions on Drupal.org, all without luck.

Drush alias:

$aliases['myalias'] = array(
  'uri' => 'mysite.com',
  'root' => '/home/mysite.com/web',
  'path-aliases' => array(
    '%drush' => '/home/.composer/vendor/drush/drush',
  '%files' => '/home/mysite.com/web/sites/mysite.com/files',

The alias works correctly for other commands like clearing caches and drush status confirms that Drupal is bootstrapped correctly.

  • are you using uri parameter ? Commented Oct 30, 2015 at 10:31
  • @DavidLukac On which URI you have Access Denied? Does it recognise the token and redirects first?
    – kenorb
    Commented Oct 30, 2015 at 10:36
  • @HimanshuPathak The URI is directly in the alias. Commented Oct 30, 2015 at 13:18
  • @kenorb The Access Denied is directly on the token URL. The watchdog says: 415 | 0 | access denied | user/reset/1/1445605040/kxvcztB8oYE5PdRDS02j_Gsef_5eI1gcSvzuSenzotE/login | ... http://example.com/user/reset/1/1445605040/kxvcztB8oYE5PdRDS02j_Gsef_5eI1gcSvzuSenzotE/login so the location and URI and URL all seem to be correct. Commented Oct 30, 2015 at 13:22
  • @DavidLukac Do you have Access Denied when you're using invalid token? I've tested this link and it gets redirected (so it recognised that the token is not right) and it's showing the message You have tried to use a one-time login ..., so at least not Access Denied.
    – kenorb
    Commented Oct 30, 2015 at 13:25

4 Answers 4


This can happen when the user is blocked. Setting the status to 1 in the Users table may resolve it.

  • 1
    Thanks, this worked for me. One would think drush does that validation first
    – Piyin
    Commented Sep 29, 2017 at 19:21
  • Beware. The command drush uli logs you in as user 1 by default. User 1 is often blocked for a reason: it can bypass any access checks, so the account is a potential security risk (especially as its username is often the same across sites, "admin"). The solution is to set up a different user account with as many administrator permissions as you need, which you could do once via user 1 (then block it). Use drush uli UID, drush uli 'username' or drush uli [email protected] to log in as that user.
    – pjcdawkins
    Commented Nov 3, 2017 at 8:42
  • Unblock the user via drush: drush user:unblock admin Commented Jan 9, 2020 at 13:34
  • Print user information using drush: drush user-information 1 Commented Jan 9, 2020 at 13:37

Just ran across this in a local dev setup.. turned out to be the $cookie_domain setting that was committed in settings.php... if this is set to the production URL, you will not get a valid cookie, and therefore access will never be granted. Overriding $cookie_domain to match the local dev environment in local-settings.php did the trick!


Also check the flood table. Its possible there are records that are failed attempts by IP address that are blocking access.


I'm not exactly sure why the drush uli gets to Access Denied. I suspect it's something with validation/generation of the one time links and/or incorrect timestamp in the users table.

The solution was deleting the password in the database. (Changing it via drush upwd or directly in Drupal didn't work.) After deleting the user's password I was able to run drush uli.

  • when you say 'delete password' do you mean delete values in users.pass? Commented Jun 8, 2017 at 10:22
  • @petednz-fuzion Per this comment, yes.
    – rovr138
    Commented Aug 8, 2017 at 17:04
  • Thanks for clarifying that "I deleted the password in the database" == "delete values in users.pass field" Commented Aug 8, 2017 at 18:38
  • drush upwd worked for me! Commented Sep 27, 2017 at 20:45
  • Beware... as I mentioned above, user 1 is an account you should be protecting carefully. Of course if it's your development site on a local machine, go ahead by all means.
    – pjcdawkins
    Commented Nov 3, 2017 at 8:50

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.