We have a user account foo that somehow has been tied to root's uid, guid and groups. when i run id foo it returns all the root id info.

id foo

uid=0(root) gid=0(root) groups=0(root)

This user account is for an old associate who is no longer here and i would like to remove their account completely from the server. Running ps -ef | grep foo doesn't return any process' for this user so i feel confident nothing is being ran under their username.

Running userdel foo indicates the user account doesn't exist as im sure it see's the account as root with the uid=0 but i still see the foo account it in /etc/passwd as foo:x:0:0::/home/foo:/bin/bash

What steps do i need to do to get rid of this account? Do i need to usermod and change the uid, gid and groups? Will that break anything if i pick a random uid not in use, i.e. uid=1099(foo)?

Im on CentOS 7, the server is connected to Active Directory, but this foo account is a Local account on the Linux serve. The user was terminated before we connected Linux to AD so the account no longer exists in Active Directory.

  • 1
    I would also probably check for unauthorized modifications to system files too, because it's really strange that foo just happened to be changed to UID=0/GID=0. This seems like a case of a cuckoo's egg to me!
    – ErikF
    Commented Mar 19, 2018 at 19:17

2 Answers 2


I recommend not to use tools like userdel as it is not clear why foo has uid 0 and you don't want to accidently delete root.

Rather edit /etc/passwd itself and delete the entry for foo. Make sure that root itself has a correct entry:


Do the same for /etc/group. Delete entry for foo and check the entry for root:


Then check password entry in /etc/shadow, delete foo, check root entry. Entry for root should look similar to:


Maybe there are additional entries for foo in /etc/group. Possible example:


For a clean job, remove foo respective foo, in those entries, too.

If /home/foo exists, check and delete it afterwards.

Currently foo is same as root. You won't find processes or files owned by foo as they all belong to root. File and process owners are registered by their uid, not by their name. So all processes or files with uid 0 appear as root. (Alternativly all root processes and files could appear as foo instead of root).

  • 1
    This answer is spot on, and raises a couple of interesting questions why you should not give a uid / gid 0 to "regular" users. Commented Mar 19, 2018 at 18:47
  • 1
    I'd rather say it's a good example of the reasons why not: it makes it harder to remove the user account once it's no longer needed, and impossible to tell the user's files and processes apart from ones legitimately belonging to root.
    – telcoM
    Commented Mar 19, 2018 at 18:57

You could use vipw to delete the line of the foo account in /etc/passwd and /etc/shadow. Once you've done that, the account is technically gone.

Depending on vipw version, once you've used it to make changes to /etc/passwd, it may either prompt you: "do you want to edit /etc/shadow too? (Y/N)" or just suggest using vipw -s to edit /etc/shadow.

Many Linux distributions have the corresponding command vigr for editing /etc/group (and /etc/gshadow, if one exists).

Using vipw and vigr is safer than editing the files directly, as these commands will make a copy of the file before editing, and will make some sanity checks before replacing the original with the edited copy.

Once the account is deleted from /etc/passwd, you can do whatever you want to the user's home directory and local mail spool, i.e. /home/foo and /var/mail/foo. Usually, you'd want to just remove them unless there is some reason to archive them.

You'll also want to check the job scheduler; the layout may vary a bit, but at least on Debian systems, there are directories atjobs, atspool and crontabs in /var/spool/cron/: check for any mention of user foo in any of them, and remove any such files.

  • Thank you very much for the insight and those commands. All three vipw, vigr & vipw -s is exactly what i was looking for. I was able to completely remove this user from the system now. I also agree that setting a users account to be an "alias" of root, is not a good practice at all. Since we now manage users via Windows AD, this local account was pretty much a backdoor into the system.
    – Govna
    Commented Mar 19, 2018 at 21:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .