The tag feels a bit vague to me. It covers several related topics, including:

  • user account metadata (password, shell, …), e.g. 1 2 3
  • user account databases, e.g. 1 2
  • privileges of a user (the files they can write, etc.), e.g. 1 2
  • file ownership, e.g. 1; often is used instead

We also have , which covers user account metadata and databases. I don't know when to use and when to use for this meaning (except that can also apply to groups).

Should we split ? If so, should we unify one of the meanings with ?

As for , it feels more tame to me. But it should be renamed to .


4 Answers 4


I think we could get away of groups, accounts, user(s) and group(s) if we used a single for all questions about UID/GID and related topics, as they pertain the user administration of the kernel/system. Other usages, like databases, web servers and the like, that are not directly related with the user/group of the (file)system itself should use their respective applications tags, like , , , etc.

Is the most simple solution I can find, which would have the most desired effect and prevents confusion.

  • what about NSS?
    – hildred
    Jun 2, 2015 at 22:28
  • @hildred there's already the nsswitch tag
    – Braiam
    Jun 3, 2015 at 1:09

I do associate with, users in /etc/group. IIRC this used to be the initial group account for when new user accounts were made (before the practise of making a group with the username for each user became widespread).

At least this questions seems to use it that way.

I don't think that that once case warrants keeping that tag around. If there are more such cases a more generic would be more appropriate (i.e. describing its function not necessarily the actual name used). During a re-tag action one could retag to this for appropriate questions and tally at the end to see whether should be a keeper.

  • You mean the group called users often present on default Linux installation? A logical tag name would be users-group, but that's an extremely specific topic, I don't see it warranting a tag. The question you cite is not about that: in that question, users is just an example. May 28, 2015 at 6:45
  • @Gilles yes that is the one I mean, and what the question I quote refers to. It is what in the man page is called the intiial group. I am not sure if it warrents keeping at all. I did not count up-front, but proposed the process of first renaming and then deciding on deletion after it is clear how many of this particular use cases there are. Instead of just removing the users and not being able to find thiem once you would realise there are enough to warrent the tag. I would not use users-group, as some distro might not use/have used users for the common initial group.
    – Anthon
    May 28, 2015 at 6:59
  • What do you mean by “common initial group”? Do you mean the default primary group? default-primary-group would be a better name. But that too is an overly specific topic, I think we can live with just group and something like user-accounts. We don't even have a tag for primary-group or supplemental-groups. May 28, 2015 at 7:02
  • @Gilles I got initial group from man useradd, but default-primary-group would probably be better. I have only retagged some 20 questions in one action and I could preview all before I started. With the 571 users that is really feasable, if a retag of this uses is done to just group and afterwards you realise you had e.g. 50 of these specific cases and decide they warrant their own tag, you would have to separate them from group. That is more difficult to do than changing or removing default-primary-group afterwards if there are not enough Qs for that tag
    – Anthon
    May 28, 2015 at 7:11
  • It is just how I would go about this, not knowing up front how many of these uses of users are there going to be.
    – Anthon
    May 28, 2015 at 7:12

I could be oversimplifying this:

Users - Attached to a human

Accounts - Not Attached to a human

User in a database would be accounts since it is overshadowed by account used by the database itself. Hopefully, we aren't running our services as personal users anymore.


I am going to disagree with DarkSheep, As much as it would be nice to have a good unix-wide distinction between users and accounts (bob is a user, apache is an account) this is not a distinction that really exists outside a small number of administrative tools. The confusion between users (Bob, a man who has less hair than he wishes), user accounts (bob, the login for the man who wants more hair), pseudo-users (the thing the computer thinks is out there, maybe), and pseudo-user accounts (the user account set aside for the web server) is not well defined on a truly global scale (although some distributions are trying to draw a line in the sand)

If we were to adopt site specific definitions (which I think would be a good thing as long as we recognise that these definitions are not fully accepted) I would propose the following:


  • System User Account: The association of data identifying a user returned by pwgent including UID, GID, username, and related information, but specifically not including password related information.

  • Application User Account: any user account used by an application that is not returned by pwgent.

  • Pseudo-user Account: Any special case of System User Account that does not have a corresponding User.

  • Regular User Account: Any System User Account associated either with an individual or organization.

Don't even get me started on groups Which are an even bigger mess with:

  • User group:

    1. organization for supporting users
    2. the group with the same name as the user
    3. a group containing real pebkac users (which sometimes is called users)
  • Group user: a user that is a member of a specific group

  • Administrative group: a group of users (pebkac) that have permissions based on group membership.

  • system group: a group without real users (ie bin, games, lpr)
  • system user group (apache)

Feel free to improve this.

You must log in to answer this question.

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