userdel

What it does

userdel removes a user account by deleting its entries from /etc/passwd, /etc/shadow, and the user's own primary group entry in /etc/group if one exists. By default it leaves the user's home directory and files elsewhere on disk untouched — you must explicitly ask it to clean those up.

Beginner examples

• sudo userdel alice — remove the account, but leave the home directory in place
• sudo userdel -r alice — remove the account and delete the home directory and mail spool
• id alice (before deleting) — confirm the account exists and check its UID
• who or w — check whether the user is currently logged in before deleting

sudo userdel -r alice

Advanced examples

• Force-remove a user even though they have an active session or owned processes: sudo userdel -rf alice (use cautiously — orphaned processes can behave unpredictably).
• Audit for leftover files after deletion by UID rather than username, since the name no longer resolves: sudo find / -xdev -uid 1500 -print (using the old numeric UID).
• Remove an SELinux user mapping alongside the account on SELinux-enabled systems: sudo userdel -Z alice.
• Combine with groupdel when the user had a dedicated personal group that's now empty and unused: sudo groupdel alice (only if no other user relies on that group).

sudo userdel -r alice && sudo find / -xdev -uid 1500 -print

Common mistakes

• Forgetting -r and assuming the account is fully gone, when the home directory and mail spool are actually still sitting on disk consuming space.
• Using -f casually on a user with active processes, which can force-remove the account while leaving orphaned running processes tied to a UID that no longer maps to a name.
• Not checking for files owned by the user outside their home directory (e.g. in /var/www, /opt, shared project folders) — userdel -r only cleans up the home directory and mail spool, nothing else.
• Deleting a user whose UID is still referenced in cron jobs, systemd services, or file ownership elsewhere, causing "unknown user" errors or orphaned ownership afterward.

Tips

• Run who or w first to check if the user has an active session before deleting, rather than jumping straight to -f.
• Search for files owned by the user's UID system-wide before deleting, so you can decide whether to reassign, archive, or delete them: find / -user alice.
• Consider locking the account first (usermod -L alice or passwd -l alice) as a reversible step before permanently deleting it, especially in production.

Best practices

• Always audit for and handle files owned by the user outside their home directory before or after running userdel -r, to avoid orphaned ownership.
• Avoid -f as a routine option; investigate why a user still has active sessions or processes rather than force-removing through it.
• In production, prefer a "lock, wait, then delete" workflow (disable login, verify nothing depends on the account, then userdel -r) over immediate deletion, to reduce the blast radius of mistakes.

Real-world use cases

• Offboarding an employee: locking their account first, then later running userdel -r once all their data has been reviewed or migrated.
• Cleaning up temporary or contractor accounts created for a short-term project.
• Removing stale service-like accounts left over from decommissioned applications, after confirming no cron jobs or processes still depend on them.

Common interview questions

• What's the difference between userdel and userdel -r? Plain userdel only removes the account entries from /etc/passwd//etc/shadow//etc/group, leaving the home directory and mail spool in place; -r also deletes those.
• What happens to files a deleted user owned outside their home directory? They're left untouched, now owned by a numeric UID with no corresponding account name, and show up that way in ls -l until reassigned or removed.
• Why might userdel refuse to delete an account? If the user has an active login session or running processes, userdel refuses by default; -f overrides this but can leave orphaned processes.