USERMOD(8)

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

🎀 USERMOD(8) — System Management Commands 🎀

okay bestie, welcome to usermod, the glow-up command. she's from the System Management Commands crew and she is that girl. 💅

🌸 NAME 🌸

usermod — modify a user account. That's it, that's the whole vibe. No cap. 💖

✨ SYNOPSIS ✨

usermod [options] LOGIN

🦋 DESCRIPTION 🦋

so usermod modifies the system account files. that's the tea ☕. You hand her a LOGIN (a user that already exists) plus some options, and she edits that account's entry in the system account files. She does not create users — that's useradd's job, different girl entirely. 🫶

💅 OPTIONS 💅

The options which apply to the usermod command are:

  • -a, --append — adds the user to the supplementary group(s). Use only with the -G option. She's the "and also keep the old ones, bestie" flag. ✨
  • -b, --badname — allows names that do not conform to standards. yes, she will let you be messy on purpose. 🙈
  • -c, --comment COMMENT — updates the comment field of the user in /etc/passwd, which is normally modified using the chfn(1) utility. That's the lil "Full Name / office / phone" corner of the file, iykyk. 📝
  • -d, --home HOME_DIR — the user's new login directory. 🏠

If the -m option is given, the contents of the current home directory will be moved to the new home directory, which is created if it does not already exist. If the current home directory does not exist the new home directory will not be created.

  • -e, --expiredate EXPIRE_DATE — specifies 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.

An input of -1 or an empty string blanks the account expiration field in the shadow password file. The account will remain available with no expiration date.

This option requires the /etc/shadow file. If no entry exists in the /etc/shadow file, the system will automatically create one.

  • -f, --inactive INACTIVE — defines the number of days after a password exceeds its maximum age during which the user can still log in by immediately changing their password. 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. 😴

A value of 0 disables the account when the password expires, with no delay.

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

This option requires the /etc/shadow file. If no entry exist in the /etc/shadow file, the system will automatically create one.

  • -g, --gid GROUP — the name or numerical ID of the user's new primary group. The group must exist. 👑

Any file from the user's home directory owned by the previous primary group of the user will be owned by this new group.

The group ownership of files outside of the user's home directory must be fixed manually.

The change of the group ownership of files inside of the user's home directory is also not done if the home dir owner uid is different from the current or new user id. This is a safety measure for special home directories such as /.

  • -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 must exist. 🫂

If the user is currently a member of a group which is not listed, the user will be removed from the group. This behaviour can be changed via the -a option, which appends the user to the current supplementary group list.

  • -l, --login NEW_LOGIN — the name of the user will be changed from LOGIN to NEW_LOGIN. Nothing else is changed. In particular, the user's home directory or mail spool should probably be renamed manually to reflect the new login name. 💫
  • -L, --lock — lock a user's password. This puts a '!' in front of the encrypted password, effectively disabling the password. You can't use this option with -p or -U. 🔒

Note: if you wish to lock the account (not only access with a password), you should also set the EXPIRE_DATE to 1.

  • -m, --move-home — moves the content of the user's home directory to the new location. If the current home directory does not exist the new home directory will not be created. 📦

This option is only valid in combination with the -d (or --home) option.

usermod will try to adapt the ownership of the files and to copy the modes, ACL and extended attributes, but manual changes might be needed afterwards.

  • -o, --non-unique — allows to change the user ID to a non-unique value. 🙃

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 a new password for the user. PASSWORD is expected to be encrypted, as returned by crypt (3). 🔑
Note: Avoid this option on the command line because the password (or encrypted password) will be visible by users listing the processes. 😭 literally anyone with ps can see it, bestie, don't do it.

The password will be written in the local /etc/passwd or /etc/shadow file. This might differ from the password database configured in your PAM configuration.

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

  • -r, --remove — remove the user from named supplementary group(s). Use only with the -G option. the anti--a. 🚪
  • -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 — apply changes within the directory tree starting with PREFIX_DIR and use as well the configuration files located there. This option does not chroot and is intended for preparing a cross-compilation target. Some limitations: NIS and LDAP users/groups are not verified. PAM authentication is using the host files. No SELINUX support.
  • -s, --shell SHELL — changes the user's login shell. An empty string for SHELL empties the field in /etc/passwd and logs the user into the system's default shell. 🐚
  • -u, --uid UID — the new value of the user's ID. 🆔

This value must be unique, unless the -o option is used. The value must be non-negative.

The user's mailbox, and any files which the user owns and which are located in the user's home directory will have the file user ID changed automatically.

The ownership of files outside of the user's home directory must be fixed manually.

The change of the user ownership of files inside of the user's home directory is also not done if the home dir owner uid is different from the current or new user id. This is a safety measure for special home directories such as /.

