Root password not accepted

Hallo, could anybody advise on following problem please?

When performing certain activities, like trying to install VBox additions, request for root password is displayed, but the password is rejected as if not correct, although it is correct.
Many other events accept the root password without problems: su in terminal, YaST etc. Problem is only with the black overlay dialog.

Running OpenSUSE 13.1 (with all fixes applied) in virtual mode, hosted in Oracle VirtualBox.

I’m not very skilled with Linux, thanks for any tips.

What “black overlay dialog” are you talking about?
Can you please post a screenshot?

Btw, you don’t have to install VBox guest additions in openSUSE.
They are included and installed by default. :wink:

Wow, that was quick :slight_smile:

This is the black overlay dialog I mentioned: https://drive.google.com/file/d/0B_Mz6sGq1mS8VnZKNXJ1enhLODg/edit?usp=sharing .
The other type - normal modal widow dialogs for root psw (like the one when entering YaST) accept root password well.

Thanks for the tip on VBox additions beeing in SUSE already. I just wanted to update, because there was notification of beeing outdated.

Anyway the problem with root password not beeing accepted is not limited to VBox additions installation.
It happens whenever I want to change some system settings like network etc.
So any suggestions how to fix are welcome.
It’s clean installation, no changes or modifications. Problem occurs right after installation.

Well, you are using GNOME.
I cannot help with that I’m afraid.
No idea where that dialog would come from. Seems to be some GNOME-internal thing.

Does it work when you run “gnomesu /sbin/yast2” or similar? (probably, as you said you can start YaST from the menu)

And how exactly are you trying to install the guest additions when that dialog appears?

Thanks for the tip on VBox additions beeing in SUSE already. I just wanted to update, because there was notification of beeing outdated.

There should not be any notification, if you use the shipped additions at least (I never saw one even after installing really old openSUSE versions like 11.3 upto 12.3 in VBox).
And there’s not really a need to update them.
You could do so via the Virtualization repo though, as you can start YaST.
Add that in “YaST->Software Repositories”->Add->Community Repositories, then install the newer “virtualbox-guest-*” packages with YaST->Software Management. You would also get automatic updates then…

Yes, I understood that.
I’m just trying to find out what displays this dialog, i.e. what is not working.

It happens whenever I want to change some system settings like network etc.

Where? In GNOME’s settings? Or in YaST?

Does rebooting help?

Have you manually changed the pam configuration?

I’m not at all sure here. However, my experience suggests that these requests from policy-kit depend on the systemd user agent. Presumably the user agent communicates with the main systemd process. If an update restarts the main systemd process, that breaks the communication and it might not work properly until reboot. And if the systemd entry is removed from the pam configuration, that also breaks the communication.

Thanks for the tip on VBox repository, I will check that later.

But we can abstract the problem from VBox completly. Easiest way to reproduce the troublesome root psw dialog is to go to “Settings -> Users” and push the “Unlock” button: https://drive.google.com/file/d/0B_Mz6sGq1mS8Y24zMDMxQjhYVDA/edit?usp=sharing. The overlay root psw window is displayed in GNOME.

Calling something through gnomesu works fine and displays the standard modal window for root psw, which accepts password just fine: https://drive.google.com/file/d/0B_Mz6sGq1mS8aWZZWEc1ekotN0U/edit?usp=sharing.

Thanks a lot for your time.

No, several reboots and still the same. It actually occured right after first install of SUSE 13.1 from the downloaded package. Clean install, not an upgrade.

I did not, it’s behaving this way right after installation without changing anything.

Hm.
At least you’re not alone apparently:
https://ask.fedoraproject.org/en/question/44735/authenticate-dialog-rejects-root-password/
Unfortunately they only “fixed” the problem there by switching to XFCE as desktop environment… :\

Maybe it is actually asking for your user’s password, not root’s? Yes, I know that it says “Admistrator”, but you could at least try to enter the user’s password once.

Try this to maybe find out what’s the problem:

Check the system journal; run this command as root in terminal:

journalctl -b -f
leave it running and try to authenticate, it should print info from polkit about what went wrong.

Yes, this is exactly the problem I have. I tried to google all over before posting here but found no solution. Baybe GNOME bug?

I tried all accounts’ passwords besides root, but didn’t work. The info in log is the same as the guy you linked mentions. No sign of error, just messages related to pressing CANCEL eventually.

Thanks a lot for your effort anyway, I appreciate it :slight_smile:

Will check GNOME pages specifically for this problem.

Be sure you are using the right case. I sometimes hit cap locks accidentally and if you did when first root password entry then maybe you use the wrong case. DId root password ever work?

BTW by default root password is set to the first user password unless you change it at install.

Apparently it works fine when he uses “gnomesu” to run things as root.
It’s just GNOME’s built-in password dialog (which uses polkit apparently) that fails.

Yes missed that. I don’t know grub either LOL

grub? I suppose you mean GNOME? rotfl!

Anyway, I just tried it here, and it works fine. So it’s definitely no general openSUSE/GNOME problem.

Some more thoughts:

  • Have you installed all updates already? GNOME as shipped in 13.1 had some bugs that got fixed later on.
    No idea if that root authorization stuff was amongst them though.

  • Maybe your root password contains strange characters that GNOME doesn’t like?
    KDE e.g. did have such a problem, that got fixed not too long ago.
    So maybe try to change your root password to some simple one for a test.
    Run “su” in a terminal, and then “passwd” to change root’s password.

Yes, I did a clean install and then applied all updates available, problem persists.

I tried, even simple passwords, just letters and numbers, or just letters, not working.
Looks like a bug rather than misconfiguration.

I checked bugzilla for GNOME 3 and didn’t find this particular issue being open, even though there are quite many complaints about this on many forums. I’ll try to open the bug case myself and will post a link here.

Thanks wolfi323 and others for trying to help me guys!

I opened a bug ticket in GNOME bugzilla. Let’s see if they recognize it.

https://bugzilla.gnome.org/show_bug.cgi?id=736240

Devs on GNOME bugzilla claim this is not GNOME related bug:

This is not a gnome-keyring issue, nor is the prompt a gnome-keyring prompt.
This bug may be related to polkit or your system configuration. You may need to
type your own password here instead of the root password? Not sure.

Any thoughts about the polkit?

No, they claim that it’s no gnome-keyring related bug, and that the dialog doesn’t come from gnome-keyring.

But IMHO it definitely comes from some GNOME-related thing, just by judging from the looks of it, and it is presented when you change things in GNOME’s settings.

As I don’t even use GNOME myself and have no insight in GNOME, I have no idea what would present that dialog or how that could fail.

Any thoughts about the polkit?

Not really.

What does “loginctl” say?
Have you tried to get some debug output as I suggested before?

Maybe ask the developers that closed your bug report? They should know how GNOME works…

PS, because you mentioned polkit:
The root password dialog for the user administration e.g. is apparently controlled by the org.gnome.controlcenter.user-accounts.administration polkit rule.
Try putting this line into /etc/polkit-default-privs.local and run “sudo /sbin/set_polkit_default_privs” afterwards:

org.gnome.controlcenter.user-accounts.administration yes

Does the “Unlock” switch in the user settings work then? (you shouldn’t even be asked for a password any more)

This should not be necessary, but could at least narrow down the problem.

Might be a silly question, but has this system ever been updated? Could this just be a case of ancient packages?

zypper up

Then, although probably shouldn’t be necessary, a complete shutdown… wait 5 seconds… then boot up.

After that,
Without knowing Gnome’s gnomesu, I’d still verify that regular “sudo” works fine (I have no idea whether gnomesu layers on sudo).

TSU