adduser Command in Linux: Syntax, Options & Practical Examples (Ubuntu/Debian)

Create a normal login user the way most admins do on Ubuntu or Debian: run adduser with a username and answer the prompts for password and full name.

Run the command:

sudo adduser alice

Sample output (interactive — password and GECOS values will differ on your host):

info: Adding user `alice' ...
info: Selecting UID/GID from range 1000 to 59999 ...
info: Adding new group `alice' (1001) ...
info: Adding new user `alice' (1001) with group `alice (1001)' ...
info: Creating home directory `/home/alice' ...
info: Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for alice
Enter the new value, or press ENTER for the default
	Full Name []: Alice Example
	Room Number []:
	Work Phone []:
	Home Phone []:
	Other []:
Is the information correct? [Y/n] Y
info: Adding new user `alice' ...

Check that the account was written to the user database — getent passwd prints the line from /etc/passwd:

getent passwd alice

Sample output:

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

The seven fields are username:password_placeholder:UID:GID:GECOS:home:shell. The x means the password hash is stored in /etc/shadow, not in this file.

Create an account that skips password prompts — useful when the user will log in with SSH keys, or when a script needs a local username and home directory.

Run the command:

sudo adduser --disabled-password --comment "Deploy Bot" deploy

Sample output:

info: Adding user `deploy' ...
info: Selecting UID/GID from range 1000 to 59999 ...
info: Adding new group `deploy' (1003) ...
info: Adding new user `deploy' (1003) with group `deploy (1003)' ...
info: Creating home directory `/home/deploy' ...
info: Copying files from `/etc/skel' ...

Confirm the account exists and see how the password field is locked — id shows UID and groups; grep on /etc/shadow shows the password state:

id deploy
sudo grep deploy /etc/shadow

Sample output:

uid=1003(deploy) gid=1003(deploy) groups=1003(deploy)
deploy:!:20362:0:99999:7:::

The ! in /etc/shadow means password login is disabled until you run passwd deploy or set up SSH keys in /home/deploy.

Add an existing user to an existing group without creating a new account. Both names must already be on the system.

Run the command (adduser with two arguments — user, then group):

sudo adduser alice devteam

Sample output:

info: Adding user `alice' to group `devteam' ...

Check that devteam appears in Alice's group list but is not her primary group:

id alice
getent group devteam

id shows all groups; the primary GID stays alice. getent group shows alice in the member list for devteam.

Sample output:

uid=1001(alice) gid=1001(alice) groups=1001(alice),1006(devteam)
devteam:x:1006:alice

To change someone's primary group instead, use usermod.

Create a user whose home directory is not under /home and whose login shell is not the system default — both paths are set at creation time.

Run the command:

sudo adduser --home /opt/myapp --shell /bin/bash --comment "App Owner" appowner

Sample output:

info: Adding user `appowner' ...
info: Adding new user `appowner' (1004) with group `appowner (1004)' ...
info: Creating home directory `/opt/myapp' ...
info: Copying files from `/etc/skel' ...

Verify the home path and shell were saved correctly, and that the home directory exists on disk:

getent passwd appowner
ls -ld /opt/myapp

getent passwd confirms the home and shell in /etc/passwd. ls -ld confirms the directory was created and owned by the new user.

Sample output:

appowner:x:1004:1004:App Owner,,,:/opt/myapp:/bin/bash
drwxr-xr-x 3 appowner appowner 4096 Jul  1 12:00 /opt/myapp

The shell path must be listed in /etc/shells or adduser rejects it.

Sometimes you only need a group record — for example before adduser --ingroup, or before adding members later.

Run the command:

sudo addgroup devteam

Sample output:

Adding group `devteam' (1006) ...
Done.

Confirm the group exists in /etc/group:

getent group devteam

Sample output:

devteam:x:1006:

The empty field after the last colon means no members yet — that is normal for a new group.

A frequent mistake is passing --ingroup with a group name that has not been created yet. This shows the error and how to fix it.

Try to create a user in a group that does not exist:

sudo adduser --ingroup missinggrp --disabled-password bob

Sample output:

adduser: The group `missinggrp' does not exist.

Create the group, then run the same user command again:

sudo addgroup missinggrp
sudo adduser --ingroup missinggrp --disabled-password bob

