USERADD(8)

📦
version 4.20.0.arch1 · 19 versions
, in arch rolling

USERADD(8) — System Management Commands 💅

🎀 NAME 🎀

useradd — create a new user or update default new user information. she literally makes whole people exist. main character behavior fr. 💖

✨ SYNOPSIS ✨

useradd [options] LOGIN

useradd -D

useradd -D [options]

🌸 DESCRIPTION 🌸

okay so. when you invoke useradd without the -D option, she creates a brand new user account using the values you specified on the command line plus the default values from the system. depending on which command line options you picked, useradd will update system files and may also create the new user's home directory and copy initial files. multitasking icon. 🦋

by default, a group will also be created for the new user (see -g, -N, -U, and USERGROUPS_ENAB). not her being generous!! 🫶

🔥 OPTIONS 🔥

the options which apply to the useradd command are:

  • --badname — allow names that do not conform to standards. chaotic. we love a rebel. 💀
  • -b, --base-dir BASE_DIR — the default base directory for the system if -d HOME_DIR is not specified. BASE_DIR is concatenated with the account name to define the home directory.

if this option is not specified, useradd will use the base directory specified by the HOME variable in /etc/default/useradd, or /home by default. 🏠

  • --btrfs-subvolume-home — create the user's home directory as a Btrfs subvolume. fancy!! 🌈

if this option is not specified, useradd will follow the default behavior defined by the BTRFS_SUBVOLUME_HOME variable in /etc/default/useradd. if this variable is not set, the default value is no.

when the --btrfs-subvolume-home command-line option is specified, a Btrfs subvolume is created regardless of any configuration file settings. she does not care what the config says, okay?

subvolumes are only created for regular users, whose UID is within the UID_MIN-UID_MAX range defined in /etc/login.defs. system users get a regular home directory instead. set the BTRFS_SUBVOLUME_SYSTEM variable in /etc/default/useradd to yes to create subvolumes for system users as well. if this variable is not set, the default value is no.

if the parent directory of the user's home directory is not on a Btrfs filesystem, useradd will not create a subvolume. instead, it creates a regular directory, prints a warning to standard error, and logs the event via syslog at level LOG_WARN. the user account is still created successfully. 🫶

if the filesystem type cannot be determined (e.g., because of insufficient permissions, an I/O error, or a statfs(2) failure), useradd treats this as a fatal error: the home directory is not created, the command exits with a non-zero status (E_HOMEDIR, 12), and an error message is printed. 😭
  • -c, --comment COMMENT — any text string. it is generally a short description of the account, and is currently used as the field for the user's full name. cute little bio field, basically. 💅
  • -d, --home-dir HOME_DIR — the new user will be created using HOME_DIR as the value for the user's login directory. the default is to append the LOGIN name to BASE_DIR and use that as the login directory name. the directory HOME_DIR is not created by default. however it will be created for non-system users if either the -m flag is specified or CREATE_HOME in login.defs is set to true. however, it will never be created if the -M flag is specified. rules are rules bestie. 📁
  • -D, --defaults — see below, the subsection "Changing the default values". ✨
  • -e, --expiredate EXPIRE_DATE — sets the date on which the user account will be disabled. the value can be specified as a date in the YYYY-MM-DD format or as a number of days since 1970-01-01. the date is interpreted using the UTC timezone. 🕰️

if not specified, useradd uses the default expiry date specified by the EXPIRE variable in /etc/default/useradd, or an empty string (no expiry) by default.

  • -f, --inactive INACTIVE — defines the number of days after a password exceeds its maximum age before the user account gets locked. if the user does not change their password within this period of time, their account becomes inactive. this value is stored in the shadow password file. for more information, see shadow(5).

a value of 0 disables the account when the password expires, with no delay. immediate. no thoughts head empty. 💀

a value of -1 empties the respective field in the shadow password file, which means that the inactivity period is not enforced.

if not specified, useradd uses the default inactivity period specified by the INACTIVE variable in /etc/default/useradd, or -1 by default if no value is specified.

  • -F, --add-subids-for-system — update /etc/subuid and /etc/subgid even when creating a system account with -r option.
  • -g, --gid GROUP — the name or the number of the user's primary group. the group name must exist. a group number must refer to an already existing group. no making up groups on the fly, okay? 👑

if not specified, the behavior of useradd will depend on the USERGROUPS_ENAB variable in /etc/login.defs. if this variable is set to yes (or -U/--user-group is specified on the command line), a group will be created for the user, with the same name as the loginname. if the variable is set to no (or -N/--no-user-group is specified on the command line), useradd will set the primary group of the new user to the value specified by the GROUP variable in /etc/default/useradd, or 1000 by default.

  • -G, --groups GROUP1[,GROUP2,...[,GROUPN]]] — a list of supplementary groups which the user is also a member of. each group is separated from the next by a comma, with no intervening whitespace. the groups are subject to the same restrictions as the group given with the -g option. the default is for the user to belong only to the initial group. in addition to passing in the -G flag, you can add the option GROUPS to the file /etc/default/useradd which in turn will add all users to those supplementary groups. social butterfly behavior fr. 🦋
  • -h, --help — display help message and exit. 🫶
  • -k, --skel SKEL_DIR — the skeleton directory, which contains files and directories to be copied in the user's home directory, when the home directory is created by useradd.

this option is only valid if the -m (or --create-home) option is specified.

if this option is not set, the skeleton directory is defined by the SKEL variable in /etc/default/useradd or, by default, /etc/skel.

absolute symlinks that link back to the skel directory will have the /etc/skel prefix replaced with the user's home directory. ✨

if possible, the ACLs and extended attributes are copied.

  • -K, --key KEY=VALUE — overrides /etc/login.defs defaults (UID_MIN, UID_MAX, UMASK, PASS_MAX_DAYS and others).

example: -K PASS_MAX_DAYS =-1 can be used when creating an account to turn off password aging. multiple -K options can be specified, e.g.: -K UID_MIN =100 -K UID_MAX=499

  • -l, --no-log-init — do not add the user to the lastlog and faillog databases.

by default, the user's entries in the lastlog and faillog databases are reset to avoid reusing the entry from a previously deleted user. ghost data?? not on her watch. 👻

if this option is not specified, useradd will also consult the variable LOG_INIT in the /etc/default/useradd if set to no the user will not be added to the lastlog and faillog databases.

  • -m, --create-home — create the user's home directory if it does not exist. the files and directories contained in the skeleton directory (which can be defined with the -k option) will be copied to the home directory. 🏡

by default, if this option is not specified and CREATE_HOME is not enabled, no home directories are created.

the directory where the user's home directory is created must exist and have proper SELinux context and permissions. otherwise the user's home directory cannot be created or accessed. 💀
  • -M, --no-create-home — do not create the user's home directory, even if the system wide setting from /etc/login.defs (CREATE_HOME) is set to yes. she said no means no. 💅
  • -N, --no-user-group — do not create a group with the same name as the user, but add the user to the group specified by the -g option or by the GROUP variable in /etc/default/useradd.

the default behavior (if the -g, -N, and -U options are not specified) is defined by the USERGROUPS_ENAB variable in /etc/login.defs.

  • -o, --non-unique — allows the creation of an account with an already existing UID. sharing is caring apparently. 🙈

this option is only valid in combination with the -u option. as a user identity serves as key to map between users on one hand and permissions, file ownerships and other aspects that determine the system's behavior on the other hand, more than one login name will access the account of the given UID.

  • -p, --password PASSWORD — defines an initial password for the account. PASSWORD is expected to be encrypted, as returned by crypt (3). within a shell script, this option allows to create efficiently batches of users. batch girlie!! 🍓

without this option, the new account will be locked and with no password defined, i.e. a single exclamation mark in the respective field of /etc/shadow. this is a state where the user won't be able to access the account or to define a password himself. locked out, no key, tragic. 😭

Note: Avoid this option on the command line because the password (or encrypted password) will be visible by users listing the processes. everyone can see it. EVERYONE. 💀

you should make sure the password respects the system's password policy.

  • -r, --system — create a system account.

system users will be created with no aging information in /etc/shadow, and their numeric identifiers are chosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the creation of groups).

