Locked out of Magento 2 admin: a diagnostic checklist

The admin asks for a new password, you set one, and the next login fails. You try again and Magento says the account is locked. You click "Forgot your password?" and get "We're unable to send the password reset email." You contact Adobe and they can't find your account. If you're a merchant and not a developer, you can't do anything else from the browser at this point.

This happens a lot, and the fix almost never involves the browser. Magento 2 admin access depends on a small set of things: the admin URL, the admin_user record, two-factor auth, base URL and cookie config, and session storage. Check them in that order. Each one has a bin/magento command that confirms or rules it out, and none of them require you to write SQL against admin_user.

You need shell access to the server, as the user that owns the Magento files. If you don't have that, the first job is to find out who does: your host, your agency, or whoever deployed the site.

Adobe cannot see your admin account

It helps to know this before anything else. On Magento Open Source and on most self-hosted Adobe Commerce installs, admin users live in your store's own database. They are not tied to an Adobe ID. Adobe support has no record of them and can't reset them. The only people who can recover the account are people with access to your server. That's why contacting Adobe goes nowhere, and it's why everything below happens on the command line.

The admin frontName may have changed

If you get a 404 or the storefront instead of a login form, you're probably on the wrong URL. The admin path is set in app/etc/env.php and can be overridden in config. Check both:

bin/magento info:adminuri
bin/magento config:show admin/url/use_custom_path
bin/magento config:show admin/url/custom_path
bin/magento config:show admin/url/use_custom

info:adminuri prints the path Magento is actually using. If someone set a custom admin URL to a domain that no longer resolves, every admin request will redirect into nothing. To reset the frontName cleanly, use bin/magento setup:config:set --backend-frontname=yourpath rather than editing env.php by hand, then flush cache.

The account is locked or the password expired

The pattern in the question above comes from this cause. Magento forces a password change once the admin password lifetime runs out (admin/security/password_lifetime, with admin/security/password_is_forced deciding whether the change is mandatory). It rejects new passwords that are too similar to recent ones. It also locks the account after a set number of failed attempts (admin/security/lockout_failures) for a set time (admin/security/lockout_threshold). A rejected new password followed by a few retries is enough to trigger the lock.

List users, unlock the one you need, and set a password from the CLI:

bin/magento admin:user:unlock <username>

If you don't know the password, or the reset email won't send, create a fresh admin user instead of fighting the old one:

bin/magento admin:user:create --admin-user=recovery --admin-password='<strong password>' --admin-email=you@example.com --admin-firstname=Recovery --admin-lastname=Admin

Log in with that account, fix the original user under System > Permissions > All Users, then remove or disable the recovery account. Don't leave spare admin users around.

The reset email never leaves the server

"We're unable to send the password reset email" is a mail transport problem, not an account problem. Magento tried to send the email and failed. Check var/log/exception.log and var/log/system.log right after clicking the reset link. Common causes:

• No working local MTA, and no SMTP extension configured
• An SMTP extension with expired credentials or a blocked port
• system/smtp/disable set to 1, which turns off outbound mail entirely

bin/magento config:show system/smtp shows the core settings. Fixing mail matters for order confirmations too, so don't skip it once you're back in. For getting access back right now, the CLI user creation above is faster.

Two-factor auth blocks you after the password works

Since 2.4, Magento_TwoFactorAuth is enabled by default. If the password is accepted but you're stuck on a 2FA screen, either the authenticator device is gone or the 2FA setup email never arrived (the same mail problem as above). Reset the provider for that user:

bin/magento security:tfa:providers
bin/magento security:tfa:reset <username> google

On the next login the user goes through enrollment again. People sometimes disable the 2FA module in production with module:disable to get in quickly. We'd avoid that. It removes a real control on the most valuable login on the site, and it tends to stay disabled long after the emergency.

Base URLs and cookie domain don't match the host

If the login form accepts your credentials and then reloads the same form with no error, the session cookie isn't sticking. This usually happens after a domain change, an HTTPS switch, or a database copied from staging:

bin/magento config:show web/secure/base_url
bin/magento config:show web/unsecure/base_url
bin/magento config:show web/secure/use_in_adminhtml
bin/magento config:show web/cookie/cookie_domain
bin/magento config:show web/cookie/cookie_path

The base URLs must match the hostname you're actually using, including the scheme. The cookie domain should be empty or match that host. A leftover .staging.example.com silently breaks every admin login. Fix values with bin/magento config:set (or --lock-env if you manage config through env.php), then run bin/magento cache:flush. Also check that the browser has the same admin_account_sharing behaviour you expect if several people use one account.

Cache and session storage are failing underneath

If none of the above explains it, look at where sessions are stored. Open the session block in app/etc/env.php:

• files: check that var/session exists, is writable by the web user, and that the disk isn't full.
• redis: confirm the Redis host is reachable from the web node and not evicting keys under memory pressure. Admin sessions written to an evicting Redis instance will log you out at random.

Then clear the state that can hide a fix you already made:

bin/magento cache:clean
bin/magento cache:flush

If you run Varnish or a CDN, make sure /admin (or your custom frontName) bypasses it. A cached admin login page causes some very confusing behaviour.

What to do next

Once you're back in, deal with what caused the lockout so it doesn't happen again. Get outbound mail working so password resets and 2FA enrollment actually reach people. Give each person their own admin user instead of sharing one. Keep at least two people with shell access. Write down the admin URL somewhere outside the site itself.

If you don't have shell access, or the steps above point to something deeper like a broken deploy, a misconfigured Redis cluster, or a database copied from another environment, that's Magento 2 operations work we do regularly. Get in touch with the symptoms and what you've already tried.