Administrator button fails to work in kde-settings and kcontrol

Typing

sudo kcontrol

from the console enables administrator tasks to be accomplished. This is a workaround. There are error messages about uid being 1000 when it should be 0, but it works.

kdesu kcontrol

fails with error messages.

This means that the system is usable now.

Chandra,
What language setting did you install Kubuntu with? Thanks! Dthacker

Need more info.

Dave,

I installed it with English, pre-selected as default.

Typing locale at the console gives:
*******
LANG=en_AU.UTF-8
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=
*******

For spelling, I used British English.

Chandra

I am online just now and can furnish more info at short notice if you tell me what commands you want executed and what messages you need logged.

Chandra

Dave,

Please tell me what additional information you need me to provide and I will endeavour to do so.

Thanks.

Chandra

> I installed it with English, pre-selected as default.
> Typing locale at the console gives:
> *******
> LANG=en_AU.UTF-8

I just installed Kubuntu Gutsy from the i386 Desktop install CD (the image was verified, so that isn't a problem).

Language for the installation was set to Finnish (fi_FI.UTF-8) and Adept failed to complete installing the (security) updates after the installation. I finished the updated package installations with "sudo dpkg --configure -a" from console (said "y" when it asked whether "/etc/qt3/qt_plugins_3.3rc" could be overwritten by the version from the updated package, what had modified that during Kubuntu installation???), otherwise the system was as installed from the CD.

Then I needed to set the language to Finnish from the KDE control center too, because most of the UI wasn't Finnish. After adding Gimp I need to add language-pack-gnome-fi too, Gimp translations didn't come automatically.

Then I tried to set kdm to AutoLogin the person for whom I was installing Kubuntu but couldn't because of this particular bug (with exactly the same error messages). Most of the time with the installation went to debugging & resolving that issue, I'm not sure about whether the language or Adept issue are related to this.

Installed Kubuntu Gutsy amd64 from the live cd 2008-01-15 using safe mode.
Selected English during the install.
Ran apt-get update && apt-get upgrade.
Installed NVIDIA restricted drivers from nvidia.com.
Installed mad-wifi from source.
Installed ndiswrapper
Installed atheros wireless windows drivers using ndiswrapper.

Select K -> System Settings -> Network Settings -> Administrator Mode
I am prompted for my password, I see a progress message "reading network configuration"
then it returns to the greyed disabled listing of available network devices.

Very new to Linux.

I'm encountering similar, and additional problems. Fresh install, all I've done is an update with adept, though the problem presented before that. Apparently at random Klauncher stops working properly, and I can no longer run anything that needs it, which is apparently anything of value. Administrator mode failing to work is new to today, but I've had Klauncher problems persisting through two reinstalls.

Gutsy 7.10, Kubuntu.
Sony VGN-AR190G computer.
Laptop, 2x 100GB HDD, Core 2 processor, 2x 512MB sticks of ram, not sure what the motherboard is off the top of my head. I don't really know what information will help, but I'm usually online, so let me know what will help. I'd very much like to not have to restart my laptop every few minutes.

I unraided the two drives and have one as root, one with my music on it. The problem(s) seem to happen with exceptional frequency when I try and do anything with the second drive. At the moment it mounts into my home directory, and is read/writable by any user. Not sure if this is relevant.

This problem disappeared as mysteriously as it arose. There are two possible reasons for this as far as I can see:

1. A recent update/upgrade using

sudo apt-get update &&sudo apt-get upgrade

flushed the problem out somehow.

2. The encoding was not set to default on konsole. This was noticeable when man pages had funny symbols instead of a hyphen. When the encoding was set back to default, the hyphen issue went away. I cannot be sure if the administrator button problem disappeared simultaneously.

In any case, the administrator button works now.

This issue dissapeared for me also in my Kubuntu Gutsy amd64 installation. However, I had to format my amd64 partitions and install the 32 bit version of Kubuntu Gutsy for testing purposes. Once the CD install completed I ran `apt-get update && apt-get upgrade` and the administrator button problem is there.

I didn't know if recent fixes got backported or not, but from the sounds of it, they have. I am going to mark this as fix released, however if you believe this is still an issue, then I urge you to reopen this report. Thanks everyone!

I am sorry, the problem has returned.

The administrator button in KDE Control Centre (kcontrol) does not work. When pressed, there is a "Loading" message and it hangs up after that. Clicking any other function after that causes the program, to abort.

The workaround

sudo kcontrol

spews error messages like

Error: "/var/tmp/kdecache-<username>" is owned by uid <user-uid> instead of uid 0.

but allows administrator tasks like font installation to be done.

Is there any reason why this problem recurs so unpredictably?

I would be glad to see it fixed once and for all.

Thanks.

Confirming. Duplicate report found and added to this report.

Out of curiosity, I just upgraded to KDE 3.5.9, simply to see if the problem went away, and it has.

I wonder if this information can help track down the cause of this recalcitrant bug.

Thanks.

I'm seeing this in Hardy Beta.

Please, please, please fix this - its ridiculous that this isnt a critical showstopper bug.

'Medium' importance is a joke. In what parallel universe can you release a desktop distro to end users with a bug like this present?

Interestingly, while trying to fix this, i found that it seems to be related to ip addressing/hostnames.

As far as i can see, the name returned from 'hostname' must have an entry in /etc/hosts mapping it to 127.0.0.1

Setting this up returned my kcontrol administrator access.

In my /etc/hosts file, the hostname of my workstation was mapped to 127.0.1.1. I'm pretty sure this was set up automatically by the ubuntu gutsy installer.

I hope this helps with the once-and-for-all elimination of this bug

In my current Kubuntu 7.10 installation my /etc/hosts contains:
127.0.0.1 localhost
127.0.1.1 somehostname
But I have no problem to use Aministrator Mode in System Settings or kcontrol.

But!
Testing Hardy (Kubuntu Desktop i386 (20080417.1)) in live session (not installed) I can't turn the Administrator mode on.

When I click it, the red box is shown for a short while and the content of it starts to update, but then the System Settings return to previous state without administrator rights.
It prevents me from configuring network during live session.

I have been toying around with the live session of Hardy pre-RC a bit more and I noticed this (steps to reproduce it):

1) I boot live CD
2) ps aux | grep dcopserver leads to: "ubuntu <pid and stuff> dcopserver [kdeinit] --nosid"

