Linux online course

Linux UID and GID: User and Group Identifiers Explained

Learn how Linux UIDs and GIDs identify users and groups, affect permissions and ownership, and can be inspected or assigned with common commands.

Linux uses numeric identities to decide who owns files, which groups a process belongs to, and whether an operation is allowed. A UID identifies a user, while a GID identifies a group. Account and group names are convenient labels, but the kernel relies primarily on the numeric values.

For background, review Linux file ownership and using grep to search text.

UID and GID concepts

A UID is a User Identifier: the number associated with a user account. A GID is a Group Identifier: the number associated with a group. Filesystem objects store an owning UID and an owning GID, and processes carry user and group credentials.

Names are resolved to numbers when commands display information. If a numeric UID or GID has no resolvable name, tools commonly display the number instead.

User IDs and the root identity

UID 0 conventionally represents the root account. The name “root” is a label; the important fact is the UID value. A process running with an effective UID of 0 normally has broad administrative authority, subject to restrictions from mechanisms such as capabilities, mandatory access controls, containers, or the operation itself.

System or service accounts generally use lower, policy-defined UID values. Regular interactive accounts often begin at a distribution-defined minimum; 1000 is common on many modern distributions, but it is not universal. Ranges are local conventions, not rules built into every Linux system.

When an account is created without an explicit UID, account-management tools commonly choose the next available eligible UID. The eligible range and selection behavior depend on command options, distribution defaults, and local policy.

Group IDs, primary groups, and supplemental groups

A GID identifies a group. GID 0 conventionally identifies the root group, although group membership and administrative privilege are separate concepts and should not be confused.

Every user account has a primary group. Its GID is stored in the user record and is used as the default group for many newly created files. A user can also belong to supplemental groups, which provide additional access to shared files, devices, and services.

System groups commonly use lower, policy-defined values, while regular groups may be allocated from another range. Actual starting values vary by distribution and configuration. Group membership is useful for collaboration: instead of granting access separately to many users, a file or directory can be owned by a shared group.

Where local identities are stored

The /etc/passwd file

/etc/passwd is the traditional local user-account database. It is a colon-separated file with these fields:

name:password-placeholder:UID:primary-GID:GECOS:home-directory:login-shell

For example, a record might look like this:

alice:x:2001:2000:Project User:/home/alice:/bin/bash

• The first field is the login name.
• The second field is commonly x, indicating that the password hash is stored elsewhere.
• The third field is the numeric UID.
• The fourth field is the user's primary GID.
• The remaining fields describe the account, home directory, and login shell.

Password hashes and password-aging information are normally protected in /etc/shadow, not stored directly in /etc/passwd.

The /etc/group file

/etc/group is the traditional local group database. Its fields are:

group-name:password-placeholder:GID:supplemental-member-list

For example:

projectteam:x:2000:alice,bob

The third field is the GID. The fourth field lists users recorded as supplemental members. A user's primary-group relationship is represented by the primary GID in /etc/passwd, so it may not appear in this member list.

NSS and directory services

Linux can resolve users and groups through NSS, the Name Service Switch. The configured sources may include local files, LDAP, Active Directory integration, or other directory services. The lookup order is commonly configured in /etc/nsswitch.conf.

Because identities may come from sources beyond local files, getent is often more complete than reading /etc/passwd or /etc/group directly.

Inspecting users, groups, and numeric ownership

Run these commands to inspect an account:

id
id alice
id -u alice
id -g alice
getent passwd alice
getent group projectteam

To inspect local files directly, use:

grep '^alice:' /etc/passwd
grep '^projectteam:' /etc/group

Ordinary ls -l output usually shows owner and group names. The numeric form makes the stored metadata explicit:

ls -l report.txt
ls -ln report.txt

The second command might show a result such as:

-rw-r----- 1 2001 2000 842 Mar 10 09:30 report.txt

Here, UID 2001 owns the file and GID 2000 is its group owner. A name-based listing renders those numbers as names when NSS can resolve them.

How UID and GID affect permissions

Each filesystem object has an owning UID and owning GID. Traditional Unix permission bits divide access into three classes:

• Owner: the process identity matches the file's owning UID.
• Group: the process has the file's owning GID among its group credentials.
• Other: everyone who matches neither the owner nor the group class.