No checks will be performed with regard to the UID_MIN, UID_MAX, SYS_UID_MIN, or SYS_UID_MAX from /etc/login.defs.

  • -U, --unlock — unlock a user's password. This removes the '!' in front of the encrypted password. You can't use this option with -p or -L. 🔓

Note: if you wish to unlock the account (not only access with a password), you should also set the EXPIRE_DATE (for example to 99999, or to the EXPIRE value from /etc/default/useradd).

  • -v, --add-subuids FIRST-LAST — add a range of subordinate uids to the user's account. 🌈

This option may be specified multiple times to add multiple ranges to a user's account.

No checks will be performed with regard to SUB_UID_MIN, SUB_UID_MAX, or SUB_UID_COUNT from /etc/login.defs.

  • -V, --del-subuids FIRST-LAST — remove a range of subordinate uids from the user's account. 🗑️

This option may be specified multiple times to remove multiple ranges to a user's account. When both --del-subuids and --add-subuids are specified, the removal of all subordinate uid ranges happens before any subordinate uid range is added.

No checks will be performed with regard to SUB_UID_MIN, SUB_UID_MAX, or SUB_UID_COUNT from /etc/login.defs.

  • -w, --add-subgids FIRST-LAST — add a range of subordinate gids to the user's account. 🌟

This option may be specified multiple times to add multiple ranges to a user's account.

No checks will be performed with regard to SUB_GID_MIN, SUB_GID_MAX, or SUB_GID_COUNT from /etc/login.defs.

  • -W, --del-subgids FIRST-LAST — remove a range of subordinate gids from the user's account. 🧹

This option may be specified multiple times to remove multiple ranges to a user's account. When both --del-subgids and --add-subgids are specified, the removal of all subordinate gid ranges happens before any subordinate gid range is added.

No checks will be performed with regard to SUB_GID_MIN, SUB_GID_MAX, or SUB_GID_COUNT from /etc/login.defs.

  • -S, --add-subids — add subordinate uids and gids to the user's account. 🎁

An appropriate uid and gid range is automatically selected from /etc/login.defs defaults.

  • -Z, --selinux-user SEUSER — defines the SELinux user to be mapped with LOGIN. An empty string ("") will remove the respective entry (if any). Note that the shadow system doesn't store the selinux-user, it uses semanage(8) for that. 🛡️
  • --selinux-range SERANGE — defines the SELinux MLS range for the new account. 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.

⚠️ CAVEATS ⚠️

You must make certain that the named user is not executing any processes when this command is being executed if the user's numerical user ID, the user's name, or the user's home directory is being changed. usermod checks this on Linux. On other operating systems it only uses utmp to check if the user is logged in. 😬 yeah bestie, log them out first.

You must change the owner of any crontab files or at jobs manually.

You must make any changes involving NIS on the NIS server.

🔧 CONFIGURATION 🔧

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

LASTLOG_UID_MAX (number) 🧾

Highest user ID number for which the lastlog entries should be updated. As higher user IDs are usually tracked by remote user identity and authentication services there is no need to create a huge sparse lastlog file for them.

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

and that's part one, bestie — we're not done yet, keep scrolling, the rest is coming 💜

  • MAIL_DIR (string) — where the mail spool directory lives, bestie. You need it so the tooling can go mess with somebody's mailbox when their user account gets modified or deleted. Leave it unset and a compile-time default gets used instead. Also, the CREATE_MAIL_SPOOL parameter over in /etc/default/useradd is what decides whether the mail spool should even be created in the first place.
  • MAIL_FILE (string) — sets where a user's mail spool files hang out, but relative to their home directory. 🏠

The MAIL_DIR and MAIL_FILE variables are the ones useradd, usermod, and userdel lean on to create, move, or delete a user's mail spool. It's giving teamwork.

  • MAX_MEMBERS_PER_GROUP (number) — max members allowed in one group entry. Hit the max and a whole new group entry (line) gets started in /etc/group, with the same name, same password, and same GID. Very "we're the same group, we just live in two houses."

Default value is 0, which means there are literally no limits on how many members a group can have. Freedom. ✨

This feature (split group) lets you cap how long the lines in the group file can get, which is genuinely useful for making sure lines for NIS groups don't grow past 1024 characters.

If you actually need to enforce that kind of limit, 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, really really.
  • 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) — set it to yes and the commands useradd, usermod, and newusers will calculate subordinate GID ranges deterministically, based on the user's UID, instead of hunting around for the next free range. The formula they use is:
start = SUB_GID_MIN + ((UID - UID_MIN) * SUB_GID_COUNT)
end   = start + SUB_GID_COUNT - 1

