Understanding the Linux /etc/passwd File Format

Learn how to read Linux /etc/passwd entries, including all seven colon-separated fields, UIDs, GIDs, shells, shadow passwords, NSS, and safe administration.

/etc/passwd is a plain-text database of local account information on Unix-like systems. Each account entry describes a login identity and its attributes, such as its username, numeric IDs, home directory, and login shell.

Despite its name, modern systems do not normally store usable password hashes in this broadly readable file. Password information is commonly kept in the protected /etc/shadow file instead.

What /etc/passwd is used for

Programs frequently need to translate between a human-readable username and the numeric identity used by the operating system. For example, a file may be owned by UID 1001, while commands display the corresponding username such as bob.

/etc/passwd is generally readable by all users because ordinary programs need account-name and identity lookups. Both human login accounts and system or service accounts can appear in it.

Security note: Broad read access to /etc/passwd is normal. Password hashes are normally separated into /etc/shadow, whose access is restricted.

The seven-field record layout

The file is plain text with one account per line. Each line contains seven fields separated by colon delimiters:

login_name:password_field:UID:primary_GID:GECOS:home_directory:login_shell

Colons identify field boundaries, so an ordinary field value cannot contain a colon as part of its content. Blank lines and comments may be handled differently by tools, but valid account records follow the seven-field layout.

Position	Field name	Typical value	Purpose	Key cautions
1	Username	`bob`	The account's textual login name.	Must be unique within the local account database.
2	Password field	`x`	Historical password location or a marker for shadow passwords.	A marker is not an actual password. Empty, locked, and shadow-password states differ.
3	UID	`1001`	Numeric user identifier used by the kernel and filesystem.	Identity is numeric; the username is only its label.
4	Primary GID	`1001`	Numeric identifier of the account's primary group.	Additional groups are not listed in this field.
5	GECOS/comment	`Bob Jones`	Descriptive account information.	It does not control authentication or permissions.
6	Home directory	`/home/bob`	Intended home-directory path.	The path may not exist or have correct ownership.
7	Login shell	`/bin/bash`	Program started for an interactive login session.	It affects login behavior, not the user's currently running shell process.

Field 1: username

The first field is the account's login name, such as bob or websvc. It provides a readable label that tools use to map an account to its numeric UID and primary GID.

Usernames must be unique within the local account database. A username is not the same as a UID: the username can be changed or removed, while file ownership and process identity are ultimately based on numeric IDs.

Field 2: password field and shadow passwords

Historically, the second field held password data. Modern Unix-like systems commonly place password hashes and password-aging information in /etc/shadow. The value x in /etc/passwd commonly means that password information is expected in /etc/shadow.

x is a placeholder, not a password. Separating the hash from the broadly readable passwd file limits exposure of sensitive authentication data.

Value or pattern	Typical meaning	Where password data is expected	Administrative note
`x`	Password information is handled through shadow passwords.	`/etc/shadow` or the configured authentication service.	Normal on many modern local-account systems.
`!`	Often indicates a locked or unusable password.	Usually shadow data or account-management state.	Exact interpretation can vary by distribution and tool.
`*`	Often marks an account whose password cannot be used for normal password login.	Usually shadow data or another authentication policy.	Do not assume this alone describes every available login method.
Empty field	No value is present in the password field.	Depends on the system's authentication rules.	Has security implications and is not equivalent to `x`, `!`, or `*`.

Markers are interpreted alongside /etc/shadow, PAM rules, SSH configuration, keys, and other authentication mechanisms. Do not expose password hashes while troubleshooting.

Field 3: UID

UID means user identifier. It is the number the kernel uses to identify a user for processes, permissions, and filesystem ownership. When a command displays a username, it is resolving that name from a numeric UID.

Each account should have an appropriate unique UID in normal administration. The ranges used for regular users, system users, and service accounts depend on distribution policy, so do not assume that one numeric range applies everywhere.

Field 4: primary GID

GID means group identifier. The fourth field gives the numeric ID of the account's primary group. The matching group definition is typically in /etc/group or is supplied by a configured name service.

A user can also belong to supplementary groups. Those additional memberships are not fully represented by the primary-GID field; use id USERNAME to view the resolved group memberships.

The primary group commonly influences the group ownership assigned to newly created files. Directory setgid settings, umasks, applications, and other system behavior can affect the final result.

Field 5: GECOS or comment

The fifth field contains descriptive account metadata. For a human account it often contains a full name, such as Bob Jones. Some systems or tools use comma-separated subfields for information such as office location, phone number, or other contact details.

This is descriptive data. It does not authenticate the account and does not grant filesystem permissions.

Field 6: home directory

The sixth field is the account's intended home-directory path, usually an absolute path such as /home/bob. Login programs and applications commonly use it as the starting directory and as the location for user-specific configuration.

A path in /etc/passwd does not create the directory or guarantee that it exists, is accessible, or has correct ownership and permissions. Service accounts may intentionally use a nonstandard path or a location such as /nonexistent.

