List all human users

Question

How can I list all human users that I've created? I've tried cat /etc/passwd and it just lists a lot of stuff.

Answer 1

Human users have UIDs starting at 1000, so you can use that fact to filter out the non-humans:

cut -d: -f1,3 /etc/passwd | egrep ':[0-9]{4}$' | cut -d: -f1

This cuts the first (username) and third (UID) colon-delimited fields from /etc/passwd, then filters for the resulting lines which end with a colon and four digits, then cuts the first (username) field from that, leaving you with a list of users with UIDs between 1000 and 9999.

If you have more than nine thousand users on your system, this will fail - but it's necessary to restrict the result to 4-digit UIDs in order not to catch nobody (UID 65534).

Answer 2

This does pretty much what the accepted answer does, just in one command instead of three:

awk -F: '$3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd

And thanks to Karel in the comments, the nobody user is also filtered out.

Answer 3

I personally like to use just:

ls /home

Admittedly this is not a list of users but instead a list of their home directories. Currently existing human users on the system will have home directories in /home, but you may see the home directories of past users who were removed, as well.

This works for my purposes and may work for yours as well. For example, if you are looking to delete a user account that turns out no longer to exist (nonexistent-user) and run the command

sudo deluser nonexistent-user

it will just tell you that that this user does not exist.

Answer 4

While it might seem like a clear-cut idea, actually there is ambiguity in the meaning of human user. Is a user account deliberately hidden from the login screen because it's used only for specialized purposes (but by humans) a human user? How about the ubuntu user (UID 999) on the live CD? And guest accounts in Ubuntu are created on-the-fly and destroyed after logout; are they human users? More examples could be devised.

Therefore, it's fitting that multiple, non-equivalent answers have been given. Saige Hamblin's solution of running ls /home is what people actually do, and unless you're writing a script, you should probably just use that.

Making ls /home More Robust

But perhaps you have users that have been removed, but whose home directories still exist in /home, and you must avoid listing them. Or maybe for some other reason you must ensure only the entries in /home that correspond to real accounts are listed.

In that case, I suggest passing the names of everything in /home to getent (to retrieve the passwd entries of users with those names), then isolate and display just the username field (with grep, sed, or awk, as per your preference). Any one of these will do:

getent passwd $(ls /home) | grep -o '^[^:]*'

getent passwd $(ls /home) | sed 's/:.*//'

getent passwd $(ls /home) | awk -F: '{print $1}'

This should work well, as you shouldn't have user accounts with whitespace or control characters in their names; cannot, without reconfiguring Ubuntu to allow it; and if you do, you have bigger problems. Thus the usual problems with parsing ls are inapplicable. But even though it's really okay here, if you consider command substitutions with ls aesthetically displeasing or just a bad habit, you may prefer:

