NEWUSERS(8)

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

✨ NEWUSERS(8) ✨ — System Management Commands

okay bestie, gather round, because newusers is THAT girl 💅 — she's the batch account creator/updater from the System Management Commands crew, and she does NOT do things one at a time. This is part 1 of 2, so buckle up 🎀

🌸 NAME 🌸

newusers — update and create new users in batch

🦋 SYNOPSIS 🦋

newusers [options] [file]

💖 DESCRIPTION 💖

So here's the vibe: newusers reads a file (or standard input if you don't hand her one, that's her default, no cap) and uses whatever's in there to update a whole set of existing users or create brand new ones. Every single line follows the same format as the standard password file — peep passwd(5) for that — with the little exceptions we're about to spill below:

pw_name:pw_passwd:pw_uid:pw_gid:pw_gecos:pw_dir:pw_shell

🔤 pw_name

This is the name of the user.

It can be the name of a new user or the name of an existing user (or a user that was created earlier by newusers). If the user already exists, their info gets changed; if not, a new user gets created. Simple as that ✨

🔐 pw_passwd

If this field is not empty, it will be encrypted and used as the new value of the encrypted password.

🆔 pw_uid

This field is used to define the UID of the user.

  • If the field is empty, a new (unused) UID will be defined automatically by newusers.
  • If this field contains a number, this number will be used as the UID.
  • If this field contains the name of an existing user (or the name of a user created before by newusers), the UID of the specified user will be used.
If the UID of an existing user is changed, the files ownership of the user's file should be fixed manually. like, nobody's gonna do that for you, bestie 🫶

👯 pw_gid

This field is used to define the primary group ID for the user.

  • If this field contains the name of an existing group (or a group created before by newusers), the GID of this group will be used as the primary group ID for the user.
  • If this field is a number, this number will be used as the primary group ID of the user. If no groups exist with this GID, a new group will be created with this GID, and the name of the user.
  • If this field is empty, a new group will be created with the name of the user and a GID will be automatically defined by newusers to be used as the primary group ID for the user and as the GID for the new group.
  • If this field contains the name of a group which does not exist (and was not created before by newusers), a new group will be created with the specified name and a GID will be automatically defined by newusers to be used as the primary group ID for the user and GID for the new group.

📇 pw_gecos

This field is copied in the GECOS field of the user.

🏠 pw_dir

This field is used to define the home directory of the user.

If this field does not specify an existing directory, the specified directory is created, with ownership set to the user being created or updated and its primary group. Heads up though: newusers does not create parent directories of the new user's home directory. So if the parent directories don't exist, newusers will fail to create the home directory and will send a message to stderr informing the user of the failure. The newusers command will not halt or return a failure to the calling shell if it fails to create the home directory — it will just keep processing the batch of new users specified. she's resilient like that 😭

If the home directory of an existing user is changed, newusers does not move or copy the content of the old directory to the new location. That's a you problem, do it manually 💀

🐚 pw_shell

This field defines the shell of the user. No checks are performed on this field. none. zero. she trusts you completely 🙈

newusers first tries to create or change all the specified users, and then write these changes to the user or group databases. If an error occurs (except in the final writes to the databases), no changes are committed to the databases.

During this first pass, users are created with a locked password (and passwords are not changed for the users which are not created). A second pass is used to update the passwords using PAM. Failures to update a password are reported, but will not stop the other password updates.

This command is intended to be used in a large system environment where many accounts are updated at a single time. it's giving enterprise main character energy 👑

✨ OPTIONS ✨

The options which apply to the newusers command are:

  • --badname — Allow names that do not conform to standards. chaotic, love that for you 💅
  • -h, --help — Display help message and exit.
  • -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 login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the creation of groups).

  • -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.

🚨 CAVEATS 🚨

The input file must be protected since it contains unencrypted passwords. fr fr, guard that file with your life 🔥

⚙️ CONFIGURATION ⚙️

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

🎚️ GID_MAX (number), GID_MIN (number)

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 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.

👥 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 to limit 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 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. like, actually actually 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 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 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 have 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. iconic, honestly ✨

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. this is the part where things go very badly, so don't 💀

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.

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

                SUB_GID_COUNT  4096
                SUB_GID_MIN    100000
                SUB_GID_MAX    10000000

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

okay that's the whole config situation and we are SO not done yet, part 2 is right there bestie 💜

  • UNSAFE_SUB_GID_DETERMINISTIC_WRAP (boolean) — okay bestie, sit down for this one 💀
WARNING: SECURITY RISK - MAY CAUSE RANGE OVERLAPS AND PRIVILEGE ESCALATION!

This one is only effective when SUB_GID_DETERMINISTIC is set to yes. It's giving chaos, and not the cute kind.

When set to yes — that's WRAP MODE — it 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 gets treated as a ring buffer. 🎠

WARNING: Range overlaps can lead to container escapes and privilege escalation. Like, 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. User B's container can now access files from User A's containers. Absolutely NOT the vibe. 😭

Use only in development, testing, or tightly constrained lab environments. fr fr, do not deploy this.

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, which is the slay behaviour. 👑

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) — set it to yes and 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. Iconic for consistency. ✨

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. Not me watching you create a range war in your own infra 🙈

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 → 100000 + ((1000-1000) * 65536) → subordinate UID range 100000-165535
  • UID 1001 → 100000 + ((1001-1000) * 65536) → subordinate UID range 165536-231071
  • UID 1002 → 100000 + ((1002-1000) * 65536) → subordinate UID range 231072-296607
  • UID 1100 → 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) — the UID twin of the cursed one above. Same energy, same warning. 💀
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 main character range, lowkey. 👑

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.

📁 FILES 📁

  • /etc/passwd — user account information.
  • /etc/shadow — secure user account information. 🔒
  • /etc/group — group account information.
  • /etc/gshadow — secure group account information. 🔒
  • /etc/login.defs — shadow password suite configuration.
  • /etc/pam.d/newusers — PAM configuration for newusers.
  • /etc/subgid — per user subordinate group IDs.
  • /etc/subuid — per user subordinate user IDs.

👀 SEE ALSO 👀

login.defs(5), passwd(1), subgid(5), subuid(5), useradd(8).

okay bestie that's the whole page 🎀 you just read all of it, and honestly? slay. this was shadow-utils 4.20.0, dated 07/30/2026, and it lives at NEWUSERS(8) 💖 go forth and make users, but pls, pls, do not turn on the wrap modes. i'm begging. 🫶✨🌸

📦 where this page comes from