Administrator button fails to work in kde-settings and kcontrol

Bug #175909 reported by R (Chandra) Chandrasekhar on 2007-12-12
Affects Status Importance Assigned to Milestone
kde-systemsettings (Ubuntu)

Bug Description

This bug is identical to:

Bug #15001, first reported on 2005-04-05 by Aric Wilisch
Administrator mode not working

and solved that year. It has re-surfaced and has also been reported again by Rohan Dhruva on 30 Nov 07. I can confirm what he has siad at:

but am reporting it as new because the older bug is closed.

It happened out of teh blue on a fresk Kubuntu Gutsy installation. Action taken included completely re-installing Kubuntu and also

sudo apt-get install --reinstall kcontrol kde-systemsettings

neither of which has helped.

Running either systemsettings or kcontrol from the konsole and clicking "Administrator Mode" for "Network Setings" does nothing but the console error messages are:

It looks like dcopserver is already running. If you are sure
that it is not already running, remove /root/.DCOPserver_kaveri__0
and start dcopserver again.

WARNING: Waiting for already running klauncher to exit.

WARNING: Waiting for already running klauncher to exit.

WARNING: Another instance of klauncher is already running!

kdeinit: Communication error with launcher. Exiting!

kio (KSycoca): ERROR: No database available!

kio (KSycoca): ERROR: No database available!

kio (KSycoca): ERROR: No database available!

kio (KSycoca): ERROR: No database available!

kcmshell (kdelibs): WARNING: Could not find module 'kcm_knetworkconfmodule'.

Could this bug be treated as serious and a workaround suggested please?

Removing /var/tmp/kdecache-<username> and kdecache-root does not help

Thank you.

Related branches


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.

DaveThacker (dthacker9) wrote :

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

DaveThacker (dthacker9) wrote :

Need more info.

Changed in kde-systemsettings:
status: New → Incomplete
assignee: nobody → dthacker9


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

Typing locale at the console gives:

For spelling, I used British English.


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.



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



Eero Tamminen (oak-helsinkinet) wrote :

> 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.

al (amcintosh) wrote :

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
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.

Deathknell (decaye) wrote :

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.

al (amcintosh) wrote :

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.

Richard Johnson (nixternal) wrote :

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!

Changed in kde-systemsettings:
status: Incomplete → Fix Released

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.


Richard Johnson (nixternal) wrote :

Confirming. Duplicate report found and added to this report.

Changed in kde-systemsettings:
assignee: dthacker9 → nobody
status: Fix Released → Confirmed
importance: Undecided → Medium

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.


ikekrull (pete-marchingcubes) wrote :

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?

ikekrull (pete-marchingcubes) wrote :

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

Setting this up returned my kcontrol administrator access.

In my /etc/hosts file, the hostname of my workstation was mapped to 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

Ped (ped) wrote :

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

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.

Ped (ped) wrote :

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.

Stefan Bader (smb) wrote :

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.

Stefan Bader (smb) wrote :

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.

Richard (rd1) wrote :

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.

Richard (rd1) wrote :

There are several more dupes of this bug I think:

See 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.

Richard (rd1) wrote :

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.

heu (h-e-u) wrote :

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, which is a wrong loopback address. I edited it to and everything went back to normal.

-- excerpt of my /etc/hosts -------------- localhost heuboxub
#heu...was for heuboxub

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

Richard (rd1) wrote :

@heu: Perhaps you have a different variant of this problem. The default Ubuntu/Kubuntu setup is that your hostname has an entry for 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 localhost

while the second line was <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.

heu (h-e-u) wrote :

Richard: I reverted the hostname address to and sysconfig (and kcontrol) is still working as it is supposed to so I guess that, even when in my case changing it to 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).

Jonathan Thomas (echidnaman) wrote :

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.

Changed in kde-systemsettings:
status: Confirmed → Won't Fix

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
> 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)

Stephen on 3rd Rock (sonrock3) wrote :

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

Changed in kde-systemsettings:
status: Won't Fix → Fix Committed
Changed in kde-systemsettings:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments