Linux online course

Linux User IDs (UIDs) and Group IDs (GIDs)

Learn how Linux UIDs and GIDs identify users and groups, control ownership and permissions, and support account administration and troubleshooting.

Linux uses numeric identities to decide who owns a file, which groups a process belongs to, and whether an operation is permitted. A username or group name is a human-readable label; the kernel and file systems ultimately work with a numeric user identifier (UID) and group identifier (GID).

This lesson covers how UIDs and GIDs work, where account information is stored, how to inspect identity mappings, and how to manage ownership and group membership safely.

UID and GID concepts

Why Linux uses numeric identities

When a program accesses a file, Linux compares the process credentials with the file's stored numeric owner and group values. Names are resolved for display and administration, but the file system stores a UID and GID rather than the text alice or projectteam.

A process has a user identity and a set of group identities. Permission checks compare those credentials with the file owner, file group, and permission classes:

• User: permissions for the file's owning UID.
• Group: permissions for processes whose group list includes the file's owning GID.
• Other: permissions for processes that do not match the owner or applicable group.

Account names can change, and different systems can assign different names to the same number. The numeric mapping is therefore important when files are copied, restored, mounted, or shared.

User identifiers (UIDs)

A UID is a numeric user identifier associated with an account. For example, a local account might resolve as alice:x:1001:1001:Alice:/home/alice:/bin/bash. In this record, 1001 is the UID and the next numeric field, 1001, is the account's primary GID.

UID 0 has a special role: it is normally the UID of the root account. The kernel treats UID 0 as privileged, although individual operations can still be constrained by security mechanisms and system configuration. Do not assign UID 0 to an ordinary account.

Linux distributions commonly separate identifiers into broad categories:

• System or service accounts run daemons and applications. They usually have restricted login capabilities and lower-numbered UIDs.
• Regular user accounts are intended for people and commonly use a later range of UIDs.
• Reserved or high-number ranges can be used for special purposes, containers, directory services, or future allocation.

The exact ranges vary by distribution, release, container environment, and local policy. Check the relevant system configuration rather than assuming that a particular numeric boundary applies everywhere.

Group identifiers (GIDs)

A GID is a numeric identifier for a group. Each group has both a human-readable name and a numeric GID. Groups allow administrators to grant access to several users without assigning permissions separately to every account.

A user's primary group is the group identified by the user's primary GID. It is used as the default group identity for many processes and commonly becomes the group owner of newly created files, subject to directory settings and application behavior.

Supplementary groups are additional memberships. They extend a user's group list and can grant access to shared directories, devices, or services. A user can have one primary group and many supplementary groups.

$ id alice
uid=1001(alice) gid=1001(alice) groups=1001(alice),1050(projectteam),27(sudo)

In this example, alice has UID 1001, primary GID 1001, and supplementary memberships in projectteam and sudo. Membership in a privileged group deserves particular review because it may grant more access than intended.

Local account database files

A typical /etc/passwd line has seven colon-separated fields:

name:x:UID:GID:comment:home:shell

These files describe local identities, but they are not always the complete identity source. Linux uses NSS (Name Service Switch) to choose configured sources and their order. The configuration in /etc/nsswitch.conf may use local files, LDAP, Active Directory integration, or other directory and network services.

Inspecting identity information

Use id for numeric identity and memberships

Run id to inspect the current account:

$ id
uid=1001(alice) gid=1001(alice) groups=1001(alice),1050(projectteam)

Inspect a named account with id username:

$ id username

This displays the UID, primary GID, and supplementary groups. It can query an identity supplied by a configured name-service source, not only a local account.

Use whoami for the current username

$ whoami
alice

whoami shows the effective username for the current shell. It does not show numeric UIDs or group memberships, so use id when those details matter.

Use getent for system-wide identity lookups

getent queries the sources configured through NSS:

$ getent passwd username
$ getent group groupname
$ getent passwd
$ getent group

The last two commands can produce extensive output on systems connected to a directory service. To query by numeric value, use the number as the key where the configured database supports it:

$ getent passwd 1001
$ getent group 1050

Inspect local files safely

When you specifically need local records, use anchored searches rather than an unbounded substring search:

$ grep '^username:' /etc/passwd
$ grep '^groupname:' /etc/group
$ grep '^[^:]*:[^:]*:1001:' /etc/passwd
$ grep '^[^:]*:[^:]*:1050:' /etc/group

Use getent when you need the system's complete configured identity view. Use /etc/passwd or /etc/group searches when you intentionally want only local-file records.

