How to Fix "Only Root Can Do That" in Proxmox VE (PAM vs PVE Realm Permissions Explained)

You SSH into your Proxmox VE box, type a command you've run a dozen times before, and instead of the usual output you get slapped with:

only root can do that

No stack trace, no hint about what actually went wrong — just five words that tell you almost nothing. If you just created a new user, or you're logged in over SSH as something other than root, this error has a very specific and very fixable cause. It's one of the most common things beginners hit in their first week with Proxmox, and it trips people up because the fix has nothing to do with passwords or typos.

What You Will Learn

By the end of this guide you'll understand exactly why Proxmox VE throws this error, how PAM and PVE realms are different (and why that distinction matters), and how to fix the problem the right way instead of just running everything as root forever. You'll also learn how to check what permissions a user actually has, and how to grant just enough access without handing out full admin rights.

What Is This Error?

only root can do that is Proxmox VE's blunt way of saying: the account you're currently using does not have permission to run this specific command. It shows up in two main places — the shell, when you run a qm, pct, or pvesh command over SSH, and occasionally in the web UI task log when a lower-privileged account tries something outside its role.

It's not a bug. Proxmox is doing exactly what it's supposed to do: refusing an action from an account that isn't authorized for it. The confusing part is that the message doesn't tell you which permission you're missing, or why — it just shuts the door.

Why Would You Use It?

You don't "use" this error on purpose, but understanding it matters because it's really your first real encounter with how Proxmox VE separates identity from privilege. Once you get past this error the right way, you'll understand a piece of Proxmox that trips up almost every new admin: the difference between a Linux system account and a Proxmox-managed account, and why root should not be your daily driver.

Running everything as root works, technically. But it means every mistyped command, every copy-pasted script from a forum post, and every compromised SSH key has full, unrestricted power over your entire virtualization host. Fixing this error properly — instead of just switching back to root — is the first step toward a Proxmox setup you can actually trust with production workloads, or just sleep better about in your homelab.

Prerequisites

Before you start, make sure you have:

• A working Proxmox VE 8.x or 9.x installation with web UI access on port 8006
• SSH or console access to the host as the root user, at least temporarily, to fix permissions
• The username of the account that's hitting the error (it might be you, or a service account you set up for automation)
• About fifteen minutes

You don't need any cluster, storage, or networking knowledge for this one — it's purely about users and permissions.

Step-by-Step Tutorial

Step 1: Confirm which account is actually running the command

Log into the console or SSH session where you're seeing the error and run:

whoami
id

whoami tells you your current Linux username. id shows your user ID, group ID, and any supplementary groups. If whoami returns anything other than root, that's very likely your answer already — most qm, pct, and low-level pvesh operations at the shell level require the actual Linux root account, not a Proxmox-realm user logged into a regular shell.

Step 2: Understand the two realms Proxmox VE uses

This is the part that confuses almost everyone, so it's worth slowing down here.

Proxmox VE authenticates users through realms, and there are two you'll deal with as a beginner:

Realm	What it actually is	Where it works
Linux PAM standard authentication (pam)	Real Linux system accounts, the same ones in /etc/passwd	Web UI login and SSH/console shell
Proxmox VE authentication server (pve)	Accounts that exist only inside Proxmox's own user database	Web UI and API only — they cannot SSH into the host or open a shell

Here's the part that catches people out: a pve-realm user, even one with full Administrator role assigned through the GUI, still can't SSH in and run qm start 100 from a shell — because that account doesn't exist as a Linux user at the operating system level. It only exists inside Proxmox's permission system, which the web UI and API check, but the shell doesn't.

So if you created a user like dave@pve through Datacenter → Permissions → Users, gave it full rights, and then tried to SSH in as dave and run privileged commands, you'll hit exactly this error — not because the permissions are wrong, but because that account was never meant to open a Linux shell in the first place.

Step 3: Check what realm the affected account actually belongs to

In the web UI, go to Datacenter → Permissions → Users. Look at the User name column — accounts are listed as username@realm. A pam suffix means it's a real Linux account; pve means it's Proxmox-only.

If you're troubleshooting from the shell, you can check whether a name exists as a real Linux user with:

getent passwd dave

If that returns nothing, dave is not a Linux system account — it's a pve-realm-only user, and that explains the error immediately if you were trying to SSH in as that user.

Step 4: Decide what you actually need — shell access or GUI access

Before fixing anything, figure out what the account is supposed to do:

• If it needs to SSH in and run qm/pct commands directly, it needs to be a real Linux user (PAM realm), and for most privileged commands, that means using sudo or being root — Proxmox's low-level CLI tools generally assume root.
• If it only needs to manage VMs, containers, backups, or storage through the web UI or API, a pve-realm account with the right role assigned is the correct — and safer — choice. It never needs shell access at all.

Most beginners actually want the second option and don't realize it. If you're only clicking around the web interface, you don't need SSH access for that account at all.

Step 5: Create a Linux (PAM) user, if shell access is genuinely needed

As root, create a real system account:

adduser dave

This creates a standard Linux user with a home directory and prompts you to set a password. This account can now log into the Proxmox web UI by selecting Linux PAM standard authentication as the realm, and it can also SSH into the host.

By default, a plain PAM user still isn't root, so privileged qm/pct commands will still fail for it at the shell. If this account genuinely needs to run administrative commands directly, add it to the sudo group:

