VMware ESXi and vSphere Cluster Management

Understanding the /etc/passwd File Format in Linux

Learn how to read Linux /etc/passwd entries, including usernames, password markers, UIDs, GIDs, GECOS data, home directories, and login shells.

/etc/passwd is a local account database used by Linux and other Unix-like systems. It is a plain-text file containing one account record per line. Each record describes a user or service account through seven colon-separated fields.

The file can contain regular human accounts as well as system accounts used by daemons and applications. It is commonly readable by ordinary users because many programs need basic identity information such as usernames, numeric IDs, home directories, and login shells.

The seven-field record format

A typical account entry has this format:

username:password:UID:GID:GECOS:home_directory:login_shell

Fields are separated by literal colon characters. Field order is significant, and each line represents one account. A field should not contain an unescaped colon because the colon is the record delimiter.

Understanding each field

1. Username

The first field is the username, also called the login or account name. It is the human-readable name that people and programs use to refer to an account.

The username is not the same as the UID. Tools often display both, but the kernel and filesystem use the numeric UID as the underlying user identity.

2. Password placeholder

The second field historically held password information. On systems using shadow passwords, it commonly contains x. This marker tells account-management and authentication software to look in /etc/shadow for the protected password data.

Common values include:

The exact result of a password marker depends on the configured authentication stack. A nonstandard value should not be interpreted without checking the system's authentication configuration.

3. UID

The UID, or user identifier, is a numeric identity used by the kernel, processes, and filesystems. File ownership is fundamentally associated with numeric UIDs, even when commands display a username.

A UID should uniquely identify an account within the relevant identity source. A system may resolve identities from local files, directory services, or other sources, so uniqueness must be considered in that environment.

Many distributions assign low or specially designated UIDs to system accounts and higher UIDs to regular users. The exact ranges are distribution- and policy-dependent; they are conventions, not universal rules.

4. GID

The GID, or group identifier, identifies the account's primary group. The number normally maps to a group record in /etc/group or another configured group source.

Every user account has one primary group, but an account can also belong to supplementary groups. Supplementary groups provide additional access beyond the primary group and are usually resolved from group membership data.

Newly created files normally receive the creator's effective primary group. Directory settings such as the setgid bit, process behavior, and other system policies can change the resulting group ownership.

5. GECOS or comment field

The fifth field is commonly called the GECOS field or comment field. It is descriptive rather than an authorization identity. It often contains a person's full name, but local conventions may use comma-separated subfields for information such as an office, room, or telephone number.

The kernel does not use the full name in this field to determine file ownership or permission. The UID and group identifiers provide the relevant security identity.

6. Home directory

The sixth field is the absolute path intended to be the account's home directory. After login, a user normally starts there, and personal configuration files are commonly stored there.

The entry only records the intended path. It does not guarantee that the directory exists, is mounted, has the correct owner, or has usable permissions.

7. Login shell

The seventh field identifies the user's default login shell or another login program. Common interactive shells include /bin/bash, /bin/sh, and /bin/zsh.

Service accounts often use /usr/sbin/nologin or /bin/false. These programs prevent ordinary interactive shell sessions and are useful for accounts intended to run a daemon rather than represent a human login.

A non-interactive shell setting is different from password locking. The shell controls what happens when a login program attempts to start the account's shell; password locking affects password authentication. Either, or both, may be used to restrict access.

Reading a regular-user entry

Consider this representative record:

alice:x:1001:1001:Alice Example:/home/alice:/bin/bash

1. alice: the username.
2. x: password information is expected in /etc/shadow.
3. 1001: Alice's numeric UID.
4. 1001: Alice's primary GID.
5. Alice Example: descriptive GECOS information.
6. /home/alice: the intended home directory.
7. /bin/bash: the default interactive login shell.

Reading a service-account entry

A service account is used by a daemon or application rather than by a human interactive user. For example:

websvc:x:997:997:Web Service Account:/nonexistent:/usr/sbin/nologin

Here, websvc is the account name, the password marker points to shadow password data, and the UID and GID are numeric service identifiers. The home path is /nonexistent, indicating that the service is not expected to use a normal personal home directory. The nologin shell prevents ordinary interactive shell access.