This guarantees the same UID always gets the same subordinate GID range on every single system, which makes it a whole vibe 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  │ Calculation    │ Subordinate GID │
│      │                │ Range           │
├──────┼────────────────┼─────────────────┤
│ 1000 │ 100000 +       │ 100000-165535   │
│      │ ((1000-1000) * │                 │
│      │ 65536)         │                 │
├──────┼────────────────┼─────────────────┤
│ 1001 │ 100000 +       │ 165536-231071   │
│      │ ((1001-1000) * │                 │
│      │ 65536)         │                 │
├──────┼────────────────┼─────────────────┤
│ 1002 │ 100000 +       │ 231072-296607   │
│      │ ((1002-1000) * │                 │
│      │ 65536)         │                 │
├──────┼────────────────┼─────────────────┤
│ 1100 │ 100000 +       │ 6653600-6719135 │
│      │ ((1100-1000) * │                 │
│      │ 65536)         │                 │
└──────┴────────────────┴─────────────────┘

🦋 Subordinate ID Space Planning 🦋

When you're planning out subordinate ID allocation, work out the maximum number of users the space can hold:

capacity = (SUB_GID_MAX - SUB_GID_MIN) / SUB_GID_COUNT

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

For high-density environments with lots of users and smaller allocations:

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)
WARNING: SECURITY RISK - MAY CAUSE RANGE OVERLAPS AND PRIVILEGE ESCALATION! 😭 This one is not playing around.

It's only effective when SUB_GID_DETERMINISTIC is set to yes.

Set it to yes (WRAP MODE) and the deterministic range calculation is allowed to wrap around using modulo arithmetic whenever a UID would overflow the configured subordinate ID space. Basically the subordinate ID space gets treated like a ring buffer. 🔄

WARNING: Range overlaps can lead to container escapes and privilege escalation. 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. User B's container can now access files from User A's containers. That's a whole security incident, bestie.

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. Safe queen behavior. 💅

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

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  │ Calculation    │ Subordinate UID │
│      │                │ Range           │
├──────┼────────────────┼─────────────────┤
│ 1000 │ 100000 +       │ 100000-165535   │
│      │ ((1000-1000) * │                 │
│      │ 65536)         │                 │
├──────┼────────────────┼─────────────────┤
│ 1001 │ 100000 +       │ 165536-231071   │
│      │ ((1001-1000) * │                 │
│      │ 65536)         │                 │
├──────┼────────────────┼─────────────────┤
│ 1002 │ 100000 +       │ 231072-296607   │
│      │ ((1002-1000) * │                 │
│      │ 65536)         │                 │
├──────┼────────────────┼─────────────────┤
│ 1100 │ 100000 +       │ 6653600-6719135 │
│      │ ((1100-1000) * │                 │
│      │ 65536)         │                 │
└──────┴────────────────┴─────────────────┘

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

⚠️ BESTIE. PAUSE. READ THIS TWICE. ⚠️ Range overlaps can literally lead to container escapes and privilege escalation. Like, not a cute lil oopsie — a whole security incident. Example time: with SUB_UID_MIN=100000, SUB_UID_MAX=200000, SUB_UID_COUNT=65536, User A (UID 1000) gets the range [100000, 165535] and User B (UID 1001) wraps around and overlaps with User A. So now User B's container can just… access files from User A's containers. 🙈 Absolute nightmare behaviour, no cap.

Use only in development, testing, or tightly constrained lab environments. That's it. That's the whole vibe. Don't bring this to prod. 💀

When set to no (which is the default), any arithmetic overflow or range exceeding SUB_UID_MAX is a hard error. It just stops. Which means you get a guarantee of non-overlapping, monotonic allocation. Chef's kiss. ✨

And the default value for UNSAFE_SUB_UID_DETERMINISTIC_WRAP is no. Remember that. 🫶

🗂️ FILES 🗂️

Here's where all the receipts live, bestie:

  • /etc/group — group account information 📋
  • /etc/gshadow — secure group account information 🔒
  • /etc/login.defs — shadow password suite configuration ⚙️
  • /etc/passwd — user account information 👤
  • /etc/shadow — secure user account information 🤫
  • /etc/subgid — per user subordinate group IDs 🧬
  • /etc/subuid — per user subordinate user IDs 🧬

👀 SEE ALSO 👀

The whole friend group, go say hi:

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

and that's the whole page, bestie!! 🎀 you officially know usermod better than 90% of the people who use it daily, periodt 💅

this lil masterpiece is from shadow-utils 4.20.0, dated 07/30/2026, and it lives at USERMOD(8) — go forth and modify users responsibly, mwah 🦋💖

📦 where this page comes from