VMware ESXi and vSphere Cluster Management

Understanding the Linux /etc/group File Format

Learn the Linux /etc/group file format, including its four fields, GIDs, primary and supplementary membership, /etc/gshadow, NSS, and safe administration commands.

What Is /etc/group?

/etc/group is the local, plain-text database of Unix and Linux groups. A group is a named collection of accounts used to assign shared access to files, directories, devices, and other resources.

The file defines group names, numeric group identifiers (GIDs), and users listed as supplementary members. Linux may obtain group information from several sources, however. The Name Service Switch (NSS) determines which sources are consulted. Depending on the system, group data can come from local files, LDAP, SSSD, or another directory service in addition to, or instead of, /etc/group.

File Characteristics

  • The standard path is /etc/group.
  • It is a line-oriented plain-text file.
  • Each non-comment entry normally describes one group.
  • Fields are separated by colons (:).
  • The file is commonly readable by users because many programs need to resolve group names and memberships.
  • Writing the file is normally restricted because malformed or inconsistent records can interfere with account and permission lookups.

A line beginning with # is commonly treated as a comment. Blank lines may also be ignored by account-management tools. Do not assume that every group visible to the operating system is physically present in this file: use NSS-aware commands when you need the system-wide view.

The Four-Field Entry Format

Each group record has this general layout:

group_name:password_field:GID:member_list

The fields must remain in this order. Empty fields are valid in some positions. The final field is a comma-separated list of login names and normally contains no spaces.

Field 1 — group name: The textual name used to identify the group.

Field 2 — password field: Historical group-password data or a placeholder such as x.

Field 3 — GID: The numeric group identifier used internally by the operating system.

Field 4 — member list: Comma-separated users assigned as supplementary members.

Basic Example

developers:x:5000:alice,bob
  • developers is the group name.
  • x indicates that protected group-password information is expected in the shadow group database.
  • 5000 is the numeric GID.
  • alice and bob are listed as supplementary members.

The Group Name Field

The first field is the human-readable group name. Administrators use it in commands, and utilities display it when showing file ownership or account information. For example, a directory might be displayed as owned by root:developers, where developers is the group name.

Group names are also used when administering permissions with tools such as chgrp and when adding users to groups. Naming rules vary by distribution and local policy. In practice, names should be consistent with the operating system's account-management tools and should avoid characters or formats rejected by that system.

The Password Field

The second field exists because Unix historically supported passwords associated with groups. A group password could allow a user to enter a group temporarily, although modern administration generally manages explicit membership instead.

On many Linux systems, this field contains x. That placeholder means protected group-password and administrative membership information is expected in /etc/gshadow rather than being exposed in the ordinary group file. On systems using an older arrangement, an encrypted password may appear directly in the second field.

The password field should not be interpreted as a normal user password field. Contemporary Linux administration usually uses commands such as usermod, gpasswd, or distribution-specific account tools to control group membership.

The GID Field

GID means numeric group identifier. The kernel and filesystems use numeric IDs internally when recording group ownership and evaluating access. The group name is a convenient textual label that a configured name service maps to the numeric GID.

System groups are generally created for operating-system services and resources, while regular user-created groups are commonly used for people collaborating on files. The exact numeric ranges and policies differ between distributions, so the distinction is conceptual rather than a universal rule.

GIDs must be managed carefully. Duplicate or changed GIDs can cause unexpected ownership and access results. A file owned by numeric GID 5000 can appear to belong to a different group if the name mapped to that number changes. If no configured source maps the number to a name, ownership may be displayed as an unknown numeric ID.

The Member List Field

The fourth field contains login names assigned to the group as supplementary members. Names are separated by commas:

projectteam:x:5010:alice,bob,carol

An empty final field means that no users are explicitly listed as supplementary members:

projectteam:x:5010:

The member list does not necessarily show every user who belongs to the group. In particular, it does not normally repeat users whose primary group is this group.

Primary and Supplementary Group Membership

A user's primary group is the group identified by the user's primary GID in the user account record, normally in /etc/passwd for a local account. A supplementary group is any additional group assigned to the user.

The local membership picture therefore comes from both /etc/passwd and /etc/group:

Primary group membership — Primary data source: /etc/passwd. Representation: the user's primary GID points to a group record. Important note: the username does not need to appear in that group's fourth field.

Supplementary group membership — Primary data source: the fourth field of /etc/group. Representation: a comma-separated username list. Important note: this is additional membership beyond the primary group.

Protected group-password data — Primary data source: /etc/gshadow. Representation: protected password and administrative fields, often associated with x in /etc/group. Important note: the local database files should remain consistent.

Example: An Empty Member List Can Be Correct

Suppose the projectteam record is:

projectteam:x:5010:

Suppose a user's account record has primary GID 5010. That user is still a member of projectteam as their primary group, even though their name is absent from the member list. Looking only at the fourth field would miss this relationship.

Use id to view the combined result of the account and group databases:

id alice

The output identifies the user's UID, primary GID, and current supplementary groups. groups alice provides another convenient membership view.

