2019-09-04 21:01:54 +05:30
---
2021-02-22 17:27:13 +05:30
stage: Manage
group: Access
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2019-09-04 21:01:54 +05:30
type: howto
---
2019-09-30 21:07:59 +05:30
2020-11-24 15:15:51 +05:30
# How to reset user password
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
There are a few ways to reset the password of a user.
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
## Rake Task
GitLab provides a Rake Task to reset passwords of users using their usernames,
which can be invoked by the following command:
2015-09-11 14:41:01 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-03-11 19:13:27 +05:30
sudo gitlab-rake "gitlab:password:reset"
2015-09-11 14:41:01 +05:30
```
2021-03-11 19:13:27 +05:30
You will be asked for username, password, and password confirmation. Upon giving
proper values for them, the password of the specified user will be updated.
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
The Rake task also takes the username as an argument, as shown in the example
below:
2015-09-11 14:41:01 +05:30
2020-03-13 15:44:24 +05:30
```shell
2021-03-11 19:13:27 +05:30
sudo gitlab-rake "gitlab:password:reset[johndoe]"
2015-09-11 14:41:01 +05:30
```
2021-03-11 19:13:27 +05:30
NOTE:
To reset the default admin password, run this Rake task with the username
`root` , which is the default username of that admin account.
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
## Rails console
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
The Rake task is capable of finding users via their usernames. However, if only
user ID or email ID of the user is known, Rails console can be used to find user
using user ID and then change password of the user manually.
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
1. Start a Rails console
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
```shell
sudo gitlab-rails console -e production
```
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
1. Find the user either by user ID or email ID:
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
```ruby
user = User.find(123)
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
#or
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
user = User.find_by(email: 'user@example.com')
```
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
1. Reset the password
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
```ruby
user.password = 'secret_pass'
user.password_confirmation = 'secret_pass'
```
1. When using this method instead of the [Users API ](../api/users.md#user-modification ),
GitLab sends an email to the user stating that the user changed their
password. If the password was changed by an administrator, execute the
following command to notify the user by email:
```ruby
user.send_only_admin_changed_your_password_notification!
```
2015-09-11 14:41:01 +05:30
2021-03-11 19:13:27 +05:30
1. Save the changes:
```ruby
user.save!
```
1. Exit the console, and then try to sign in with your new password.
2019-09-04 21:01:54 +05:30
2021-02-22 17:27:13 +05:30
NOTE:
2021-01-29 00:20:46 +05:30
You can also reset passwords by using the [Users API ](../api/users.md#user-modification ).
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
## Reset your root password
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
The previously described steps can also be used to reset the root password.
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
In normal installations where the username of root account hasn't been changed
manually, the Rake task can be used with username `root` to reset the root
password.
2020-11-24 15:15:51 +05:30
2021-03-11 19:13:27 +05:30
If the username was changed to something else and has been forgotten, one
possible way is to reset the password using Rails console with user ID `1` (in
almost all the cases, the first user will be the default admin account).
2020-11-24 15:15:51 +05:30
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. -->