Take the 2-minute tour ×

Does anybody know why the linux command


shows a different output than

    groups username 

The logged in user is the same as the parameter username. Example:

    thorsten@ubuntu:~/tmp$ groups
    thorsten adm dialout cdrom plugdev lpadmin admin sambashare
    thorsten@ubuntu:~/tmp$ groups thorsten
    thorsten : thorsten adm dialout cdrom plugdev nogroup lpadmin admin sambashare
share|improve this question

migrated from stackoverflow.com Apr 24 '12 at 20:15

This question came from our site for professional and enthusiast programmers.

There are so many duplicates of this question that I don't even know where to start. –  grawity Apr 24 '12 at 21:39
add comment

4 Answers

up vote 6 down vote accepted

When you run groups username, it looks up1 the given user in /etc/passwd and /etc/group (although it can be LDAP, NIS or something else2) and shows you all groups found.

On the other hand, when you run the groups command without any arguments, it simply lists all groups it itself belongs to3 – which is not necessarily the same as what is listed in /etc/group. (See below for an explanation.) In fact, the only lookups made to /etc/group are for translating GIDs to group names.

Each process has a set of credentials, which contains (among other things) a "real group ID" (primary GID), an "effective group ID" (EGID), and a list of "supplementary group" IDs (secondary GIDs). By default, a process inherits its credentials from its parent; however, processes running as root (UID 0) or having the CAP_SETUID capability are allowed to set arbitrary credentials.

In particular, when you log in to Linux (whether in a tty, X11, or over SSH), the login process (/bin/login, gdm, sshd) looks up your username to determine your UID, primary GID, and secondary GIDs. On a personal machine, this just means reading the appropriate lines from passwd and group files (or NIS, LDAP, etc).

Next, the login process switches4 to those credentials before starting your session, and every process you launch from now on will have the exact same UID & GIDs – the system does not check /etc/group anymore5 and will not pick up any modifications made.

In this way, the /usr/bin/groups process will belong to the same groups as you did when you logged in, not what the database says you are in.

Note: The above explanation also applies to almost all Unixes; to the Windows NT family (except UIDs and GIDs are all called "SIDs", there is no "primary group", the credentials are called the "process token", and CAP_SETUID is SeCreateTokenPrivilege or SeTcbPrivilege); and likely to most other multi-user operating systems.

1 getpwuid() and getgrouplist() are used to look up a user's groups.

2 On Linux, glibc uses /etc/nsswitch.conf to determine where to look for this information.

3 groups uses getgid(), getegid() and getgroups() to obtain its own credentials.

4 setuid(), setgid(), initgroups() and related.

5 An exception, of course, is the various tools that run elevated (setuid) such as su, sudo, sg, newgrp, pkexec, and so on. This means that su $USER will spawn a shell with the updated group list.

share|improve this answer
add comment

groups on its own gives the current group membership of the owner of the process. This can differ from groups <username> if the groupdb has changed since the process started or the process owner changed.

share|improve this answer
groups doesn't give current membership, but rather that which was "current" at the time when the login process (/sbin/login, gdm, sshd) called initgroups(). –  grawity Apr 24 '12 at 21:03
add comment

Run updatedb, see if there is any change.

The same in my OSX machine when groupdb has not changed:

albert-hotspot:~ sami$ groups sami
staff com.apple.access_screensharing com.apple.sharepoint.group.2 everyone _appstore localaccounts _appserverusr admin _appserveradm _lpadmin _lpoperator _developer
albert-hotspot:~ sami$ groups
albert-hotspot:~ sami$ 
share|improve this answer
add comment

Just restart the computer and both groups and groups user should give the same results.

The reason they were different was because you added yourself to a new group which you weren't a member of when you started the computer.

share|improve this answer
You certainly do not need to reboot the whole system! You just need to start a new login session (i.e. on a new virtual console, using su, closing a reopening the current session). You can also use newgrp to start processes with the new group included. –  pabouk Nov 18 '13 at 10:04
I only meant to give a simple quick fix solution which will work every time. There are plenty of other answers which already answer this question in much detail. Sometimes what people want, like it was in my case, is a simple solution that just works without going through several steps. –  Alex Nov 29 '13 at 0:01
add comment

Your Answer