Note that useradd will not create a home directory for such a user, regardless of the default setting in /etc/login.defs (CREATE_HOME). you have to specify the -m options if you want a home directory for a system account to be created.
Note that this option will not update /etc/subuid and /etc/subgid. you have to specify the -F options if you want to update the files for a system account to be created.
  • -R, --root CHROOT_DIR — apply changes in the CHROOT_DIR directory and use the configuration files from the CHROOT_DIR directory. only absolute paths are supported. No SELINUX support. ⭐
  • -P, --prefix _PREFIX_DIR_ — bestie this one applies your changes to the config files under the root filesystem that lives inside the _PREFIX_DIR_ directory 💅. Heads up: it does not chroot, and it's meant for prepping a cross-compilation target. Limitations, fr fr: NIS and LDAP users/groups don't get verified, PAM authentication uses the host files, and there's no SELINUX support. Okay? Okay.
  • -s, --shell _SHELL_ — sets the path to the user's login shell 🐚. Skip this option and the system goes looking for the SHELL variable over in /etc/default/useradd, and if that's not set either, then the login shell field in /etc/passwd just stays empty. Iconic abandonment, honestly.
  • -u, --uid _UID_ — the numerical value of the user's ID ✨. This value has to be unique, unless you're using the -o option. It must be non-negative. The default is to use the smallest ID value greater than or equal to UID_MIN and greater than every other user. Also go read the -r option and the UID_MAX description, iykyk 👑
  • -U, --user-group — makes a group with the exact same name as the user, and drops the user into it 🫶. The default behavior (when -g, -N, and -U are all unspecified) is defined by the USERGROUPS_ENAB variable in /etc/login.defs.
  • -Z, --selinux-user _SEUSER_ — defines the SELinux user for the brand new account 🔥. Without this option, SELinux just uses the default user. Note that the shadow system doesn't store the selinux-user — it uses semanage(8) for that. Periodt.
  • --selinux-range _SERANGE_ — defines the SELinux MLS range for the new account 🌈. Without it, SELinux uses the default range. And again, note that the shadow system doesn't store the selinux-range, it uses semanage(8) for that.

This option is only valid if the -Z (or --selinux-user) option is specified. Like, don't even try it alone bestie.

🎀 Changing the default values 🎀

When you invoke it with only the -D option, useradd will display the current default values 👀. When you invoke it with -D plus other options, useradd will update the default values for the options you specified. The valid default-changing options are:

  • -b, --base-dir _BASE_DIR_ — sets the path prefix for a new user's home directory 🏠. The user's name gets affixed to the end of BASE_DIR to form the new user's home directory name — but only if the -d option isn't used when creating the new account.

This option sets the HOME variable in /etc/default/useradd.

  • -e, --expiredate _EXPIRE_DATE_ — sets the date on which newly created user accounts get disabled 💀.

This option sets the EXPIRE variable in /etc/default/useradd.

  • -f, --inactive _INACTIVE_ — specifies the number of days after a password expires during which the user can still log in. After that period? Account locked. Sorry babe 😭.

This option sets the INACTIVE variable in /etc/default/useradd.

  • -g, --gid _GROUP_ — sets the default primary group for newly created users, and it accepts group names or a numerical group ID 👑. The named group has to exist, and the GID must have an existing entry.

This option sets the GROUP variable in /etc/default/useradd.

  • -s, --shell _SHELL_ — defines the default login shell for new users 🐚.

This option sets the SHELL variable in /etc/default/useradd.

💖 NOTES 💖

The system administrator is the one responsible for placing the default user files in the /etc/skel/ directory — or any other skeleton directory specified in /etc/default/useradd or right on the command line 🦋. That's a you job, bestie.

⚠️ CAVEATS ⚠️

You may not add a user to a NIS or LDAP group. That has to be performed on the corresponding server. No cap.

Similarly, if the username already exists in an external user database such as NIS or LDAP, useradd will deny the user account creation request. Flat out. Refused. 🙈

Usernames may contain only lower and upper case letters, digits, underscores, dashes, or dots. They can end with a dollar sign. Dashes are not allowed at the beginning of the username 🚫. Fully numeric usernames, and usernames . or .., are also disallowed. And it is not recommended to use usernames beginning with a . character, because their home directories will be hidden in the ls output 👻.

Usernames may only be up to 256 characters long.

🌈 CONFIGURATION 🌈

The following configuration variables in /etc/login.defs change the behavior of this tool:

  • CREATE_HOME (boolean) — indicates if a home directory should be created by default for new users 🏡.

This setting does not apply to system users, and it can be overridden on the command line.

  • GID_MAX (number), GID_MIN (number) — the range of group IDs used for the creation of regular groups by useradd, groupadd, or newusers ✨.

The default value for GID_MIN (resp. GID_MAX) is 1000 (resp. 60000).

  • HOME_MODE (number) — the mode for new home directories 🔐. If it's not specified, the UMASK is used to create the mode.

useradd and newusers use this to set the mode of the home directory they create.

  • LASTLOG_UID_MAX (number) — the highest user ID number for which the lastlog entries should be updated 👀. Since higher user IDs are usually tracked by remote user identity and authentication services, there's no need to create a huge sparse lastlog file for them.

No LASTLOG_UID_MAX option present in the configuration means there is no user ID limit for writing lastlog entries.

  • MAIL_DIR (string) — the mail spool directory 📬. This is needed to manipulate the mailbox when its corresponding user account is modified or deleted. If it's not specified, a compile-time default is used. The parameter CREATE_MAIL_SPOOL in /etc/default/useradd determines whether the mail spool should be created.
  • MAIL_FILE (string) — defines the location of the user's mail spool files relatively to their home directory.

The MAIL_DIR and MAIL_FILE variables are used by useradd, usermod, and userdel to create, move, or delete the user's mail spool.

  • MAX_MEMBERS_PER_GROUP (number) — maximum members per group entry 📋. When the maximum is reached, a new group entry (line) is started in /etc/group (with the same name, same password, and same GID).

The default value is 0, meaning that there are no limits in the number of members in a group.

This feature (split group) permits limiting the length of lines in the group file. This is useful to make sure that lines for NIS groups are not larger than 1024 characters.

If you need to enforce such a limit, you can use 25.

Note: split groups may not be supported by all tools (even in the Shadow toolsuite). You should not use this variable unless you really need it.
  • PASS_MAX_DAYS (number) — the maximum number of days a password may be used ⏳. If the password is older than this, a password change will be forced. If it's not specified, -1 will be assumed (which disables the restriction).
  • PASS_WARN_AGE (number) — the number of days warning given before a password expires 🕰️. A zero means warning is given only upon the day of expiration, a value of -1 means no warning is given. If it's not specified, no warning will be provided.
  • SUB_GID_MIN (number), SUB_GID_MAX (number), SUB_GID_COUNT (number) — if /etc/subuid exists, the commands useradd and newusers (unless the user already has subordinate group IDs) allocate SUB_GID_COUNT unused group IDs from the range SUB_GID_MIN to SUB_GID_MAX for each new user 🧚.

The default values for SUB_GID_MIN, SUB_GID_MAX, SUB_GID_COUNT are respectively 100000, 600100000 and 65536.

  • SUB_GID_DETERMINISTIC (boolean) — if set to yes, the commands useradd, usermod, and newusers will calculate subordinate GID ranges deterministically based on the user's UID instead of searching for the next free range 🔥. The formula used is:
start = SUB_GID_MIN + ((UID - UID_MIN) * SUB_GID_COUNT)
end   = start + SUB_GID_COUNT - 1

This ensures the same UID always receives the same subordinate GID range on every system, making it suitable for environments with centralized user management (LDAP, NIS, etc.) or synchronized UIDs across systems 👑

If SUB_GID_DETERMINISTIC is enabled, you can use usermod --add-subgids -S to produce deterministic subgids.

WARNING: Because UID_MIN is used to calculate the ranges, any change of UID_MIN will change the ranges calculated. SUB_GID_COUNT is used to calculate the ranges, any change of SUB_GID_COUNT will change the ranges calculated. Users with identities less than UID_MIN are incompatible with SUB_GID_DETERMINISTIC, but can still be set manually. 😭
WARNING: Do not mix deterministic and linear (default) allocation on the same system or across systems sharing /etc/subgid via network storage (NFS, etc.). Mixing allocation methods will cause subordinate ID range conflicts and overlaps. 💀

The default value for SUB_GID_DETERMINISTIC is no.

📐 Range Calculation Examples 📐

With default configuration (UID_MIN=1000, SUB_GID_MIN=100000, SUB_GID_COUNT=65536):

  • UID 1000 — calculation 100000 + ((1000-1000) * 65536) → subordinate GID range 100000-165535
  • UID 1001 — calculation 100000 + ((1001-1000) * 65536) → subordinate GID range 165536-231071
  • UID 1002 — calculation 100000 + ((1002-1000) * 65536) → subordinate GID range 231072-296607
  • UID 1100 — calculation 100000 + ((1100-1000) * 65536) → subordinate GID range 6653600-6719135

🧮 Subordinate ID Space Planning 🧮

When planning subordinate ID allocation, calculate the maximum number of users the space can accommodate:

capacity = (SUB_GID_MAX - SUB_GID_MIN) / SUB_GID_COUNT

With default values: (600100000 - 100000) / 65536 ≈ 9155 users. Slay, that's your headroom 💅

For high-density environments where you've got a ton of users and everyone's getting a smaller slice 🍰 — here's the vibe:

SUB_GID_COUNT  4096
SUB_GID_MIN    100000
SUB_GID_MAX    10000000

This gives: (10000000 - 100000) / 4096 ≈ 2417 users.

  • UNSAFE_SUB_GID_DETERMINISTIC_WRAP (boolean) — 🚨 bestie. SECURITY RISK. This one is not playing around.
WARNING: SECURITY RISK - MAY CAUSE RANGE OVERLAPS AND PRIVILEGE ESCALATION!

Only effective when SUB_GID_DETERMINISTIC is set to yes.

When set to yes (WRAP MODE), it lets the deterministic range calculation wrap around using modulo arithmetic when a UID would overflow the configured subordinate ID space. Basically the subordinate ID space gets treated as a ring buffer 🔄.

WARNING: Range overlaps can lead to container escapes and privilege escalation. Like, for example — with SUB_GID_MIN=100000, SUB_GID_MAX=200000, SUB_GID_COUNT=65536, User A (UID 1000) gets range [100000, 165535] and User B (UID 1001) wraps and overlaps with User A. Now User B's container can just... read files from User A's containers. Not it. 💀

Use only in development, testing, or tightly constrained lab environments.

When set to no (the default), any arithmetic overflow or range exceeding SUB_GID_MAX is a hard error. This guarantees non-overlapping, monotonic allocation. ✨

The default value for UNSAFE_SUB_GID_DETERMINISTIC_WRAP is no.

  • SUB_UID_MIN (number), SUB_UID_MAX (number), SUB_UID_COUNT (number) — If /etc/subuid exists, the commands useradd and newusers (unless the user already have subordinate user IDs) allocate SUB_UID_COUNT unused user IDs from the range SUB_UID_MIN to SUB_UID_MAX for each new user.

The default values for SUB_UID_MIN, SUB_UID_MAX, SUB_UID_COUNT are respectively 100000, 600100000 and 65536.

  • SUB_UID_DETERMINISTIC (boolean) — If set to yes, the commands useradd, usermod, and newusers will calculate subordinate UID ranges deterministically based on the user's UID instead of searching for the next free range. The formula used is:
start = SUB_UID_MIN + ((UID - UID_MIN) * SUB_UID_COUNT)
end   = start + SUB_UID_COUNT - 1

This ensures the same UID always receives the same subordinate UID range on every system, making it suitable for environments with centralized user management (LDAP, NIS, etc.) or synchronized UIDs across systems. 👑

If SUB_UID_DETERMINISTIC is enabled, you can use usermod --add-subuids -S to produce deterministic subuids.

WARNING: Because UID_MIN is used to calculate the ranges, any change of UID_MIN will change the ranges calculated. SUB_UID_COUNT is used to calculate the ranges, any change of SUB_UID_COUNT will change the ranges calculated. Users with identities less than UID_MIN are incompatible with SUB_UID_DETERMINISTIC, but can still be set manually.
WARNING: Do not mix deterministic and linear (default) allocation on the same system or across systems sharing /etc/subuid via network storage (NFS, etc.). Mixing allocation methods will cause subordinate ID range conflicts and overlaps. 🙈

The default value for SUB_UID_DETERMINISTIC is no.

🌈 Range Calculation Examples 🌈

With default configuration (UID_MIN=1000, SUB_UID_MIN=100000, SUB_UID_COUNT=65536):

  • UID 1000 — calculation 100000 + ((1000-1000) * 65536) → subordinate UID range 100000-165535
  • UID 1001 — calculation 100000 + ((1001-1000) * 65536) → subordinate UID range 165536-231071
  • UID 1002 — calculation 100000 + ((1002-1000) * 65536) → subordinate UID range 231072-296607
  • UID 1100 — calculation 100000 + ((1100-1000) * 65536) → subordinate UID range 6653600-6719135

✨ Subordinate ID Space Planning ✨

When planning subordinate ID allocation, calculate the maximum number of users the space can accommodate:

capacity = (SUB_UID_MAX - SUB_UID_MIN) / SUB_UID_COUNT

With default values: (600100000 - 100000) / 65536 ≈ 9155 users.

