In Linux, the Authentication token manipulation error appears when the system can't save a new password. It occurs while running the passwd command and is tied to a problem writing authentication data: incorrect permissions on /etc/shadow, a read-only file system, lack of free disk space, or a misconfiguration in PAM. You can usually track down the cause within a few minutes by checking four things in sequence, which we'll walk through below.

What the Authentication token manipulation error means

passwd relies on PAM (Pluggable Authentication Modules) to change a password. In a standard Linux configuration, local password data is stored in /etc/shadow, while the pam_unix module works with /etc/passwd and /etc/shadow to verify and update credentials.

The message

passwd: Authentication token manipulation error
passwd: password unchanged

means the password change operation didn't complete successfully.

Important clarification: this isn't necessarily a failure to verify the old password. The user may have entered the current password correctly, and the system accepts the new one, but then fails to write the result to /etc/shadow.

This happens not only during a regular passwd run, but also when a password is force-changed due to expiration during SSH login or through other PAM-aware programs. The underlying PAM_AUTHTOK_ERR code in Linux-PAM corresponds to this exact Authentication token manipulation error.

Cause 1 — incorrect permissions on /etc/shadow

The first thing worth checking is the file's owner and permissions:

ls -l /etc/shadow

On Debian and Ubuntu, the standard setup looks like this:

-rw-r----- 1 root shadow ... /etc/shadow

In other words, the owner is root, the group is shadow, and the permissions are 640. Debian explicitly recommends keeping /etc/shadow owned by root:shadow with mode 0640; Ubuntu follows the same scheme.

If these values have been altered, on Debian/Ubuntu you can restore them with:

sudo chown root:shadow /etc/shadow
sudo chmod 640 /etc/shadow

After that, try again:

sudo passwd USERNAME

Don't apply chmod 640 to /etc/shadow blindly on just any Linux distribution without checking first. RHEL-based systems may use a different protection scheme for this file. So first identify the distribution:

cat /etc/os-release

and compare the current permissions against that system's defaults.

It's also worth verifying the integrity of the account files:

sudo pwck

pwck checks the structure of /etc/passwd and /etc/shadow, confirms that user entries match up, and validates field correctness.

Cause 2 — the root partition is mounted read-only

Even if the permissions on /etc/shadow are correct, writing to it is impossible if the file system containing /etc is mounted read-only.

You can check the mount mode with:

findmnt /

or:

mount | grep ' on / '

If ro appears among the options, the root partition is running in read-only mode. In some cases, you can temporarily remount it as read-write:

sudo mount -o remount,rw /

Then verify:

findmnt /

and try again:

sudo passwd USERNAME

If the remount fails, or the system keeps flipping the file system back to read-only, don't just keep repeating the command. The root cause likely lies in a file system error or an underlying disk problem. This is where it makes sense to boot into recovery/rescue mode and run a file system check.

This is especially relevant for virtual servers: if SSH has stopped responding or the system is behaving unpredictably, it helps to have an alternative way to reach the server through the control panel — for example, a web console or VNC, if that feature is included in your plan and control panel.

Cause 3 — the disk has run out of space

Check available space:

df -h

Pay attention to the line for /:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G   20G     0 100% /

When a partition is full, Linux may fail to properly create a temporary file or write a change to a system file. In that case, changing the password won't work even if the password itself is correct and there are no permission issues on /etc/shadow.

If the partition is full, start by locating the large directories:

sudo du -xhd1 / | sort -h

Common space hogs include:

  • /var/log — system logs;

  • /var/cache — package and application caches;

  • Docker images and containers;

  • old backups;

  • temporary files;

  • large application files.

For systemd journal logs, you can check their size with:

journalctl --disk-usage

Don't delete system files at random. The key first step is identifying exactly what's consuming disk space, freeing up a bit of room, and then retrying the password change. If a virtual server's disk keeps filling up to 100%, the issue goes beyond passwd. Check the disk size, logs, backups, and your data retention settings. A VPS with more disk space is one way to address this recurring problem.

Cause 4 — incorrect PAM configuration

If the permissions on /etc/shadow, the file system, and free space all check out, the next place to look is PAM. On Debian and Ubuntu, the global authentication rules live in:

/etc/pam.d/

The password-change rules specifically are in:

/etc/pam.d/common-password

You can review the configuration here:

sudo cat /etc/pam.d/common-password

On Debian systems, the standard PAM profiles are managed with:

sudo pam-auth-update

This utility manages PAM profiles, while the shared configuration files live in /etc/pam.d/common-*

Before making any manual changes to the configuration, always back it up first:

sudo cp /etc/pam.d/common-password /etc/pam.d/common-password.bak

After that, review the most recent changes and which PAM modules are currently loaded.

Don't just copy a line from some random forum post and overwrite the entire common-password file. A mistake in PAM can not only break the ability to change a password, but also cause problems logging in altogether.

On RHEL, CentOS, Rocky Linux, and AlmaLinux, the PAM structure is different. These systems use different configuration setups, so common-password instructions can't be applied directly. So first identify the distribution:

cat /etc/os-release

If the PAM configuration was recently changed, restore the last working version of the file from a backup, or rebuild the configuration using your distribution's own tools.

How to quickly figure out which cause applies to you

Diagnose the problem from simplest to most complex:

  1. Check /etc/shadow. Run ls -l /etc/shadow. On Debian/Ubuntu, you should see root:shadow and typically 640.

  2. Check free space. Run df -h. If / is at 100%, free up space first.

  3. Check the mount mode. Run findmnt /. If the file system is ro, try sudo mount -o remount,rw /

  4. Check account integrity with sudo pwck

  5. Check PAM if the previous steps didn't help. On Debian/Ubuntu, review /etc/pam.d/common-password

  6. After fixing the issue, retry the password change with sudo passwd USERNAME

Following this order helps you avoid unnecessarily touching the PAM configuration and system files.

If nothing works and SSH access is already lost

The situation gets trickier if the password can't be changed and SSH access is already gone. This happens when a user is locked out, or when the system demands a password change due to expiration, but the operation itself fails.

At this point you need an alternative way to reach the server:

  • web console;

  • VNC/console;

  • serial console;

  • rescue/recovery environment;

  • virtual machine console provided by the VPS provider.

Through one of these channels, you can log directly into the system and check /etc/shadow, the file system state, free space, and PAM without depending on a regular SSH connection. For a virtual server, this is one of the reasons to choose infrastructure that includes a backup administration method ahead of time. Our virtual server's control panel includes console access, which is especially useful exactly in situations where SSH has stopped working.

Conclusion

Authentication token manipulation error isn't some obscure standalone password bug — it's a signal that the credential-update operation failed to complete properly. In practice, the fastest approach is to work through the chain: /etc/shadow permissions, free disk space, mount mode, PAM.

Start with the simple, safe checks, then move on to the file system and authentication configuration. If SSH is already unreachable, backup access through a VPS console or another out-of-band channel lets you continue diagnosing directly on the server.

For servers where quick access recovery matters, it pays to have a backup administration method and sufficient disk space ready in advance. A VPS with console access and an adequate storage allocation reduces the risk of getting completely locked out of your server during incidents like this.