Scenario 1 (bug):
3) I go into System Settings, go into Monitor & Display settings, hit the Administrator Mode button.
The red rectangle shows for a short while, than it gets back no non-administrator display.
4) RMB on KNetwork manager in tray and choosing "Manual Config" leads to big error dialog:
DCOP communications error
There was an error setting up inter-process communications for KDE ..cut.. message:
Authentication Rejected, reason: None of the authentication protocols specified are supported and host-based authentication failed ...cut.. (something like make sure dcopserver is running)
5) ps aux | grep dcopserver leads to:
ubuntu <pid and stuff> dcopserver [kdeinit] --nosid
root <pid and stuff> dcopserver [kdeinit] --n

Scenario 2 (ok):
3) RMB on KNetwork manager icon in tray and choosing "Manual Config" -> the network configuration dialog is shown with working Administration rights, so I can change setup.
4) System Settings -> Monitor & Display -> Administrator Mode -> leads to working administrator mode with the "red rectangle" dialog, and I can change settings
5) ps aux | grep dcopserver leads to (same output like in Scenario 1 as far as I can tell, unless my eyes are fooling me):
ubuntu <pid and stuff> dcopserver [kdeinit] --nosid
root <pid and stuff> dcopserver [kdeinit] --n

(all outputs/messages have been written down to paper firstly and than retyped, so of course the 5th step output here is identical, it's C'n'P, but you will have to believe me it was really the same)

So basically the only difference between bug or working is whether the administrator authentication is called from KNetwork (works) or from System Settings (fails). I hope this helps.

Hardy-Kubuntu-Desktop amd64 (CD of 2008-04-17.1)

I have to see how the next installation case looks, but I got something pretty similar but without the second dcopserver running. Initial status was exactly as described before. The systemssettings dialogue would drop back to unprivileged mode after a few seconds.
Then I started the hardware driver manager to enable the nvidia driver and I got the exactly same error message in a box as in the previous comment. The box goes away and installation run normally. After that and even after reboot, the admin mode works.

I captured the console message when systemsettings fails for the first time. I can confirm that
1. kill the root dcopserver created by systemsettings
2. run either manual network manager configuration or, at least it seemed to work once, call the
    restricted driver manager.
After that it administrator mode seems to work.

I'm using Kubuntu Gutsy, fully updated, and have had this problem since upgrading from Feisty.

One interesting workaround, though it does require gksudo, is to simply do: gksudo kcontrol. This generated the following konsole output:

$ gksudo kcontrol
kbuildsycoca running...
ing new authority file /root/.ICEauthority
DCOP Cleaning up dead connections.
kdecore (KProcess): WARNING: _attachPty() 12
QImage::smoothScale: Image is a null image
QImage::smoothScale: Image is a null image
QImage::smoothScale: Image is a null image
$

The 'cleaning up dead connections' part looks interesting.... After doing this, the root-owned dcopserver was gone, but more importantly, future use of kcontrol from the normal menus just works - e.g. on the Login Manager tool within Kcontrol, the Administrator Mode works (doesn't prompt as the sudo is established I guess.)

Not sure if I will need to re-do the gksudo invocation every time the sudo credentials run out, but since "gksudo kcontrol" could be put in the KDE menus it may be a better workaround than using Konsole. I would still really like to see a fix though.

There are several more dupes of this bug I think:

https://bugs.launchpad.net/ubuntu/+source/kde-systemsettings/+bug/176518

https://bugs.launchpad.net/ubuntu/+source/kdesudo/+bug/182403

See http://ubuntuforums.org/showthread.php?t=133582 for another workaround (DCOP server restart) that worked for some people. Perhaps a new bug should be opened to cover the Gutsy re-occurrence?

It would be interesting to find out if

kdesu kcontrol

had the same beneficial effect:

"DCOP Cleaning up dead connections."

I cannot test this since I no longer have this problem, but I believe that the observation above from Richard holds the clue to the solution.

I don't have the problem any more, at present, so I can't test it..... I did try kdesu and/or kdesudo on kcontrol before hitting on gksudo, and it didn't seem to clear things up at all. None of the other sudo options including plain 'sudo kcontrol' had the same effect of getting the DCOP connections cleared up. (Someone else on the Ubuntu forum link did find that restarting the DCOP server also did this.)

Interestingly, after a reboot I have found no need to repeat the 'gksudo kcontrol' - now I find that kcontrol launched from menus is OK, with the Administrator Mode button functioning. Also, after the reboot, I had only one dcopserver running:

$ ps aux| grep dcop
richard 6478 0.1 0.0 25840 3104 ? S 10:19 0:00 dcopserver [kdeinit] --nosid
richard 6643 0.0 0.0 2992 788 pts/1 S+ 10:19 0:00 grep dcop
$

My two KDE sessions on Gutsy were interspersed with long sessions on XP and Ubuntu Hardy (separate partition and using GNOME not KDE), so I think any sudo credentials must have expired by now (and they should be reset on boot anyway).

My workaround is not ideal, as gksudo may well not be installed on Kubuntu by default, and will probably pull in GNOME libraries, but I hope it helps in figuring out a better workaround or a fix.

my story:
1)everything was working fine on Feisty
2)upgraded to Gutsy (had to finish it from the shell). System Settings and everything was working alright.
3)upgraded KDE from 3.5.8 to 3.5.9 then everything requiring administrator mode stopped working. I wasnt even getting the prompt for my password. Sudo kcontrol was functional though.
4)after reading this threat checked out my /etc/hosts file and the local hostname address was set to
127.0.1.0, which is a wrong loopback address. I edited it to 127.0.0.1 and everything went back to normal.