The failed first run does not leave a half-created user — safe to fix the group and retry.

Service accounts for daemons use a low system UID, no home directory, and a shell that blocks interactive login.

Run the command:

sudo adduser --system --no-create-home --shell /usr/sbin/nologin --comment "Service Account" svcapp

Sample output:

info: Selecting UID from range 100 to 999 ...
info: Adding system user `svcapp' (122) ...
info: Adding new user `svcapp' (UID 122) with group `nogroup' ...
info: Not creating `/nonexistent'.

Check the passwd line — note the low UID, nologin shell, and placeholder home:

getent passwd svcapp

Sample output:

svcapp:x:122:65534:Service Account,,,:/nonexistent:/usr/sbin/nologin

UID 122 is in the system range. GID 65534 is often nogroup on Debian/Ubuntu. Use --system --group when the service needs a dedicated primary group with the same name.

For labs, load tests, or onboarding many accounts, wrap adduser in a loop. Two common patterns:

With a shared group — one group, many users, fixed UID range (good when every account must share the same primary group):

#!/bin/bash
# bulk-users-with-group.sh — create COUNT users in shared group batchgrp
set -euo pipefail

COUNT=5          # raise to 100 (or more) for larger batches
BASE_UID=3000
GROUP=batchgrp

sudo addgroup --quiet "$GROUP" 2>/dev/null || true

for i in $(seq -w 1 "$COUNT"); do
  user="batchuser${i}"
  uid=$((BASE_UID + 10#${i}))
  sudo adduser \
    --disabled-password \
    --quiet \
    --ingroup "$GROUP" \
    --uid "$uid" \
    --comment "Batch user ${i}" \
    "$user"
done

Without a shared group — each user gets the default private group adduser creates automatically (simpler, no addgroup step):

#!/bin/bash
# bulk-users-default-group.sh
set -euo pipefail

COUNT=5

for i in $(seq -w 1 "$COUNT"); do
  user="solouser${i}"
  sudo adduser \
    --disabled-password \
    --quiet \
    --comment "Solo user ${i}" \
    "$user"
done

Run the shared-group version and watch the first user being created (--quiet hides most lines; drop it while testing):

chmod +x bulk-users-with-group.sh
sudo ./bulk-users-with-group.sh

Sample output (first user only — later iterations look the same):

info: Adding user `batchuser01' ...
info: Adding new user `batchuser01' (3001) with group `batchgrp (1005)' ...
info: Creating home directory `/home/batchuser01' ...
info: Copying files from `/etc/skel' ...

Confirm a user in the middle of the range and count how many accounts were created:

id batchuser03
getent passwd batchuser03
getent passwd | grep -c '^batchuser'

Sample output:

uid=3003(batchuser03) gid=1005(batchgrp) groups=1005(batchgrp)
batchuser03:x:3003:1005:Batch user 03,,,:/home/batchuser03:/bin/bash
5

Use --uid and --ingroup when IDs must match across hosts. Omit them when the system can pick UID/GID automatically. Use --quiet in loops to hide repetitive info: lines.

Encrypted home directories need the ecryptfs-utils package and ecryptfs-setup-private on PATH. Without it, adduser stops before creating the user.

Run the command:

sudo adduser --encrypt-home --disabled-password --comment "" encuser

Sample output when the helper is missing:

fatal: Could not find program named `ecryptfs-setup-private' in $PATH.

Install the dependency, then retry:

sudo apt install ecryptfs-utils
sudo adduser --encrypt-home --disabled-password --comment "" encuser

Verify with ls -la /home/encuser — an encrypted private directory is created when the stack is available. Remove test users with sudo deluser --remove-home encuser.

When adduser fails and the message is unclear, --debug shows each low-level command it runs behind the scenes.

Run the command:

sudo adduser --debug --disabled-password --comment "" dbguser

Sample output:

debug: new_uid 1007 selected
debug: /sbin/groupadd -g 1007 dbguser
debug: /sbin/useradd -d /home/dbguser -g 1007 -s /bin/bash -u 1007 dbguser
debug: /bin/chfn -f  dbguser

Each debug: line is a real subprocess. If something fails, the error usually appears right after the line for the command that broke — use the Troubleshooting table to match symptoms to fixes.