How to Add a User in Linux: Groups & Permissions 2026

Your new VPS arrives with exactly one account, root, and working from it every day is how a single typo turns into an outage. So the first real admin job on any server is knowing how to add a user in Linux and giving that account only the access it needs.

Quick Answer: On Ubuntu or Debian, run sudo adduser deploy, answer the password prompt, then grant admin rights with sudo usermod -aG sudo deploy. On AlmaLinux, Rocky or RHEL, run sudo useradd -m deploy, set a password with sudo passwd deploy, and use the wheel group instead of sudo. Log in as the new user and confirm with id before you touch root access.

Last verified: September 2026, against Ubuntu 24.04 LTS and 26.04 LTS (adduser 3.x) and the current useradd and usermod man pages.

Our team resolves 20 to 30 client server issues every day, and a steady share of them trace back to an account created in a hurry: no home directory, the wrong group, an SSH key the server refuses to read. This guide is the checklist we wish those customers had used, written so you can do it yourself in about 10 minutes.

Why You Shouldn't Run Your Server as Root

Root can do anything, including wipe the system with one mistyped command, and every script it starts inherits that power.

A Linux user account is an identity with its own UID, home directory, password and group memberships, stored across /etc/passwd, /etc/shadow and /etc/group. On Ubuntu and RHEL-family servers, regular accounts start at UID 1000 and system accounts sit below it. One account per person or app means a leaked password or buggy script only reaches what that single UID can touch.

Working through sudo also gives you an audit trail. Every elevated command lands in /var/log/auth.log on Ubuntu (or the journal on RHEL-family systems), so when something breaks at 2 a.m. you can see who ran what. If root's password is still the one from your welcome email, change the root password safely before going further.

Do I really need a separate user if I'm the only admin?

Yes, and being the only admin is exactly why. According to the SSH auth logs Hostaccent's engineers review on newly provisioned client servers, root is almost always the first username automated bots try, often within minutes of an IP going live. Once you log in as your own user, you can switch off root SSH login entirely, and bots are left guessing a username as well as a password. Pair that with Fail2ban to stop brute-force attempts and most of the noise disappears.

How to Add a User in Linux, Step by Step

The whole job is five steps: create the account, set a password, grant admin rights only if needed, copy your SSH key, then verify. You need root or an existing sudo account and an open SSH session.

Step 1: Create the account

On Ubuntu and Debian, adduser walks you through everything:

bashCopy
sudo adduser deploy

It creates a matching deploy group, builds /home/deploy, copies the starter files from /etc/skel, and asks for a password twice. The "Full Name" and "Room Number" questions are optional, so press Enter to skip them.

To skip the prompts in a script, pass --comment "Deploy User". That flag replaced the older --gecos, which the Debian adduser manual marks as deprecated, so a tutorial still using --gecos is showing its age. As of September 2026, both Ubuntu 24.04 and Ubuntu 26.04 LTS (supported until April 2031) ship adduser 3.x with the new flag.

On AlmaLinux, Rocky Linux and RHEL, adduser is only a link to useradd, so be explicit:

bashCopy
sudo useradd -m -s /bin/bash -c "Deploy User" deploy

Step 2: Set a password (useradd only)

bashCopy
sudo passwd deploy

Until you do this, the account is locked: its line in /etc/shadow holds ! instead of a password hash. SSH key logins can still work in that state, which surprises plenty of people.

Step 3: Grant sudo rights, only if this user needs them

bashCopy
sudo usermod -aG sudo deploy     # Ubuntu / Debian
sudo usermod -aG wheel deploy    # AlmaLinux / Rocky / RHEL

For a narrower grant, create a drop-in with sudo visudo -f /etc/sudoers.d/deploy rather than editing the main sudoers file. visudo checks syntax before saving, and that check is what stands between a small typo and a server where sudo stops working.

Step 4: Copy your SSH key the right way

bashCopy
sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo cp /root/.ssh/authorized_keys /home/deploy/.ssh/
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Pro Tip: Skip the chown and the copied key stays owned by root. OpenSSH's StrictModes check then ignores it, and the new user gets "Permission denied (publickey)" even though the key itself is fine. Keep your root session open and test the new login from a second terminal before closing anything, especially if you also plan to change the SSH port.

Step 5: Run the 60-Second Account Audit

We run the same four commands after every account we create for a client:

bashCopy
id deploy                 # UID, primary group, extra groups
sudo -l -U deploy         # what sudo will allow
sudo passwd -S deploy     # P = password set, L = locked
ls -ld /home/deploy       # owner and permissions

