2019-09-04 21:01:54 +05:30
|
|
|
---
|
|
|
|
type: howto
|
|
|
|
---
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
# How to unlock a locked user from the command line
|
2019-09-04 21:01:54 +05:30
|
|
|
|
2020-04-08 14:13:33 +05:30
|
|
|
After ten failed login attempts a user gets in a locked state.
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
To unlock a locked user:
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
1. SSH into your GitLab server.
|
|
|
|
1. Start a Ruby on Rails console:
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2020-03-13 15:44:24 +05:30
|
|
|
```shell
|
2019-09-30 21:07:59 +05:30
|
|
|
## For Omnibus GitLab
|
2020-04-08 14:13:33 +05:30
|
|
|
sudo gitlab-rails console -e production
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
## For installations from source
|
2020-04-22 19:07:51 +05:30
|
|
|
sudo -u git -H bundle exec rails console -e production
|
2019-09-30 21:07:59 +05:30
|
|
|
```
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
1. Find the user to unlock. You can search by email or ID.
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
```ruby
|
|
|
|
user = User.find_by(email: 'admin@local.host')
|
|
|
|
```
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
or
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
```ruby
|
|
|
|
user = User.where(id: 1).first
|
|
|
|
```
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
1. Unlock the user:
|
2018-11-20 20:47:30 +05:30
|
|
|
|
2019-09-30 21:07:59 +05:30
|
|
|
```ruby
|
|
|
|
user.unlock_access!
|
|
|
|
```
|
|
|
|
|
|
|
|
1. Exit the console with <kbd>Ctrl</kbd>+<kbd>d</kbd>
|
|
|
|
|
|
|
|
The user should now be able to log in.
|
2019-09-04 21:01:54 +05:30
|
|
|
|
|
|
|
<!-- ## Troubleshooting
|
|
|
|
|
|
|
|
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
|
|
|
|
one might have when setting this up, or when something is changed, or on upgrading, it's
|
|
|
|
important to describe those, too. Think of things that may go wrong and include them here.
|
|
|
|
This is important to minimize requests for support, and to avoid doc comments with
|
|
|
|
questions that you know someone might ask.
|
|
|
|
|
|
|
|
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
|
|
|
|
If you have none to add when creating a doc, leave this section in place
|
|
|
|
but commented out to help encourage others to add to it in the future. -->
|