I saw another post from a couple years ago with the same issue. password-changed-itself/20782
Just loaded in latest amd64 manjaro a couple weeks ago and now for the second time my primary wheel user’s password has been “mysteriously reset”. Luckily I had set up direct ssh root access from my former dev machine so I can go in and reset it otherwise this install would have been foobared (would have had to reset from a snaphsot).
So what gives? why would this happen? never ever happened in ubuntu ever.
About the only thing I can think of was I was messing around with sudo pacman when this happened. So could that have done this?
I have seen people carelessly merging or simply replacing .pacnew files - with dire consequences.
Only you can know what has happened - you can trace back your steps via the shell history and by examining /var/log/pacman.log to see what was installed/replaced.
Your issue is clearly not a wide spread phenomenon, else the board would be swamped with similar issues.
To fix it there is usually a backup /etc/passwd~. Verify your username is at the end of the file and - if it is - use cp to replace the existing file.
sudo cp /etc/passwd~ /etc/passwd
No - passwords are never reset by an update.
Confused by the presense of a file named passwd.pacnew?
It would happen if you - without giving thought to the process - replace a configuration with a .pacnew file
Never automate .pacnew files - it may wreck your system completely.
Ubuntu doesn’t have .pacnew files
Manjaro is based on Arch. Manjaro is for the most parts a self-service system.
Yes - the manjaro-system script takes care of some of the tedious ripples discovered when upstream Arch makes important changes to the system - but in general the user is solely responsible for what happens with the system.
Updates never - ever - touches files in any user’s home - neither is local system configurations ever changed by overwriting or replacing files in /etc but instead the new configuration file is written with an extension of .pacnew - e.g. mkinitcpio.conf.pacnew or passwd.pacnew.
If you change an apps local - system wide settings - and then remove the app - the apps local configuration is not removed but is save using an extension of .pacsave.
Can you explain a bit more what you mean here, because the wheel user is not a normal user account and does not have any password to login into…
If you mean your account that is part of the wheelgroup, can you explain what you tried to do which made you think your password was reset? (Maybe you think your password was reset while in fact it was something different)
So please give step-by-step explanation of what you did and what you expected to happen…
I searched my rootfs for .pac* files as suggested in the wiki and found none so it doesn’t seem related to .pacnew .pacsave and the /var/log/pacman shows nothing irregular?
this user has sudo privileges but as I have come to discover there is no sudo group in arch but rather wheel. So what I mean this is user can run commands as root via sudo so it’s possible I did something to change this users entry in the shadow file without ever running passwd
All I can report is that since I was working on some aliases and functions for pacman and possibility that activity somehow created the issue. Other than that I am unable to share a “step by step” leading up to the issue. So I have taken steps to be sure I can recover (like creating another admin (i.e. sudo/wheel) user I can login to and reset the original user’s password. I also now have cron job for rootfs snapshots and I can remote from my laptop to reset as well. So I am covered should it happen again. There is also a terminal logger tlog I can set to help review a terminal session/shell if it happens again.
Taking measures to prevent and to be able to mitigate if it occurs in conjunction with backup and/or snapshots is due diligence -
It is - remotely - possible that filesystem errors may create the issue.
According to btrfs evangelists this cannot happen with btrfs - I beg to differ - btrfs has caused me some hairpulling incidents in the past - and while I have tested it from time to time - I am not personally satisfied with it.
yes this is first time on any distro I’ve had this issue. This is the first time also I have ever used a btrfs subvolume for a rootfs so maybe you @linux-aarhus might be right. I’ll stick with btrfs for now but switching to ext4 is something to consider if I keep having this issue for no apparent reason. Now that I have a second sudo user if that user too has bad pw at the same time then I might assume the /etc/shadow file got corrupted (via btrfs) rather than anything I did.
The /etc/shadow file isn’t something that you edit.
less /etc/group
shows you all the groups on your system and which group has which members
simply typing:
groups
will tell you which groups your user is a member of
if you need that user to have admin rights, you add the user to the wheel group:
(there is more than one way to do it - like this, for example):
gpasswd -a username wheel
ps:
all of these commands and probably hundreds more will be there to be re-examined or remembered
if you look at the shell history
It may help you remember what you did.
The command for that is: history
if you use the bash shell
Or you can simply list the contents of: ~/.bash_history
history | less
or less ~/.bash_history
The same goes for the root account: /root/.bash_history
… if you logged in as root did what you did there …
So far we have no STR (Steps to reproduce), nor explanation how the OP logs into his normal account, only that he uses SSH to login to his alternate account and opinions what could have changed without facts for it…
It started out as a password problem, but is now turning into a sudo problem.
So im out of here as following trails of impressions and opinions are not my style to debug a problem.
If i were i might as well roll a dice and say this is the cause, which might be more acurate as anything else…