The 60-Second Account Audit checks four things in about 60 seconds: that the user exists with the right groups (id), that sudo grants only what you meant (sudo -l -U), that the password status shows P rather than L (passwd -S), and that the home directory belongs to the user with 750 or 700 permissions (ls -ld). Any surprise here is cheaper to fix today than next month.

◆ Professional help available

Still working through this server issue?

Send the symptoms, error output, and what you have already tried. We can work with Hostaccent services or infrastructure hosted with another provider.

Request server help→How server support works↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

adduser vs useradd: The Difference That Actually Matters

adduser is a friendly Perl script on Debian and Ubuntu that asks questions and then calls useradd for you. useradd is the low-level tool found on every distribution, and it does only what its flags tell it.

| Behaviour | adduser (Debian/Ubuntu) | useradd (all distros) | |---|---|---| | Asks questions interactively | Yes | No, silent on success | | Creates the home directory | Yes, copies /etc/skel | Only with -m on Debian/Ubuntu; by default on RHEL family | | Sets a password | Prompts for one | No, run passwd afterwards | | Default login shell | /bin/bash via adduser.conf | /bin/sh on Ubuntu unless you pass -s | | Reads defaults from | /etc/adduser.conf | /etc/default/useradd and /etc/login.defs | | Best used for | Typing by hand | Scripts, cloud-init, Ansible |

Most guides tell beginners to always prefer adduser. Our rule is simpler: adduser at the keyboard, useradd in anything automated, because it behaves the same on every distribution and never sits waiting for input. That's the real adduser vs useradd difference once you manage more than one server.

The classic trap is plain useradd deploy on Ubuntu. On Ubuntu and Debian, useradd without -m records /home/deploy in /etc/passwd but never creates the folder, so the first login lands in / with a "Could not chdir to home directory" warning. The useradd manual page documents -m, and typing it takes about 2 seconds.

So if you want to create a user with a home directory using useradd, treat -m as mandatory. Already made the mistake? Create the folder, copy /etc/skel/. into it, then run sudo chown -R deploy:deploy /home/deploy and sudo chmod 750 /home/deploy.

Add a User to a Group in Linux and Set Permissions Right

Use sudo usermod -aG groupname username, and never leave out the -a.

Insider Insight: usermod -G without -a replaces the user's entire list of supplementary groups. Run usermod -G webteam deploy by mistake and deploy quietly drops out of sudo, which on a server with root login disabled can lock you out of admin access completely.

To create a group for a team and add someone to it:

bashCopy
sudo groupadd webteam
sudo usermod -aG webteam deploy
sudo gpasswd -d deploy webteam   # removes the user again

New memberships only apply to fresh logins, so log out and back in (or run newgrp webteam) before testing. The full flag list lives in the usermod manual page.

Home directory permissions