Field 7: login shell

The seventh field names the program started for an interactive login session. Common examples include /bin/bash and /bin/sh.

Service or disabled-login accounts may use /usr/sbin/nologin or /bin/false, depending on the system. These values commonly prevent ordinary interactive shell access. The configured login shell is distinct from the shell process that a user happens to be running now.

Reading an account entry

Interactive user example

bob:x:1001:1001:Bob Jones:/home/bob:/bin/bash

bob: the login name.
x: a common indication that password data is expected in /etc/shadow.
1001: Bob's UID.
1001: Bob's primary GID.
Bob Jones: descriptive GECOS information.
/home/bob: the intended home directory.
/bin/bash: the login shell.

Service account example

websvc:x:987:987:Web service account:/nonexistent:/usr/sbin/nologin

This account has a system-assigned UID and GID. Its nonstandard home path may be intentional, and nologin commonly prevents ordinary interactive shell access. The exact UID and GID ranges for service accounts vary by distribution.

Related files and account lookup services

/etc/passwd is only one part of local account management:

/etc/shadow commonly stores password hashes and password-aging data with restricted permissions.
/etc/group defines groups, including the group corresponding to a user's primary GID and supplementary group memberships.
NSS, or Name Service Switch, determines where the system looks up users and groups. Sources can include local files, LDAP, SSSD, and other configured services.

Because NSS can use nonlocal sources, /etc/passwd is not always the complete view of accounts recognized by the system. getent passwd queries the configured account sources.

Method	Data source scope	Best use
`cat /etc/passwd` or filtered file reading	The local passwd file only.	Inspect local account records. Use paging or filtering for long output.
`getent passwd`	All passwd sources configured through NSS.	View accounts as the system resolves them.
`id USERNAME`	Resolved identity and group sources.	Show UID, primary GID, and supplementary groups.

Safe inspection commands

cat /etc/passwd
getent passwd
getent passwd bob
grep '^bob:' /etc/passwd
id bob
getent group 1001
getent group developers

grep '^bob:' /etc/passwd checks the local file only. In contrast, getent passwd bob uses NSS and may return a directory-service account that has no local entry.

id bob displays the resolved UID, primary GID, and supplementary groups. getent group 1001 can help find the group associated with a numeric GID.

Safe administration practices

Avoid casually editing /etc/passwd with a general-purpose editor. A missing delimiter, an invalid numeric field, a duplicate identity, or an accidental deletion can prevent account access or disrupt services.

For routine changes, prefer account-management commands such as useradd, usermod, passwd, and userdel. For example:

usermod -s /bin/bash bob
passwd -l bob

The first command changes the login shell through an account-management tool. The second is an example of locking password-based authentication. Login behavior can also depend on SSH settings, PAM policy, keys, and other authentication methods.

When direct editing of the local passwd database is truly necessary, use vipw. It provides locking and participates in validation workflows. Make a verified backup and follow local recovery procedures if a change causes lookup or login failures.

Troubleshooting /etc/passwd problems

The account is not in /etc/passwd

Use getent passwd USERNAME. If it returns an entry, the account comes from a configured NSS source rather than the local file. If it returns nothing, inspect the configured identity service and NSS setup.

The user cannot obtain an interactive shell

Inspect the final field of the resolved entry. A shell of /usr/sbin/nologin, /bin/false, a missing path, or a policy-disallowed shell can prevent interactive access. Also check separate authentication and access-control settings.

The home directory causes errors

Verify that the configured directory exists. Check its ownership and permissions using the account's UID and primary group, and confirm that the path in the resolved passwd entry is correct. The entry records an intended path; it does not validate or create it.

The password marker is unexpected

Determine whether x indicates shadow-password use, then use authorized administrative tools to inspect account status without exposing hashes. Check whether the account is locked and whether another authentication method is being used.

Ownership displays numeric IDs

Filesystem ownership is numeric. Test name resolution with getent passwd UID and getent group GID. If resolution fails, the relevant local or directory-service mapping may be unavailable.

A manual edit broke account lookups

Check for exactly seven colon-separated fields, valid numeric UID and GID values, sensible paths, and duplicate identities. Use vipw for future direct edits and restore from a verified backup or follow the system's recovery procedure.

Exam-relevant summary

/etc/passwd is a broadly readable, plain-text account database; it normally does not contain usable password hashes on modern systems.
Each account record has seven colon-separated fields: username, password placeholder, UID, primary GID, GECOS/comment, home directory, and login shell.
UIDs and GIDs are numeric identities used by the kernel and filesystem; names are resolved labels.
The primary GID is only one group membership. Supplementary groups are separate.
x commonly points to shadow-password data. ! and * commonly indicate an unusable or locked password, but exact interpretation varies.
getent passwd follows NSS and can show accounts from local or network sources, while direct file reading shows only local records.
Use account-management tools for routine changes and vipw when a direct local passwd-file edit is unavoidable.

For related background, see Linux, Bourne Again Shell Bash, and Determine File Type.