Q9. A user sees “This account is currently not available” at a terminal, or the GUI returns to the login prompt. How do you troubleshoot it?
Start by inspecting the account rather than editing /etc/passwd directly:
getent passwd nerds
The final field is the user's login shell. If it is /sbin/nologin or /usr/sbin/nologin, an interactive login normally prints a “not available” message. If it is /bin/false, the shell exits immediately and may simply return to a login prompt. These are not necessarily errors: service accounts are often deliberately prevented from logging in interactively.
For a real user account that should have terminal access, change the shell with usermod:
sudo usermod -s /bin/bash nerds
getent passwd nerds
You can also use chsh -s /bin/bash nerds where permitted. Avoid hand-editing /etc/passwd; a malformed line can break account lookups, while usermod performs the change safely. Do not “fix” a service account such as www-data by giving it a shell merely because its non-interactive login failed.
If the shell is already valid, the password and GUI symptoms can have other causes. Check the home directory, filesystem space, account status, and recent authentication logs:
sudo passwd -S nerds
ls -ld /home/nerds
df -h
sudo journalctl -b --no-pager
Debian and Ubuntu commonly record authentication details in /var/log/auth.log; RHEL-family systems use /var/log/secure. A full home filesystem, broken session files, an expired account, or incorrect home-directory ownership can produce a GUI login loop. A good interview answer explains how you isolate the cause instead of treating every failure as a shell problem.
Q10. How do you make a user reset their password at the next login?
Use chage to set the last password-change date to zero:
sudo chage -d 0 nerds
On many Linux systems, sudo passwd -e nerds is an equivalent way to expire the current password. At the next password-based login, the user is required to choose a new password.
Verify the account's aging information:
sudo chage -l nerds
This does not set a new password for the user, and it is different from configuring a routine password-expiration interval. It forces a one-time change. Before using it, confirm that the account has a usable authentication method and that the person has been given the current temporary password through a secure channel.
For automation, create the account with a random temporary password, expire it, and never put that password in shell history, a ticket, or source control. Also consider how your access method behaves: key-only SSH systems and centralized identity providers may require a different enrollment or password-reset workflow.
Q11. How do you create home directories under /data/home, including for future users?
For one new account, pass the full home path to useradd and request creation of the directory:
sudo mkdir -p /data/home
sudo useradd -m -d /data/home/flatliner flatliner
The -m option creates the home directory when it does not exist. Without it, some systems create only the account record and leave you to create and secure the directory yourself.
To change the base directory for future accounts, edit /etc/default/useradd and set:
HOME=/data/home
Then create a user normally:
sudo useradd -m anotheruser
getent passwd anotheruser
The setting affects new users; it does not move existing accounts. To move an existing user's home, log the user out, take a backup, and use usermod with both -d and -m:
sudo usermod -d /data/home/nerds -m nerds
Confirm that no running process is still using the old directory. Applications sometimes store the old absolute path in their own configuration, so changing the account database alone may not finish the migration.
On SELinux-enabled systems, a nonstandard home location can also require the correct file-context configuration. Check for denials with sudo ausearch -m avc -ts recent and follow the distribution's SELinux documentation rather than disabling SELinux. Regardless of the platform, verify ownership and permissions before asking the user to log in.
Follow-up scenarios worth practicing
Interviewers often extend these questions to see whether you understand the operational consequences:
-
A service account uses
/usr/sbin/nologin. Should you change it? Usually not. Services can run without an interactive shell, and adding one increases attack surface. -
The home path exists in
/etc/passwd, but login still fails. Check whether the directory actually exists, whether the user owns it, and whether permissions or disk quotas prevent writes. - You expired a password but cannot connect to test it. Make sure you have another administrative session or console access before changing authentication settings on a remote machine.
- A new home directory works locally but not over NFS or SELinux. Investigate the complete storage and security path instead of repeatedly recreating the user.
The strongest answers combine the command with verification: inspect getent passwd, review chage -l, check logs, and test the login without closing your recovery session.
Top comments (0)