If you forgot your Linux password on Ubuntu, you can reset it without reinstalling. The two reliable paths are GRUB recovery mode (the most common, no extra media needed) and a LiveCD/LiveUSB chroot mount (works when GRUB is locked or encrypted boot is in the way). The team that knows which path matches their setup has the right one before they need it.
Table of contents
- Why Ubuntu does not let you log in without the password
- Path 1: Reset through GRUB recovery mode
- Path 2: Reset from a LiveCD or LiveUSB
- Common mistakes and how to avoid them
- What to do before you ever need this
- FAQ
Why Ubuntu does not let you log in without the password
Ubuntu ships with the shadow file containing the hashed user passwords and a passwd file listing who can log in. When the local account is locked, the only path back in is a privileged shell that does not require the lost password. Recovery mode and the installer LiveCD both give you that shell, but they use different mechanisms. Recovery mode restarts the local system with init=/bin/bash so the running kernel drops you straight into a root shell. LiveCD mode boots a separate environment from USB and uses chroot to operate on the installed system. Both are legitimate. Recovery mode is faster and what the Ask Ubuntu answer thread has been recommending for a decade. LiveCD is what you use when GRUB is encrypted, when the disk is full, or when recovery mode itself is broken.
The Linux filesystem does not forget the password. It stores a salted hash that is computationally infeasible to reverse, and that hash is still on disk after you forget the password. The recovery procedure is not a decryption. It is a write to the shadow file that replaces the existing hash with a new one. The math is the same as a normal passwd change. The only difference is the path that gets you to a shell that can write to /etc/shadow.
Path 1: Reset through GRUB recovery mode
Reboot the machine. Hold the left Shift key during boot (or press Escape on some HP and Lenovo hardware) to bring up the GRUB menu. If your machine is configured to boot straight to the login screen, you may have to enter your BIOS or boot firmware to re-enable the GRUB menu first.
Once the menu is up, select Advanced options for Ubuntu and then the recovery mode entry that matches your kernel. Pick root - Drop to root shell prompt from the recovery menu. The system mounts the local filesystem in read-write mode. Run:
mount -o remount,rw /Then reset the password:
passwd usernameReplace username with the actual user. Type the new password twice. If you forgot the username, cat /etc/passwd | grep /home lists everyone with a home directory. After the change, reboot:
rebootIf you do not see a GRUB menu, it is most likely hidden. The fix is to set GRUB_TIMEOUT=10 in /etc/default/grub from a LiveCD, then update-grub. The procedure for hidden GRUB is covered in the Ubuntu Community Hub thread.
Path 2: Reset from a LiveCD or LiveUSB
If recovery mode is unavailable (encrypted disk, broken GRUB, full disk, or the recovery entry was removed), boot from an Ubuntu install USB. Pick Try Ubuntu from the boot menu to get a live desktop.
Identify the partition that holds your installed root. lsblk or sudo fdisk -l shows you the layout. Mount it:
sudo mount /dev/sda2 /mntIf you have a separate /boot partition, mount that too:
sudo mount /dev/sda1 /mnt/bootThen chroot in and reset the password:
sudo chroot /mnt
passwd username
exit
sudo rebootThe chroot makes the live environment treat your installed system as its root. From the chroot, passwd writes to the right /etc/shadow and the change persists when you reboot back into the installed system.
A common variation is when the user record itself is broken (the passwd -l username was misapplied, or the account was deleted). In that case, use usermod -p 'new-password-hash' username or recreate the account with useradd -m -G sudo newuser and add the same UID/GID.
Common mistakes and how to avoid them
The biggest mistake is editing /etc/shadow directly with vi or sed. The passwd command is the right tool because it handles the salt, the hashing algorithm, and the lock flag. A hand-edited shadow entry is the fastest way to lock yourself out permanently. Use passwd. If you have to script the change, use chpasswd with a here-doc.
The second most common mistake is the file-mode check. /etc/shadow must be readable only by root, and /etc/passwd must be world-readable. If a LiveCD session changes the permissions while you are chrooted in, the system will refuse to authenticate after reboot. Leave the modes alone.
The third mistake is the SELinux or AppArmor context. On Ubuntu Server with AppArmor installed, a relabeled /etc/shadow from a chroot can fail to authenticate until the next reboot triggers a forced relabel. On Ubuntu Server this is rare. On RHEL and Fedora it is common. If you are on Red Hat family and passwd succeeds but you still cannot log in, touch /.autorelabel and reboot. The same fix is occasionally needed on Ubuntu when the chroot environment is unusually out of date.
What to do before you ever need this
The team that does not get caught by a forgotten password is the team that took three steps when they set the box up: enabled the GRUB menu timeout, made sure the recovery mode entry was not removed in the GRUB config, and stored a working LiveCD ISO on a USB stick in the same drawer as the server. Recovery mode and LiveCD both work, but the LiveCD is the more reliable of the two because it works on every Linux distribution, not just Ubuntu.
If you manage many machines, the right escalation is to centralize auth on LDAP or Active Directory. A user who forgets the password resets it through a web UI, and the change propagates to every box in the fleet. Local accounts on a single server are an operational liability for any team beyond one person.
FAQ
Can I reset the password without rebooting?
No. The local account password lives in /etc/shadow, and you need a privileged shell to write to it. The only way to get a privileged shell without the password is to interrupt boot and use recovery mode or a LiveCD. If you have a working sudo session under a different user, you can use that. If you are locked out of every account, the only path is a reboot into recovery.
Will I lose my data?
No. Resetting the password does not touch your home directory, your installed packages, or any other data. The procedure only rewrites the hash in /etc/shadow. Files on disk are untouched.
My disk is encrypted with LUKS. What changes?
You still need the LUKS passphrase to unlock the disk at boot. Recovery mode and LiveCD both require that. If you also forgot the LUKS passphrase, the data is unrecoverable — LUKS is designed so that forgetting the passphrase is permanent. The only remediation is to wipe the disk and restore from backup.
Why does Ubuntu not show the GRUB menu by default?
The default /etc/default/grub file has GRUB_TIMEOUT=0 and GRUB_TIMEOUT_STYLE=hidden on Ubuntu Desktop since 12.04 to make the boot path invisible. The fix is to set GRUB_TIMEOUT=10 in /etc/default/grub (from a LiveCD, because you cannot log in to the running system), then run sudo update-grub. The Ubuntu Community Hub post linked above walks through this.
Can I prevent this from happening again?
Yes. The team that has the right setup is the one with a working LiveCD on a USB stick in the same drawer as the server, a GRUB menu timeout above zero, and either a documented password manager entry for the user or central auth on the fleet. None of these are difficult. They are just easy to forget.
Does the recovery procedure work on a remote server?
Only if the hosting provider gives you a console (IPMI, KVM, or a cloud provider’s serial console). The recovery procedure requires interrupting the boot process at the GRUB menu, which means you need a way to see the screen and a way to type. AWS gives you this through EC2 Serial Console. Hetzner, OVH, and most bare-metal providers do not — for those, the answer is usually to add an SSH key to a recovery user through the provider’s management panel.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: