Linux print all users

List all human users

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.

8 Answers 8

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 ':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).

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

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

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

@karel Yeah, maybe. Instead of filtering by UID, I’m filtering out that username explicitly. There may be a reason for having a legitimate user with a UID that high. Who knows 😉

I personally like to use just:

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.

+1 This way is simple, it’s what most experienced users would actually do, and I think it’s no less robust than methods that check a range of UIDs. It seems less likely a human user would have a home directory outside /home (that isn’t symlinked to /home ) than that a human user would have a UID of under 1000 (after all, this is the most common method of keeping a display manager from listing a user on the login screen, which may sometimes be done for a human user). The one, relatively minor disadvantage here is that lost+found will be listed on systems with separate /home partitions.

@Serg I think it comes down to the inherent ambiguity in the problem description. Does an account with no home directory really represent a human user? In practice, such accounts are usually—though admittedly not always—used for highly specialized tasks (typically by people with their own separate accounts) or for users intended to access the system only through specific, restricted services. Of course there’s another use case for useradd —no-create-home —the home directory might already exist or might be created shortly thereafter—but the ls /home method works fine for those cases.

What happens if someone creates a folder not associated with a user or with a human user? For example a folder for shared files

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: '' 

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: '' 

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:)' 

• 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: ).

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:)' 

Источник