Ownership, permissions, and IDs

The owner and group shown by ls -l are name resolutions of numeric metadata. For example:

$ ls -l project.txt
-rw-rw---- 1 alice projectteam 1200 Aug 16 10:00 project.txt

$ ls -ln project.txt
-rw-rw---- 1 1001 1050 1200 Aug 16 10:00 project.txt

ls -ln avoids name resolution and shows the stored UID and GID directly. stat provides more detailed metadata:

$ stat project.txt

If a file shows a familiar name but has an unexpected numeric ID, or if a numeric owner appears with no name, the name-to-number mapping may not be what you expect. Access decisions use the numbers, not the displayed spelling of an account name.

For a shared project directory, check all of the following:

• The directory's numeric owner and group.
• The user, group, and other permission bits.
• The user's primary and supplementary groups.
• Execute permission on every parent directory, which is required to traverse the path.
• Any ACLs or security policy that add restrictions or permissions beyond the basic mode bits.

chown changes an owner and optionally a group. chgrp changes only the group:

$ sudo chown username:projectteam path
$ sudo chgrp projectteam path

Use these commands with administrative care. A recursive ownership change can affect configuration files, sockets, libraries, or unrelated data beneath a directory.

Creating and modifying users and groups

Common account-management commands include:

• useradd or the distribution-specific adduser creates a user account.
• groupadd creates a group.
• usermod changes account properties and memberships.
• groupmod changes group properties, including a GID when appropriate.

For example, create a project group and add an existing user as a supplementary member:

$ sudo groupadd projectteam
$ sudo usermod -aG projectteam username
$ id username

The -aG combination is important: -a appends the group, while -G specifies supplementary groups. Omitting -a can replace the user's existing supplementary-group list, possibly removing required access.

A user's primary group can be selected when creating an account or changed with an appropriate usermod operation. Create or change a group's numeric GID with groupadd or groupmod only when an established policy requires it.

Specify a UID or GID explicitly only for a documented reason, such as a migration or coordinated shared-storage design. Arbitrary values can create collisions, ownership confusion, or security problems. Avoid manually editing /etc/passwd, /etc/group, or /etc/shadow while accounts are active unless you understand locking, consistency, running processes, and recovery consequences. Prefer the account-management tools, and verify the result afterward.

UID/GID consistency and portability

File systems store numeric ownership. Suppose a file owned by UID 1001 is copied from one host to another. If UID 1001 means alice on the first host but serviceuser on the second, the destination may display the file as belonging to serviceuser. The file did not change its stored UID; the mapping changed.

This issue commonly appears with:

• Copied files and synchronized directories.
• Restored backups and extracted archives.
• Mounted disks moved between machines.
• Containers whose internal accounts use IDs that differ from the host.
• NFS and other shared storage systems.
• Shared project directories used by multiple hosts.

When migrating accounts or sharing files, preserve or coordinate the required UIDs and GIDs. Before changing anything, compare numeric ownership with ls -ln and inspect mappings with getent. If coordinated IDs are not appropriate, repair ownership after transfer with a carefully scoped chown or chgrp.

Security and administration considerations

• Duplicate UIDs can cause two account names to act as the same file owner. This can create unintended access and auditing confusion.
• Unexpected membership in groups such as administrative, device, storage, or service-specific groups can grant powerful access.
• A user's primary identity is not the same as elevated privileges obtained through sudo or another privilege-management tool.
• Follow least privilege: grant only the groups and ownership needed for the task.
• Review the exact target before using recursive ownership or permission changes.
• Verify account records, group memberships, and file metadata after every change.

Troubleshooting UID and GID problems

Practical workflow

1. Identify the account with whoami or id.
2. Inspect the target using ls -l, ls -ln, and, when needed, stat.
3. Resolve names and numbers with getent.
4. Check primary and supplementary groups, including whether the current session has refreshed after a membership change.
5. Check every directory in the path and consider ACLs or service policy.
6. Make the smallest administrative change necessary with account tools, chown, or chgrp.
7. Repeat the identity and ownership checks, then test access as the affected user.

Summary

UIDs identify users and GIDs identify groups. Linux stores these numbers in process credentials and file metadata, then evaluates them against owner, group, and other permission classes. Use id for a complete identity view, whoami for the current username, getent for NSS-aware lookups, and ls -ln or stat to confirm numeric ownership. Coordinate IDs across systems that share or move files, and make account, group, and ownership changes conservatively.

For related fundamentals, see Linux topics.