How to Fix “passwd: Authentication token manipulation error” in Linux

In Linux, the passwd command is used to set or change user account passwords, while using this command sometimes users may encountered the error: “passwd: Authentication token manipulation error” as shown in below example.

Recently I was logging in to my CentOS server using my username “tecmint“. Once I am logged in I am trying to change my password using passwd utility, but a second after I am getting the following error messages.

# su - tecmint
$ passwd tecmint
Changing password for user tecmint
Changing password for tecmint

(current) UNIX password: 
passwd: Authentication token manipulation error 

In this article, we will explain different ways of fixing “passwd: Authentication token manipulation error” in Linux systems.

1. Reboot System

The first basic solution is to reboot your system. I can’t really tell why this worked, but it did worked for me on my CentOS 7.

$ sudo reboot 

If this fails, try out the next solutions.

2. Set Correct PAM Module Settings

Another possible cause of the “passwd: Authentication token manipulation error” is wrong PAM (Pluggable Authentication Module) settings. This makes the module unable to obtain the new authentication token entered.

The various settings for PAM are found in /etc/pam.d/.

$ ls -l /etc/pam.d/

-rw-r--r-- 1 root root 142 Mar 23  2017 abrt-cli-root
-rw-r--r-- 1 root root 272 Mar 22  2017 atd
-rw-r--r-- 1 root root 192 Jan 26 07:41 chfn
-rw-r--r-- 1 root root 192 Jan 26 07:41 chsh
-rw-r--r-- 1 root root 232 Mar 22  2017 config-util
-rw-r--r-- 1 root root 293 Aug 23  2016 crond
-rw-r--r-- 1 root root 115 Nov 11  2010 eject
lrwxrwxrwx 1 root root  19 Apr 12  2012 fingerprint-auth -> fingerprint-auth-ac
-rw-r--r-- 1 root root 659 Apr 10  2012 fingerprint-auth-ac
-rw-r--r-- 1 root root 147 Oct  5  2009 halt
-rw-r--r-- 1 root root 728 Jan 26 07:41 login
-rw-r--r-- 1 root root 172 Nov 18  2016 newrole
-rw-r--r-- 1 root root 154 Mar 22  2017 other
-rw-r--r-- 1 root root 146 Nov 23  2015 passwd
lrwxrwxrwx 1 root root  16 Apr 12  2012 password-auth -> password-auth-ac
-rw-r--r-- 1 root root 896 Apr 10  2012 password-auth-ac

For instance a mis-configured /etc/pam.d/common-password file can result into this error, running the pam-auth-update command with root privileges can fix the issue.

$ sudo pam-auth-update

3. Remount Root Partition

You might also see this error if the / partition is mounted as read only, which means no file can be modified thus a user’s password can’t be set or changed. To fix this error, you need to mount the root partition as as read/write as shown.

$ sudo mount -o remount,rw /

4. Set Correct Permissions on Shadow File

Wrong permissions on the /etc/shadow file, which stores actual passwords for user accounts in encrypted format can also cause this error. To check the permissions on this file, use the following command.

$ ls -l  /etc/shadow

To set the correct permissions on it, use the chmod command as follows.

$ sudo chmod 0640 /etc/shadow

5. Repair and Fix Filesystem Errors

Minor storage drive or filesystem errors can also cause the error in question. You can use Linux disk scanning tools such as fsck to fix such errors.

6. Free Up Disk Space

Furthermore, if your disk is full, then you can not modify any file on the disk especially when file’s size is meant to increase. This can also cause the above error. In this case, read our following articles to clean up disk space can help solve this error.

  1. Agedu – A Useful Tool for Tracking Down Wasted Disk Space in Linux
  2. BleachBit – A Free Disk Space Cleaner and Privacy Guard for Linux Systems
  3. How to Find and Remove Duplicate/Unwanted Files in Linux Using ‘FSlint’ Tool

