Linux online course

Understanding the Linux /etc/group File Format

Learn how Linux /etc/group records define group names, GIDs, password fields, and supplementary group membership, with safe inspection and administration commands.

The /etc/group file is the local, plain-text database of named Unix and Linux groups. A group is a named collection used when Linux makes file ownership and permission decisions. Each local group record associates a human-readable group name with a numeric group identifier, or GID, and may list accounts that belong to the group as supplementary members.

On most systems, ordinary users can read /etc/group. Reading the file is not the same as being allowed to change it. Group creation and membership changes should normally be performed with administrative utilities.

The /etc/group Record Format

Each non-comment record describes one group. The fields are colon-delimited, meaning that a colon separates each field and the fields always appear in a fixed order:

group_name:password_field:GID:member_list

The fourth field may be empty. For example, the trailing colon in developers:x:1200: marks an empty member-list field.

/etc/group Field Reference

Position | Field | Example value | Meaning | Notes

1 | Group name | projectteam | Human-readable group name | Used by administrators and commands

2 | Password field | x | Group-password indicator or legacy password storage | Usually x on shadow-enabled systems

3 | GID | 5000 | Numeric group identifier | Used for ownership and authorization

4 | Member list | alice,bob | Comma-separated supplementary members | Can be empty

Example: A Typical Group Record

projectteam:x:5000:alice,bob
  • projectteam is the group name.
  • x indicates that protected group-password information is expected in /etc/gshadow when shadow group data is in use.
  • 5000 is the group’s numeric GID.
  • alice,bob is the comma-separated list of accounts explicitly included as supplementary members.

Understanding Each Field

1. Group Name

The first field is the group’s textual name. Administrators and commands commonly use this name when assigning ownership, changing membership, or referring to permissions. Linux ultimately uses the associated numeric GID internally, but names make administration easier for people.

2. Historical Group-Password Field

The second field is the historical group-password field. On systems using shadow group information, an x commonly indicates that protected data, if used, is stored in /etc/gshadow rather than directly in /etc/group.

Some older or non-shadow arrangements may store an encrypted group password in this field. Group passwords are uncommon in modern Linux administration, so most administrators encounter x and do not use group-password login or switching workflows.

3. Numeric GID

The third field is the numeric GID, or group identifier. Linux uses the GID for group ownership and access checks. The group name and GID are related, but they are not the same thing: the name is a label resolved for humans and tools, while the number is the identifier stored in file metadata and used by the kernel.

For locally defined groups, each GID is normally expected to be unique. Duplicate GIDs can be intentional in unusual configurations, but an unexpected duplicate may cause confusing ownership and authorization results.

4. Comma-Separated Member List

The fourth field contains account names separated by commas. It represents supplementary group membership: additional groups associated with a user beyond that user’s primary group.

projectteam:x:5000:alice,bob

Do not insert spaces around commas. Use alice,bob, not alice, bob. An empty final field means that no users are explicitly listed as supplementary members:

developers:x:1200:

An empty member list does not mean the group is unusable. A user can still have that group as their primary group through the user’s account record.

Primary and Supplementary Groups

A user’s primary group is the user’s default group. For local accounts, the user’s /etc/passwd record contains the primary GID. The user’s name does not have to appear in the fourth field of the matching /etc/group record.

A supplementary group is an additional group to which the user belongs. Local supplementary membership is normally represented by placing the user’s account name in the fourth field of the group record.

Where Group Membership Is Recorded

Membership type | Primary source | How it is represented

Primary group | /etc/passwd or another NSS account source | The user record contains a GID

Supplementary group | /etc/group or another NSS group source | The group record lists user names

Primary-Membership Example

developers:x:1200:

Suppose an account record has a primary GID of 1200. That account has developers as its primary group even if the account name is absent from the empty member list. The account database establishes the primary-group relationship; the fourth field adds supplementary memberships.

Related Account Files and NSS

/etc/passwd supplies local user account names and, for each account, the primary GID. The group name associated with that GID is resolved through group databases such as /etc/group.

/etc/gshadow is the restricted companion file for shadowed group password and administrative information. The password field in /etc/group commonly contains x when this arrangement is enabled.

NSS, or Name Service Switch, is the mechanism Linux uses to obtain identity data from configured sources. Besides local files, an NSS configuration may use LDAP, SSSD, NIS, or another directory service. Consequently, a group visible to applications may not have a local line in /etc/group.

Use name-service-aware commands when checking the groups Linux can resolve, rather than relying only on a direct read of the local file.

Safe Inspection Commands

Read the Local File

cat /etc/group

This displays locally stored group records. It does not necessarily show groups supplied only by LDAP, SSSD, NIS, or another NSS provider.

Query Configured Name Services

getent group
getent group projectteam

getent group lists group records resolved through configured name-service sources. The second command looks up one group by name.

Inspect a User’s Effective Groups

id alice
groups alice

id shows the user’s UID, primary GID, and supplementary groups in a clear form. groups displays the groups associated with the user; use id when you need an explicit primary-versus-supplementary view.

Administrative Tools

Prefer locking-aware system utilities over casual direct editing. These tools update related account data in the format expected by the operating system:

groupadd projectteam
usermod -aG projectteam alice
gpasswd -a alice projectteam
  • groupadd projectteam creates a group.
  • usermod -aG projectteam alice adds alice to a supplementary group.
  • The -a option is essential with -G. Without -a, usermod -G can replace the user’s existing supplementary-group list.
  • gpasswd -a alice projectteam is an alternative way to add a member.

If manual repair is unavoidable, use appropriate privileges, create a backup first, preserve the exact four-field syntax, and use a locking-aware method. Run a consistency check afterward:

grpck

Do not treat a text editor as a substitute for account-management tools, especially on systems with shadow files or centralized identity services.

Troubleshooting

The User Is Not Listed but Appears to Belong to the Group

The group may be the user’s primary group. Run:

id username

Compare the user’s primary GID with the group’s GID. Primary membership comes from the account record and does not require the username in the group’s fourth field.

The Group Is Missing from /etc/group but Applications Recognize It

The group may come from an NSS identity source rather than the local file. Check it with:

getent group groupname

If identity-source configuration is relevant, review the group sources configured in /etc/nsswitch.conf.

A New Membership Is Missing in an Existing Terminal

Group credentials are normally established when a session begins. Start a new login session and run id username again. A shell that was already running may not automatically acquire the changed supplementary groups.

Other Supplementary Groups Disappeared

This commonly happens when usermod -G is used without -a. Inspect the current result and restore required memberships with an append operation:

id username
usermod -aG groupname username

Tools Report Malformed Group Data

Possible causes include an incorrect field count, an invalid GID, unintended whitespace, or an invalid member-list format. Run:

grpck

Verify that each local record follows the four-field colon-separated structure and that member names are comma-separated without spaces around the commas.

Exam-Relevant Notes

  • /etc/group is a local plain-text group database.
  • Its four fields are group name, password field, GID, and member list.
  • The password field is commonly x when protected group data is kept in /etc/gshadow.
  • The GID is numeric and is used internally for ownership and access checks.
  • The fourth field lists supplementary members and may be empty.
  • Primary membership is determined by the user’s GID in /etc/passwd or another NSS account source.
  • getent and id are generally more useful than reading only /etc/group when NSS or effective membership matters.
  • Use usermod -aG, not plain usermod -G, when adding a supplementary membership while preserving existing memberships.

For related Linux command-line and file-management concepts, see Linux, showing the full path of shell commands, and determining file types.