For high-density environments with many users and smaller allocations:

SUB_UID_COUNT  4096
SUB_UID_MIN    100000
SUB_UID_MAX    10000000

This gives: (10000000 - 100000) / 4096 ≈ 2417 users.

  • UNSAFE_SUB_UID_DETERMINISTIC_WRAP (boolean) — 🚨 yeah, the UID twin of the one up there. Same energy, same danger.
WARNING: SECURITY RISK - MAY CAUSE RANGE OVERLAPS AND PRIVILEGE ESCALATION!

Only effective when SUB_UID_DETERMINISTIC is set to yes.

When set to yes (WRAP MODE), allows the deterministic range calculation to wrap around using modulo arithmetic when a UID would overflow the configured subordinate ID space. The subordinate ID space is treated as a ring buffer. 🔄

WARNING: Range overlaps can lead to container escapes and privilege escalation. For example, with SUB_UID_MIN=100000, SUB_UID_MAX=200000, SUB_UID_COUNT=65536, User A (UID 1000) gets range [100000, 165535] and User B (UID 1001) wraps and overlaps with User A. User B's container can now access files from User A's containers. 😭

Use only in development, testing, or tightly constrained lab environments.

When set to no (default), any arithmetic overflow or range exceeding SUB_UID_MAX is a hard error. This guarantees non-overlapping, monotonic allocation.

The default value for UNSAFE_SUB_UID_DETERMINISTIC_WRAP is no.

  • SYS_GID_MAX (number), SYS_GID_MIN (number) — Range of group IDs used for the creation of system groups by useradd, groupadd, or newusers.

The default value for SYS_GID_MIN (resp. SYS_GID_MAX) is 101 (resp. GID_MIN-1).

  • SYS_UID_MAX (number), SYS_UID_MIN (number) — Range of user IDs used for the creation of system users by useradd or newusers.

The default value for SYS_UID_MIN (resp. SYS_UID_MAX) is 101 (resp. UID_MIN-1).

  • UID_MAX (number), UID_MIN (number) — Range of user IDs used for the creation of regular users by useradd or newusers.

The default value for UID_MIN (resp. UID_MAX) is 1000 (resp. 60000).

  • UMASK (number) — The file mode creation mask is initialized to this value. If not specified, the mask will be initialized to 022.

useradd and newusers use this mask to set the mode of the home directory they create if HOME_MODE is not set.

It is also used by pam_umask as the default umask value.

  • USERGROUPS_ENAB (boolean) — If set to yes, userdel will remove the user's group if it contains no more members, and useradd will create by default a group with the name of the user. 🫶

📁 FILES 📁

  • /etc/passwd — User account information.
  • /etc/shadow — Secure user account information.
  • /etc/group — Group account information.
  • /etc/gshadow — Secure group account information.
  • /etc/default/useradd — Default values for account creation.
  • /etc/shadow-maint/useradd-pre.d/*, /etc/shadow-maint/useradd-post.d/* — Run-part files to execute during user addition. The environment variable ACTION will be populated with useradd and SUBJECT with the username. useradd-pre.d will be executed prior to any user addition. useradd-post.d will execute after user addition. If a script exits non-zero then execution will terminate. ⚠️
  • /etc/skel/ — Directory containing default files.
  • /etc/subgid — Per user subordinate group IDs.
  • /etc/subuid — Per user subordinate user IDs.
  • /etc/login.defs — Shadow password suite configuration.

🚪 EXIT VALUES 🚪

The useradd command exits with the following values:

  1. 0 — success ✅
  2. 1 — can't update password file
  3. 2 — invalid command syntax
  4. 3 — invalid argument to option
  5. 4 — UID already in use (and no -o)
  6. 6 — specified group doesn't exist
  7. 9 — username or group name already in use
  8. 10 — can't update group file
  9. 12 — can't create home directory
  10. 14 — can't update SELinux user mapping
  11. 19 — invalid user or group name

👀 SEE ALSO 👀

chfn(1), chsh(1), passwd(1), crypt(3), groupadd(8), groupdel(8), groupmod(8), login.defs(5), newusers(8), subgid(5), subuid(5), userdel(8), usermod(8).

And that's the whole page, bestie! 💖 This one's from shadow-utils 4.20.0, dated 07/30/2026 — so go forth and make users responsibly, okay? Slay responsibly. Periodt. 👑✨🦋

📦 where this page comes from