getent passwd $(basename -a /home/*) | grep -o '^[^:]*'

getent passwd $(basename -a /home/*) | sed 's/:.*//'

getent passwd $(basename -a /home/*) | awk -F: '{print $1}'

These don't accommodate whitespace or control characters either. I provide them only because $(ls /home) looks wrong even when it is right, and thus rubs many users the wrong way. In most situations, there are real, good reasons to avoid parsing ls, and in those situations parsing basename -a is usually only very slightly less bad. In this situation, however, due to the limitation on what characters may practically occur in usernames, they are both fine.

Explanation, Benefits, and Drawbacks

I use getent mainly because it accepts usernames as arguments to restrict its output, but also because it is slightly more universal than examining /etc/passwd directly, in case authentication facilities and the password database are provided by network services.

This method has the additional benefit over ls /home that, on systems with a separate /home partition, lost+found usually appears in the output of ls /home.

• With the more robust method presented above, lost+found will only appear if there happens to be a user (human or not) called lost+found, which is unlikely.
• But if you're entering commands interactively rather than writing a script, ls /home is fine--you know you don't have a human user called lost+found.

Infrequently, this method (in any of the above variations) will produce unsatisfactory output:

• If a user's home directory exists outside /home, or not at all, this suggests but does not imply the account shouldn't be considered to represent a human user. This method only lists users when there is a directory of the same name in /home.
• If you have created additional directories in /home that aren't actually anybody's home directory, and they happen to have the same name as an existing non-human user--or consist of words separated by whitespace, one or more of which has the same name as an existing non-human user--then some non-human users may be included in the output.
  _{(This method can be implemented with a loop and separate getent invocations, so word splitting doesn't produce spurious output. But the complexity is not warranted; fundamentally, if you use /home as something other than a place for users' home directories, this method will not produce reliable output.)}

---

Making UID Checking Simpler

If you decide to go with a method that checks user IDs to ensure they are in the likely range for accounts representing human beings, as in the accepted answer or Oli's answer, then I suggest this for brevity:

getent passwd | grep -oP '^[^:]+(?=:x:\d{4}:)'

This uses a Perl regular expression (-P) to show:

• text at the beginning of a line (^) containing no :s ([^:]+) — this is the first field, as : is the field separator in passwd
• that precedes but doesn't include ((?= )) the password field x — it should always be x, since in Ubuntu password hashes are stored in the shadow database, not the world-readable passwd database
• and a UID field consisting of exactly 4 digits (:\d{4}:).

This is thus a significantly shorter and somewhat simpler variant of the technique in the accepted answer. (The technique described there works fine too, and it does have the benefit of being portable to non – GNU/Linux systems whose grep doesn't support -P.)

Reconsidering the "Human" UID Range

If you want to accommodate very high UIDs and check for nobody explicitly, you can use the method in Oli's answer. You may wish to consider, however, if users with very high UIDs should really be assumed human, or if they are more likely to be some other special-purpose non-human user (like nobody). In practice such users--besides nobody--are uncommon, so really this is a judgment call on your part.

A possible compromise is to list users in the range of UIDs that are actually being assigned to newly created, non-"system" users. You can check for this in adduser.conf:

$ grep -E '^(FIRST|LAST)_UID' /etc/adduser.conf
FIRST_UID=1000
LAST_UID=29999

Here are two ways to list users whose UIDs range from 1000 to 29999:

getent passwd | grep -oP '^[^:]+(?=:x:[12]?\d{4}:)'

getent passwd | awk -F: '999<$3 && $3<30000 {print $1}'

Answer 5

grep -E "x:[1-9]([0-9]){3}:" /etc/passwd

It browses the content of /etc/passwd looking for entries of human users.

To do that grep looks for lines that have user id numbers bigger than 1000.

Examples of matching regex:

x:1001:

x:1203:

Answer 6

TL;DR: only human users have SystemAccount=false

One other way is to list output of while ignoring root ls /var/lib/AccountsService/users/ | grep -v root. Now, there is a quirk - gdm, a greeter/login screen ( or more formally desktop manager ) is also listed as a user. So just from listing we cant tell if gdm is human or not.

A more efficient and correct approach is to go through the files in that folder and find out which users are listed as having SystemAccount=false. The one-liner bellow achieves that

grep SystemAccount=false /var/lib/AccountsService/users/* | awk -F '/' '{gsub(":","/");print $6}'

Answer 7

Joining the party, I oversee a network systems using LDAP, having home directories outside /home and UIDs (due to a scripting glitch) in the millions. None of the current answers, therefore, work. The test that works for me is checking whether the user has a valid login shell. A valid shell is one which is listed in /etc/shells. The simplest form:

getent passwd | grep -wFf /etc/shells

The file may contain comments (or empty lines), so one might have to filter them out:

getent passwd | grep -wFf <(grep '^/' /etc/shells)

Answer 8

On buntu systems, regular users (human users, that is) have UIDs beginning with 1000 which are assigned sequentially to them when their accounts are first created. What all this boils down to is that the first account created on a buntu system has a UID of 1000. The next one created has a UID of 1001. And so on and so forth.

So, the simplest way to list all human user accounts present on the system, in my opinion, is to check whether the third column in the /etc/passwd file which contains the user's UID is greater than or equal to 1000 and less than, let's say, 2000 (it's very unlikely for a typical desktop PC to have more than one thousand user accounts, don't you think so?):

$ awk -F$':' '{ if ($3 >= 1000 && $3 < 2000) print $1; }' /etc/passwd