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.
- Agedu – A Useful Tool for Tracking Down Wasted Disk Space in Linux
- BleachBit – A Free Disk Space Cleaner and Privacy Guard for Linux Systems
- 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.
- How to Reset Forgotten Root Password in RHEL/CentOS and Fedora
- How to Force User to Change Password at Next Login in Linux
- 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.
What if you’re not an admin? Just wait on one?
Password Security is inherently an Administrative responsibility.
So, yes, you have to find an Admin to fix it.
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:
save it and retry to create the user.
@jeoppy
Many thanks for sharing this solution.
THE SHADOW FILE UNDER NO CIRCUMSTANCES SHOULD BE MADE READABLE BY ANYBODY. STEP 4 IS WRONG.
The
/etc/shadowshould 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.
I will create
chmod u+s /bin/passwdAs 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.
Mis-configured Selinux setting is another possible problem here; we fixed this with:
and the response was:
restorecon reset /etc/shadow context unconfined_u:object_r:etc_t:s0->unconfined_u:object_r:shadow_t:s0The 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=0Note the difference between
[scontext=...:passwd_t:...]and[tcontext=...:etc_t:...]fields.In solution 2 which PAM profiles should I choose to enable?