The low UID and GID in this example are only examples. System-account ranges and home-directory conventions vary by distribution and organization.

Relationship to /etc/shadow and /etc/group

/etc/shadow

/etc/shadow is a protected local file that commonly stores password hashes, password expiration information, and other password-aging fields. On a shadow-enabled system, the x in /etc/passwd connects the account record to its password data without exposing the hash in the broadly readable passwd file.

/etc/group

/etc/group maps group names to GIDs and can list supplementary group members. The GID in a passwd entry identifies the user's primary group, while additional memberships may be found in group records or other configured identity sources.

For example, to map a primary GID to a group record, run:

getent group 1001

Name Service Switch and other identity sources

NSS, or Name Service Switch, lets account and group lookups use configured sources. A system may combine local files with directory services or other providers. Therefore, a user that can be resolved by the operating system does not necessarily have a line directly in the local /etc/passwd file.

Use getent passwd alice when you want the account record as resolved through the configured identity sources:

getent passwd alice

Safe inspection commands

These commands are read-only inspection examples:

• getent passwd lists passwd entries as resolved through configured identity sources.
• getent passwd alice looks up one account by username.
• id alice displays the UID, primary GID, and supplementary groups for an account.
• grep '^alice:' /etc/passwd searches specifically in the local passwd file.
• cut -d: -f1,3,4,6,7 /etc/passwd displays selected fields for format inspection.

This command labels selected fields from a resolved account record:

getent passwd alice | awk -F: '{print "user=" $1 ", uid=" $3 ", gid=" $4 ", home=" $6 ", shell=" $7}'

Administration and editing practices

Avoid manually editing /etc/passwd with a general-purpose text editor. A missing field, incorrect delimiter, duplicate identifier, invalid shell, or partially written file can disrupt account resolution and login.

Prefer account-aware tools such as:

• useradd to create accounts.
• usermod to modify account properties.
• passwd to manage password authentication.
• vipw when a direct passwd-file edit is unavoidable; it provides a system-aware editor and locking workflow.
• pwck -r for a read-only consistency check on systems that support it.

Make administrative changes through a validated workflow, keep backups according to local policy, and confirm the result with getent, id, and appropriate account-management tools.

Troubleshooting common problems

A username cannot be resolved

Run:

getent passwd username

Possible causes include a nonexistent account, a spelling mismatch, or an unavailable or incorrectly configured centralized identity service. If a local account is expected, check the local file with a delimiter-aware search such as grep '^username:' /etc/passwd. If the environment uses centralized identity, review its configured name-service sources.

A user cannot obtain an interactive shell

Inspect field seven with getent passwd username. A shell such as /usr/sbin/nologin or /bin/false restricts interactive shell access. Other possibilities include a locked password, an authentication policy restriction, or a shell path that does not exist or is not permitted by local policy.

The expected home directory is unavailable

Compare the field-six path with the filesystem. The directory may not exist, may have incorrect ownership or permissions, or may be on an unavailable network mount.

Created files have an unexpected group owner

Use id username to inspect the primary GID and getent group GID to resolve its group name. Also inspect the target directory: a setgid directory can cause new files to inherit the directory's group, and an application can change its effective group.

Account tools report malformed passwd data

Use pwck -r where supported. Check that the affected record has seven correctly ordered fields, that no unintended colon appears inside a field, and that the UID, GID, home path, and shell are valid. Correct the record with supported account-management tools or vipw, not an unsafe direct edit.

Exam-relevant summary

• /etc/passwd is a plain-text account database with one colon-delimited record per line.
• The seven fields are username, password placeholder, UID, GID, GECOS/comment, home directory, and login shell.
• The UID is the numeric user identity used for processes and file ownership.
• The GID identifies the account's primary group; supplementary groups are resolved separately.
• x usually means password data is stored in /etc/shadow.
• /usr/sbin/nologin and /bin/false restrict interactive shell access, but they are not the same as password locking.
• The listed home directory may not exist or have correct permissions.
• getent follows configured NSS sources, while direct inspection of /etc/passwd only examines the local file.

For related account-file concepts, see the Linux passwd file format reference.