For ordinary discretionary access checks, the kernel evaluates the process's effective UID and group memberships against the object's numeric ownership and permission bits. A process may have a primary group and several supplemental groups. The effective UID is the user identity a process uses for many permission checks; it may differ from the login account's real or saved credentials in special situations.

Numeric identity is therefore important even when names look identical. Two systems may both have an account named alice, but if one uses UID 2001 and the other uses UID 3001, shared storage generally treats them as different users.

Changing ownership

chown changes the owning user, and it can also set the group. chgrp changes only the group ownership:

sudo chown alice:projectteam report.txt
sudo chgrp projectteam report.txt

Use these commands carefully. Changing ownership does not automatically change the permission bits, and access may still be blocked by a parent directory, ACL, or service policy.

Creating and managing users and groups

Account-management tools can allocate IDs automatically or accept explicit values. Automatic allocation is usually safer because it follows local policy.

Create a group

sudo groupadd projectteam

To request a particular GID, first verify that it is unused and permitted by local policy:

getent group 2000
sudo groupadd -g 2000 projectteam

Create a user with a primary group

sudo useradd -m -g projectteam alice

This creates a home directory and assigns projectteam as the primary group. Distribution defaults can affect other account properties, so review the resulting record.

An explicit UID can be supplied when a site policy requires stable numeric identities:

getent passwd 2001
sudo useradd -m -u 2001 -g projectteam alice

Do not manually select a UID or GID that is already assigned. A collision can make files appear to belong to the wrong account and can grant unintended access.

Add supplemental membership

sudo usermod -aG projectteam alice

The -a option appends the group. Omitting it while using -G can replace the user's existing supplemental-group list. The user generally needs a new login session before the updated membership appears in the session's credentials.

Changing an existing UID or GID

usermod can change an existing account's identifiers, but this is a migration task rather than a simple rename. Existing files retain their old numeric ownership until they are updated. Inventory home directories, service data, scheduled jobs, mounted filesystems, containers, backups, and external services before making the change. Also consider processes that are already running with the old credentials.

ID allocation policy and distribution differences

On many systems using shadow-utils, /etc/login.defs contains defaults such as UID_MIN, UID_MAX, GID_MIN, and GID_MAX. These values influence account creation, but other tools, distributions, and directory services may apply different rules.

Do not assume that a particular number always identifies a system account or a regular user. Before assigning an explicit ID, inspect current records with getent, review local policy, and confirm that shared systems use compatible identity mappings.

Creating a shared project directory

A group-owned directory can provide a simple collaboration model:

sudo groupadd projectteam
sudo mkdir /srv/project
sudo chown root:projectteam /srv/project
sudo chmod 2770 /srv/project
sudo usermod -aG projectteam alice

The group ownership allows members of projectteam to use the directory when the group permission bits grant access. The leading 2 in mode 2770 sets the setgid directory bit, which commonly causes new files and subdirectories to inherit the directory's group. Check the resulting permissions and test from a refreshed user session.

Troubleshooting identity and ownership problems

A file shows a numeric owner or group

Possible causes include a missing local account, an unavailable directory service, incorrect NSS configuration, or a file copied from a system with different numeric mappings.

ls -ln path
getent passwd 2001
getent group 2000

If the lookups fail, inspect /etc/nsswitch.conf and the availability of any configured network identity service.

Same account name, unexpected access

Compare numeric identities rather than names:

id alice
getent passwd alice
ls -ln shared-file

Shared storage evaluates numeric IDs. Standardize IDs through local policy or centralized identity management when multiple systems must share ownership.

A new account receives an unexpected ID

Existing allocations, command options, distribution defaults, and site policy can all affect the result. Inspect records with getent, review /etc/login.defs where applicable, and check the exact useradd or groupadd options used.

Changing a UID leaves unknown ownership

Files owned by the old numeric UID do not automatically follow the account. Locate and update them carefully, including data outside the home directory and files on mounted or shared storage. Review running services and external systems that refer to the old UID.

New group membership has no effect

Start a new login session and run id again. If access still fails, inspect every parent directory and the target:

id
ls -ld /path /path/to /path/to/item

Check group ownership, mode bits, and ACLs when ordinary permissions do not explain the result.