You will also find these articles relating to managing user passwords in Linux.

  1. How to Reset Forgotten Root Password in RHEL/CentOS and Fedora
  2. How to Force User to Change Password at Next Login in Linux
  3. How to Run ‘sudo’ Command Without Entering a Password in Linux

That’s it for now! If you know any other solution to fix “passwd: Authentication token manipulation error”, let us know via the feedback form below. We will be grateful for your contribution.

Hey TecMint readers,

Exciting news! Every month, our top blog commenters will have the chance to win fantastic rewards, like free Linux eBooks such as RHCE, RHCSA, LFCS, Learn Linux, and Awk, each worth $20!

Learn more about the contest and stand a chance to win by sharing your thoughts below!

Aaron Kili
Aaron Kili is a Linux and F.O.S.S enthusiast, an upcoming Linux SysAdmin, web developer, and currently a content creator for TecMint who loves working with computers and strongly believes in sharing knowledge.

Each tutorial at TecMint is created by a team of experienced Linux system administrators so that it meets our high-quality standards.

Join the TecMint Weekly Newsletter (More Than 156,129 Linux Enthusiasts Have Subscribed)
Was this article helpful? Please add a comment or buy me a coffee to show your appreciation.


Leave a Reply
  1. Sometimes you get this error just by trying to set UID to the user which is higher then the allowed range defined at: /etc/pam.d/common-password.

    For example you try to set uid of 3000 and in that case the solution will be to edit the /etc/pam.d/common-password and change the line:

    password        [success=3 default=ignore] minimum_uid=1000
    password        [success=3 default=ignore] minimum_uid=3000

    save it and retry to create the user.


    The /etc/shadow should have 000 access permissions, and the “/bin/passwd” file should be owned by “root” with its user sticky bit set. If the system can not operate on the shadow file without externally adding Read/Write Access, IT HAS A BUG.

    • @umca

      By default, the /etc/shadow file permissions should set to 0640 and owned by user and group root. You can check on your Linux system.

      • I did check my system, and I have access to several Redhat 7 and CentOS 6 systems. In each case, the /etc/shadow permission is *000* out of the box. It may seem redundant, but it’s more secure that way.

        It might be different on other systems such as Debian, but so long as the /bin/passwd program is given “root” program access (as it ought to have out of the box), setting the shadow file to more than 000 should not be necessary.

        • @unca

          It’s true, we have checked to confirm this, on some Linux distros such as RHEL/CentOS, the /etc/shadow has 0000 permissions and Debian/Ubuntu has 0640 by default. Many thanks for the useful feedback.

  3. As per in my case on Ubuntu, I got to find that this issue happens due to corrupted file on path /etc/pam.d/common-password so I have on a working system with the same os or can be from live cd (i think so) and copied the same file and replaced the original one. And my issue is resolved.

    I mentioned here because I researched much time for some solution but no one is worked well, so finally got this trick and shared with you. All the steps above mentioned I tried didn’t solve my issue. But anyway thanks for the support and giving a resolution.

  4. Mis-configured Selinux setting is another possible problem here; we fixed this with:

    # restorecon -v /etc/shadow

    and the response was:
    restorecon reset /etc/shadow context unconfined_u:object_r:etc_t:s0->unconfined_u:object_r:shadow_t:s0

    The clue for us was an entry, that we think was generated by the passwd command, in /var/log/audit/audit.log[.N]:

    type=AVC msg=audit(1557686143.503:880784): avc: denied { create } for pid=33555 comm="passwd" name="nshadow" scontext=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0

    Note the difference between [scontext=...:passwd_t:...] and [tcontext=...:etc_t:...] fields.


Got Something to Say? Join the Discussion...

Thank you for taking the time to share your thoughts with us. We appreciate your decision to leave a comment and value your contribution to the discussion. It's important to note that we moderate all comments in accordance with our comment policy to ensure a respectful and constructive conversation.

Rest assured that your email address will remain private and will not be published or shared with anyone. We prioritize the privacy and security of our users.