usermod -aG sudo dave

Then the user can run sudo qm start 100 instead of needing to be logged in as root directly. This keeps an audit trail of who ran what, which plain root access doesn't give you.

Step 6: Or, assign proper permissions if this is a web UI / API access case

If the account only needs Proxmox-level access, skip PAM entirely and use Proxmox's own permission system:

1. Go to Datacenter → Permissions → Users and create (or confirm) the user under the pve realm.
2. Go to Datacenter → Permissions and click Add → User Permission.
3. Pick the Path this permission applies to — for example /vms/100 for a single VM, or / for the whole datacenter.
4. Choose a Role, such as PVEVMAdmin for VM management or PVEAuditor for read-only access.
5. Save, then log out and back in as that user to confirm the new permission took effect.

This account will never hit "only root can do that" from the web UI once the role and path are correct, and it never needs a Linux password or shell access at all.

Step 7: Verify the fix

For a PAM/sudo user, SSH back in and try the same command with sudo:

sudo qm list

For a pve-realm user, log into the web UI with that account and confirm the relevant menu items and buttons are now visible and clickable instead of greyed out.

Commands Explained

Command	What it does
whoami	Prints the username of the account running the current shell session.
id	Shows the current user's UID, GID, and group memberships — useful for confirming sudo group membership.
getent passwd <name>	Looks up a username in the system's user database. No result means it's not a real Linux account.
adduser <name>	Creates a new Linux system user with a home directory, interactively setting a password.
usermod -aG sudo <name>	Adds an existing user to the sudo group, without removing them from any groups they're already in (the -a flag means "append").
sudo <command>	Runs a single command with root privileges, prompting for the current user's own password rather than root's.

Common Errors

A few variations show up alongside or instead of the exact message above:

• "Permission denied" in the web UI task log — usually a pve-realm user missing a role on the specific path they're trying to act on. Check Datacenter → Permissions and confirm the path matches (a role on /vms/100 doesn't grant access to /vms/101).
• "user 'dave@pve' has no permission to access '/'" — the permission exists but was assigned at too narrow a path. Assigning it at / or the correct parent path fixes it, though be deliberate about how broad you make it.
• sudo: dave is not in the sudoers file — this means the usermod -aG sudo step from earlier either wasn't run, or the user needs to log out and back in (group membership changes don't apply to an already-open session).

Troubleshooting

If you added a user to the sudo group and sudo still doesn't work, the most common cause is an existing SSH session that predates the group change. Log out completely and reconnect — group membership is read fresh at login, not mid-session.

If a pve-realm account still can't see or edit something after you've assigned a role, double-check the Path field carefully. It's easy to assign a permission on /vms when you meant /, or on a specific VM ID when the user needs access to a whole pool instead. Permissions in Proxmox are not inherited upward — a role on a child path doesn't grant anything on its parent.

If you're not sure what role to pick, Datacenter → Permissions → Roles lists every built-in role along with the exact privileges bundled into it. It's worth reading through once — PVEVMAdmin, PVEVMUser, and PVEAuditor cover most day-to-day cases, and their names are more descriptive than they might seem at first glance.

Best Practices

Once you've fixed the immediate error, a few habits will save you from repeating it:

• Stop logging in as root for daily work. Create a personal PAM account with sudo access instead — it's not meaningfully slower, and it means your commands are attributable to you specifically.
• Use pve-realm accounts for anyone who only needs the web UI or API, especially teammates who shouldn't have shell access to the host at all.
• Scope permissions to specific paths rather than granting / access by default. A backup automation account, for instance, rarely needs anything beyond PVEDatastoreAdmin on the relevant storage.
• Disable direct root SSH login once you have a working sudo account, by setting PermitRootLogin no in /etc/ssh/sshd_config and restarting the SSH service. Test your sudo access thoroughly first, though — don't lock yourself out.

Frequently Asked Questions

Can a pve-realm user ever get shell access?

Not directly. A pve-realm account exists only inside Proxmox's own authentication database, not as a Linux system account, so there's nothing for SSH to log into. If shell access is required, you need a real Linux (PAM) user instead.

Is it safe to just keep using root over SSH?

It works, but every command runs with unrestricted power over the host, and there's no per-user audit trail. For a solo homelab it's a common shortcut; for anything shared or production-facing, a sudo-enabled account is worth the five extra minutes of setup.

Why does the web UI let me click a button that then fails with this error?

The web UI doesn't always pre-check every permission before showing a control. Some actions are only validated when you actually submit them, so a missing permission can surface as a failed task rather than a greyed-out button.

Does adding a user to the sudo group give them full root access?

Effectively, yes — a sudo user can run any command as root after authenticating with their own password. If you want narrower access, Proxmox's own role-based permissions on the pve realm are a better fit than sudo.

Conclusion

"Only root can do that" isn't Proxmox being cryptic for no reason — it's the system correctly refusing an action from an account that was never granted it, usually because of a mismatch between the PAM and pve realms. Once you know which realm an account belongs to and what it's actually trying to do, the fix is usually a two-minute job: either create a proper Linux user with sudo, or assign the right role on the right path inside Proxmox's own permission system. Either way, you come out the other side with a setup that's a little more deliberate than "just SSH in as root and hope."