Relationship to /etc/gshadow

/etc/gshadow is a protected local database that can store group-password information and administrative membership data. A common arrangement is for the second field in /etc/group to contain x, while the sensitive information is stored in /etc/gshadow with tighter permissions.

These files describe related account data. Manual changes to one without considering the other can produce inconsistent results. Prefer account-management utilities, which are designed to update the relevant files together and preserve their expected structure.

Inspecting Groups Safely

Read-only commands are preferable when you are investigating a group. To inspect only the local record for developers, use:

grep '^developers:' /etc/group

To ask the system's configured NSS sources for the group, use:

getent group developers

getent is often the better diagnostic because it can find groups supplied by local files, LDAP, SSSD, or other configured sources. To list all groups available through those sources:

getent group

The lookup order and sources are configured in /etc/nsswitch.conf. A typical configuration may include files and a directory-backed source, but the exact entries depend on the host.

Recommended Administration Tools

View a group — getent group developers — Retrieve a group through configured name services. Safety consideration: this is read-only and may show a non-local source.

List a user's groups — id alice or groups alice — Display primary and supplementary memberships. Safety consideration: current process credentials may differ from a newly configured login.

Create a group — groupadd developers — Create a local group. Safety consideration: check naming and GID policies first.

Modify group membership — usermod -aG developers alice — Add a user while preserving existing supplementary groups. Safety consideration: the -a append option is important.

Alternative membership administration — gpasswd -a alice developers — Add a user through the group administration utility. Safety consideration: verify the result afterward.

Group-specific modification — groupmod -a -U alice developers — Add a user on systems supporting these options. Safety consideration: option support varies, so check the local command documentation.

Remove a group — groupdel developers — Delete a local group. Safety consideration: do not remove a group still required as a user's primary group or by files and services.

Validate local databases — grpck — Check syntax and consistency of local group database files. Safety consideration: review proposed corrections carefully.

Why Direct Editing Is Risky

Although /etc/group is text, it is an account database rather than an ordinary notes file. A manually edited line should have exactly four colon-separated fields in the expected order. Common mistakes include deleting a colon, inserting spaces into the member list, using an invalid GID, duplicating a group name, or making /etc/group and /etc/gshadow inconsistent.

Account-management tools are generally safer because they can apply policy checks and update companion databases. If direct editing is unavoidable, make a protected backup, use a suitable locking or account-file editing mechanism, preserve permissions, and validate afterward with grpck. Avoid editing while another account-management operation is running.

Permissions and Operational Impact

Group membership affects access to group-owned files and directories. For example, consider a directory owned by root:developers with group write permission. A user recognized as a member of developers may receive that group permission, subject to the directory's mode bits, ACLs, process credentials, and other security controls.

Adding a user to a supplementary group does not necessarily alter credentials in an already-running login session. The user may need to start a new login session, reconnect, or otherwise refresh credentials. Confirm the active result with:

id alice

Membership changes also do not override more restrictive controls. File ownership, permission bits, POSIX ACLs, mandatory access controls, and application-specific authorization can all affect the final access decision.

Troubleshooting Common Problems

A User Appears Absent from a Group

The group may be the user's primary group. Run id with the username and compare the user's primary GID with the target group's GID. A match confirms membership even if the name is not present in the fourth field of /etc/group.

A Newly Added User Cannot Access Group-Owned Files

The existing session may not have refreshed its supplementary group credentials. Start a new login session or reconnect, then run id to verify the active group list.

A Group Is Not Found in /etc/group

The group may be supplied by a non-local identity provider. Run getent group or getent group group_name instead of inspecting only the local file. Review the group-related entry in /etc/nsswitch.conf, and check the directory-service or SSSD configuration where applicable.

Other Memberships Disappeared After an Edit

A user-management command may have been run without its append option. Inspect the result with id or groups. When adding a supplementary group with usermod, use -aG, not merely -G, so existing supplementary memberships are preserved.

Group Lookup Reports a Malformed Record

Run grpck. Review the affected line for four colon-separated fields, valid GID data, and a properly formatted comma-separated member list. Use supported account-management tools to correct the record where possible.

File Ownership Shows an Unknown Numeric GID

No current group source may map that numeric ID to a name, perhaps because the group was removed or its GID was changed. Query the configured sources with getent group and, where supported, query by the numeric GID. Before recreating or changing a group, review existing filesystem ownership so that access is not changed accidentally.

Exam-Relevant Notes

  • /etc/group is a local text database, not necessarily the only source of group information.
  • The field order is group_name:password_field:GID:member_list.
  • The fourth field lists supplementary members and does not necessarily include primary members.
  • A user's primary GID is normally stored in their /etc/passwd account record.
  • x in the password field commonly indicates that protected group data is stored in /etc/gshadow.
  • Linux uses numeric GIDs internally for ownership and permission checks.
  • Use getent for NSS-aware inspection and account-management utilities for changes.
  • After membership changes, a new session may be required before credentials reflect the change.