Recent Ubuntu releases create home directories with 750 permissions, so users on the same server can't browse each other's files. Servers upgraded from much older releases may still carry 755 homes. Check with ls -ld /home/* and tighten any world-readable ones with sudo chmod 750 /home/username.

A shared website folder that never needs 777

When a site user deploys code and the web server only reads it, set ownership like this:

bashCopy
sudo chown -R deploy:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 2750 {} +
sudo find /var/www/example.com -type f -exec chmod 640 {} +

The leading 2 in 2750 is the setgid bit: files created inside the folder inherit the www-data group automatically, so permissions stay correct after every deploy. Only the upload or cache folders your application writes to need 2770 and 660. On RHEL-family servers the web group is usually apache or nginx, and if PHP-FPM runs each site as its own user, use that user as the owner.

Across the 4,000+ site migrations Hostaccent has handled since 2016, the permission fault our engineers fix most often after a move is files left owned by root, usually because they were copied with sudo and never handed back. The site loads, then uploads and plugin updates fail with "permission denied". One chown -R to the site's own user is the real fix, while chmod 777 only hides the problem. If that user also connects by FTP, a wrong shell or home directory is a common cause of FTP 530 login authentication failures.

How to Delete a User in Linux Without Leaving a Mess

On Ubuntu and Debian, run sudo deluser --remove-home username; on RHEL-family systems, sudo userdel -r username. Do it only after you've locked the account, stopped its processes and saved anything worth keeping.

1. Lock before you delete

bashCopy
sudo usermod -L deploy     # locks the password
sudo chage -E 0 deploy     # expires the account, blocking SSH keys too

Locking the password alone isn't enough, because SSH key logins can still succeed. Expiring the account stops both. For staff who are leaving, we keep accounts locked for 7 days before deleting, in case something quietly depends on them.

2. Check what the user is running

bashCopy
ps -u deploy
sudo crontab -l -u deploy
sudo pkill -u deploy

In our experience, a forgotten cron job or background worker is what breaks after a deletion, and it fails silently.

3. Back up, then remove

bashCopy
sudo mkdir -p /root/user-backups
sudo deluser --remove-home --backup-to /root/user-backups deploy   # Debian/Ubuntu
sudo userdel -r deploy                                             # RHEL family

4. Find the files left behind

bashCopy
sudo find / -xdev -nouser 2>/dev/null

Deleting a user removes their home directory and mail spool, but not files they own elsewhere, such as uploads under /var/www or logs in /opt. Those files stay behind owned by a bare number, and the next account created with the same UID, often 1001 on a small server, silently inherits them. Run the search above and reassign or remove anything it finds in the same maintenance window.

Pro Tip: Taking away admin rights rarely needs a deletion at all. sudo gpasswd -d deploy sudo removes sudo access in one command and keeps the account's files and history intact.

Your Next Step: A Server Ready for Its First User

• Create a named account first and keep root for emergencies.
• Use adduser by hand and useradd -m in scripts.
• Add groups with usermod -aG, never -G alone.
• Lock and expire before you delete, then hunt down orphaned files.

Now that you know how to add a user in Linux without the permission mess, the remaining question is where that account lives. You could set all of this up on any bare box, or start on a server built for it: full root access, free 30 Gbps DDoS protection, and 24/7 help from Hostaccent's own in-house engineers (hosting since 2016, UK-incorporated 2018) when a login or permission goes sideways. The Basic plan at $7.99/mo renews at the same $7.99/mo and includes a 30-day money-back guarantee. One honest caveat: control panels like cPanel or Plesk are licensed separately, so budget for one if you need it. When you're ready, start on the Basic plan.

Frequently Asked Questions

How to add a user in Linux with a custom home directory?

Pass the path explicitly. With useradd, run sudo useradd -m -d /srv/app -s /bin/bash app, where -d sets the location and -m creates it. With adduser on Ubuntu or Debian, use sudo adduser --home /srv/app app. Service accounts that never log in are better created as system users, for example sudo useradd -r -s /usr/sbin/nologin app, which picks a UID below 1000 and gives the account no usable shell.

How do I list all users on a Linux server?

Run getent passwd to print every account the system knows about, including any from LDAP or other directories. To see only real login accounts, filter by UID: getent passwd | awk -F: '$3 >= 1000 && $3 < 65534 {print $1}'. Most of the 30-odd entries you'll see without that filter are system accounts such as www-data or sshd, which services run as and people never log in with.

How do I give an existing user sudo access on Ubuntu?

Run sudo usermod -aG sudo username, then have the user log out and back in, because group changes only apply to new sessions. Confirm it worked with sudo -l -U username, which should list "(ALL : ALL) ALL". On AlmaLinux, Rocky or RHEL, the admin group is wheel instead. To grant only a few commands, write a drop-in file with visudo -f /etc/sudoers.d/username rather than handing over full admin rights.

Can I rename a Linux user without breaking things?

Yes, with care. Log the user out first, then run sudo usermod -l newname oldname to change the login name and sudo usermod -d /home/newname -m newname to move the home directory. Rename the matching group with sudo groupmod -n newname oldname. The UID stays the same, so file ownership survives, but check crontabs, sudoers drop-ins and any config file that references the old name as text.

Why can't my new user log in over SSH?

Four causes cover nearly every case we see. The password was never set (passwd -S shows L), the authorized_keys file is owned by root or has loose permissions, the shell is /usr/sbin/nologin, or an AllowUsers line in the SSH config leaves the new name out. The sshd_config manual explains AllowUsers and StrictModes, and sudo journalctl -u ssh (sshd on RHEL) shows the exact refusal reason.

Is a Linux user the same as a MySQL user?

No. MySQL and MariaDB keep their own user tables, completely separate from /etc/passwd, so adding a Linux account grants no database access, and deleting one leaves database logins untouched. The one overlap is socket authentication, where the MariaDB root account can trust the Linux root user on the same server. If that link breaks and you're locked out, this guide to reset the MySQL root password walks through recovering access.