-- excerpt of my /etc/hosts --------------
127.0.0.1 localhost
127.0.0.1 heuboxub
#heu...was 127.0.1.0 for heuboxub
127.0.0.1 www.adbrite.com
127.0.0.1 creative.clicksor.com
-------------------------------------------------

Maybe the whole problem was caused by a mistyped loopback address in some install script??

@heu: Perhaps you have a different variant of this problem. The default Ubuntu/Kubuntu setup is that your hostname has an entry for 127.0.1.1 in the /etc/hosts file, but it would be good if those who still have this problem can test this.

Could you try reverting your hosts file to original setup, and see if you get the problem again? If so, maybe you could try the 'gksudo kcontrol' or DCOP server shutdown and restart workarounds, and post any output here.

My hosts file has always had a 192.168.1.x address for this host - this did not change with the upgrade from Feisty to Gutsy, so if it is the cause then it's a regression.

For what it is worth, I just checked my /etc/hosts file and found out that the first line was

127.0.0.1 localhost

while the second line was

127.0.1.1 <hostname>

Perhaps the first line was a leftover from manually editing the file in some previous setup. I have now commented it out and will post here if there are any problems arising from this. I do not know the significance of that first line and believe that localhost recognition now happens via /etc/network/interfaces.

Richard: I reverted the hostname address to 127.0.1.1 and sysconfig (and kcontrol) is still working as it is supposed to so I guess that, even when in my case changing it to 127.0.0.1 helped to put sysconfig/kcontrol back on their feet, the problem is somewhere else (unless someone else has tried it and it helped to restore system settings/kcontrol functionality on their system).

Non-applicable for KDE4.

In Intrepid System Settings doesn't have a "root mode" but rather launches the various modules as root via kcm shell. Eventually we'll probably get some policykit goodness to ask for passwords within the app so that we don't need to use that hack, but for all intents and purposes this bug probably won't need to be fixed in the future due to architectural changes and probably won't be fixed for the KDE3 version of system settings because it's unmaintained.

Selon Jonathan Thomas:
> Non-applicable for KDE4.
>
> [...]
> ** Changed in: kde-systemsettings (Ubuntu)
> Status: Confirmed => Won't Fix

Oh! I'm glad to see I was right when I decided to switch back to Debian
(Etch on my desktop and Lenny on my notebook), I've also just downloaded
the 12.2 release of the Slackware and I'll give it a try.

But your answer confirm that *buntu are for su><ors...

Is there something I should do so I won't anymore from *buntu ?

> --
> Administrator button fails to work in kde-settings and kcontrol
> https://bugs.launchpad.net/bugs/175909
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.

--
> 23:34:56 14 billion years up, 12e45 users load average: 53435.0 3533.2 48633.3
       Hugo (né il y a 1 409 645 889 secondes)

I have a fix that works for me and makes complete sense:
(my) problem was user was not in admin group (after creating new user then - silly me? - deleting previous user + files before logging out and back in.
To add user to admin group withou any admin user available:
Bootup with (K)Ubuntu cd and edit as root etc\groups to add user name to admin group.
Stephen on Rock 3 20Jan09, advanced pc user but not a developer