usermodChange an existing user account
usermod edits an existing account: add it to groups, change its shell or home, lock it, rename it or set an expiry date. The one flag pair everyone must know is -aG: without -a, -G replaces all of the user's groups.
usermod [OPTIONS] LOGINdocker ps fails with permission denied for you, and you want to fix it without using sudo for every command.
sudousermod rewrites /etc/passwd, /etc/shadow and /etc/group, so it needs root.
usermod locks the account files, rewrites the relevant lines and unlocks them. -G and -aG edit the member lists in /etc/group and /etc/gshadow; -s, -d, -c, -l and -u edit the /etc/passwd line; -L puts a ! in front of the password hash in /etc/shadow and -e writes the expiry day. Nothing touches running processes: group membership is part of a process's kernel credentials, set by initgroups() when login, sshd or su starts your session, and inherited by every child. So after usermod -aG docker, your current shell still has the old groups until you log in again (or start a new one with newgrp or su - $USER). For -l and -u, usermod refuses if the user has running processes, because their files and processes would no longer match. With -u it also chowns files inside the home directory, but not files elsewhere.
-aG g1,g2Add supplementary groups, keep the existing ones-G g1,g2Set the exact supplementary list (removes others!)-s SHELLChange the login shell (/usr/sbin/nologin to disable)-LLock the password (puts ! before the hash)-UUnlock the password-e YYYY-MM-DDExpire the whole account on a date; -e 1 expires it now-d DIR -mSet a new home and move the old contents there-l NEWRename the login (home and group are not renamed)-u UIDChange the UID (files in the home are re-owned)-g GROUPChange the primary group-c TEXTChange the comment / full namesudo usermod -G docker kunalWithout -a, -G replaces the whole supplementary group list: kunal silently loses sudo and every other group.
sudo usermod -aG docker kunal (or sudo gpasswd -a kunal docker)Adding yourself to a group and expecting the current shell to have itGroup membership is part of a process's credentials, set at login. Existing shells and services keep the old list.
Log out and in, run newgrp docker, or restart the service that needs the groupUsing only usermod -L to block a leaver-L breaks password logins only. SSH keys and existing sessions keep working.
sudo usermod -L -e 1 -s /usr/sbin/nologin USER && sudo pkill -KILL -u USERusermod -u 2001 app and assuming all its files followOnly files inside the home directory are re-owned. Files under /var, /srv or /data keep the old number.
sudo find / -xdev -uid 1002 -exec chown -h 2001 {} + after changing the UIDTry these on a Linux machine of your own. Each task has a hint and a solution.
Add the user devops to the adm group (so it can read /var/log files) without removing any existing groups. Show the result.
Create user temp1, then lock its password and confirm the status shows L.
Change temp1's login shell to /usr/sbin/nologin and verify in /etc/passwd.
Make temp1 expire on 2026-12-31 and check it.
usermodChange an existing user account
usermod edits an existing account: add it to groups, change its shell or home, lock it, rename it or set an expiry date. The one flag pair everyone must know is -aG: without -a, -G replaces all of the user's groups.
usermod [OPTIONS] LOGINdocker ps fails with permission denied for you, and you want to fix it without using sudo for every command.
sudousermod rewrites /etc/passwd, /etc/shadow and /etc/group, so it needs root.
usermod locks the account files, rewrites the relevant lines and unlocks them. -G and -aG edit the member lists in /etc/group and /etc/gshadow; -s, -d, -c, -l and -u edit the /etc/passwd line; -L puts a ! in front of the password hash in /etc/shadow and -e writes the expiry day. Nothing touches running processes: group membership is part of a process's kernel credentials, set by initgroups() when login, sshd or su starts your session, and inherited by every child. So after usermod -aG docker, your current shell still has the old groups until you log in again (or start a new one with newgrp or su - $USER). For -l and -u, usermod refuses if the user has running processes, because their files and processes would no longer match. With -u it also chowns files inside the home directory, but not files elsewhere.
-aG g1,g2Add supplementary groups, keep the existing ones-G g1,g2Set the exact supplementary list (removes others!)-s SHELLChange the login shell (/usr/sbin/nologin to disable)-LLock the password (puts ! before the hash)-UUnlock the password-e YYYY-MM-DDExpire the whole account on a date; -e 1 expires it now-d DIR -mSet a new home and move the old contents there-l NEWRename the login (home and group are not renamed)-u UIDChange the UID (files in the home are re-owned)-g GROUPChange the primary group-c TEXTChange the comment / full namesudo usermod -G docker kunalWithout -a, -G replaces the whole supplementary group list: kunal silently loses sudo and every other group.
sudo usermod -aG docker kunal (or sudo gpasswd -a kunal docker)Adding yourself to a group and expecting the current shell to have itGroup membership is part of a process's credentials, set at login. Existing shells and services keep the old list.
Log out and in, run newgrp docker, or restart the service that needs the groupUsing only usermod -L to block a leaver-L breaks password logins only. SSH keys and existing sessions keep working.
sudo usermod -L -e 1 -s /usr/sbin/nologin USER && sudo pkill -KILL -u USERusermod -u 2001 app and assuming all its files followOnly files inside the home directory are re-owned. Files under /var, /srv or /data keep the old number.
sudo find / -xdev -uid 1002 -exec chown -h 2001 {} + after changing the UIDTry these on a Linux machine of your own. Each task has a hint and a solution.
Add the user devops to the adm group (so it can read /var/log files) without removing any existing groups. Show the result.
Create user temp1, then lock its password and confirm the status shows L.
Change temp1's login shell to /usr/sbin/nologin and verify in /etc/passwd.
Make temp1 expire on 2026-12-31 and check it.