Bug 61850

Does "kcheckpass" on command line accept the password as correct? 

Yes. And when I give the wrong password for control center, it resuses it and
asks again. Only on correct answer goes on to do the above described thing.

root is probably not allowed to write on your display whatsoever. Dumb check: Does it work 
when you set "xhost +localhost"? 

No, still don't work (I could run an xterm az root, so the xhost was set OK).

This bug may be related to that I have my home on nfs, with 2.2.25 kernel and nfs-user-server 2.2beta47-12 on the server. The client is woody.

I can't reproduce that. If anyone else can, please reopen.

Finally I have managed to pin down the cause: the home is on the NFS server, but root_squashed. Thus, the root on the client is not able to access the home dircetory of the user. Going administrator mode requires to touch some of the files in .kde (the nfs server reports them as root squashed access denied or something like that). I think kcontrol should be avere this and give a meaningful error message, if it's not possible to avoid accessing the user's files.

I had the same error a few times already (also with the lastest CVS version), but I don't know a way to reproduce it.

For me, it has nothing to do with NFS. I have all my files on one partition on my PC.

*** Bug 85052 has been marked as a duplicate of this bug. ***

I never had problems with KDE 3.2.x or KDE 3.3.0_alpha1, only with beta1. Nothing is printed out on stderr or stdout and nothing on .xsession-errors.
I'm not sure if the bug of KDE 3.3.0_beta1 is the same as this.

Now no problem for me on KDE 3.3.1 (neither on final, I don't remember on other betas).

I do have the Error here on my System.
curiously, when i run the kdesu-line which is given in the password dialog, from an xterm, it works. 

Sorry,forget the details,
my homes are local, no nfs_whatsoever, and here goes the .xsesseion-errors:
kio (KSycoca): WARNING: Found version 72, expecting version 75 or higher.
kio (KSycoca): WARNING: Outdated database found
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: WARNING: Could not find module 'kdm'.

I Have this same promlem ever since upgrading to KDE 3.4 from 3.3.2. 

PLEASE HELP.

To fix the problem I did an rm -rf ~/.kde
Then it worked for 1 day...now I have the same problem again!!! PLEASE HELP.

Here is the console output from kcontrol:

[paul@titan ~]$ kcontrol
[paul@titan ~]$ QImage::smoothScale: Image is a null image
QImage::smoothScale: Image is a null image
QLayout "unnamed" added to QVBox "m_body", which already has a layout
QImage::smoothScale: Image is a null image


I get this as soon as I click "LOGIN MANAGER":  QImage::smoothScale: Image is a null image


I get this as soon as I click "ADMINISTRATOR MODE":  QLayout "unnamed" added to QVBox "m_body", which already has a layout

Typing the correct pw brings me back to the default category description screen.  Typing an incorrect pw, i get the "AUth failed" error.

PLEASE HELP.  I have kde 3.4 (rpm install) on an up2date Fedora3 system.

I have this problem too after compiling KDE-3.4 from source.

Test:
Control Center -> System Administration -> Login Manager -> Administrator mode -> Run as root -> enter root password  => crash. The Control Center displays the "Wellcome to KDE Control Center" splash screen instead of starting the administrator mode.

Control Center -> System Administration -> Font Installer -> Administrator mode triggers the same fault.

I did not have this problem using KDE-3.4-RC1, compiled from sources.

I did have this problem using KDE-3.4-beta2.

uname -a
Linux lfs 2.6.11 #1 Wed Mar 2 22:19:23 CET 2005 i686 athlon i386 GNU/Linux

gcc version 3.4.2

Best regards,

Magnus Larsson

Hello again,

I can make this work, once, by reinstalling kdebase: 
init 3, stop kde, x
su
make install
init 5, starting x, kde
=> Control Center System Administration -> Login Manager -> Administrator mode works.

A subsequent restart of the machine causes Control Center to revert back to the old behaviour.

Magnus Larsson

Same problem here with not be able to log into the admin mode in KControl. If I create a new user it will work until the first reboot, then it is broken in that user account also. I'm running KDE 3.4 final in PCLinuxOS with 2.6.11-oci2.mdk kernel. Thanks, Sal

Why is it neccessary to vote for a bug in order to get the attention of a kde developer?  This bug is affecting the newest stable version of kde, and I haven't heard one thing from anyone with even a slight resemblence to a fix.  What gives?

I am having this same problem in kde-3.4.  I enter in my root password and click "OK", then it takes me to the same screen as if I had clicked "Cancel".

I've got some additional info.

fc3
kde-redhat RPMs (redhat RPMS).

Got the same problem. Clicking on Adminstration Mode in any module brings me back to the intro screen. After this happens and then try to run a program by opening up konsole su to root and then run a command produces a dcop error something about protocol not being supported and host authentication failed. To further this, if after the error occurs you delete the file ksycoca from the users kdecache folder in /tmp then administrator mode works. Reboot the system and problem returns.

Obvious workaround until the problem is fixed, is to run the command from rc.local

rm -Rf /tmp/kdecache-*

Please fix this. It seems that this problem has been here for some time.

Are there any KDE developers here????  I was under the impression that KDE was under active development.... This is a generally annoying bug that affects the latest stable version of their product, and we don't get so much as a whimper from a single kde coder.... WHAT GIVES?

I started a long thread on this over at the kde-redhat list. I can report the exact same issues as Eli, above. The same workaround is working for me as well. 

Paul, have patience.  It seems this only affects some people, and sometimes only sporadically.  Personally, I have never been able to reproduce the problem, so it makes it difficult to investigate or debug further.

On my Kanotix 2005.2 system, the file ksycoca is in /var/tmp/kdecache-(username)
When I see this problem, I follow the procedure that Poster #41 has outlined and I have full Administration Mode in kcontrol again.
I tried making /var/tmp "sticky" to see if permissions was preventing some process  from deleting this ksycoca file, but the problem persists.

I don't know if my issue is the same but it sounds similar but I get no errors. When I click "Administrator Mode" the screen says loading .... but nothing. No password prompt, nothing, just sits there saying it is loading. very trouble some.

I upgraded to KDE 3.4.1 under Kubuntu "Hoary Hedgehog" and encountered the same bug (failure to enter Administrator Mode). I notice that this bug has been around on and off since KDE 2.9 (see Bug 39436). Why is the fix for this bug so elusive, so unstable??? I wonder if ANYONE actually understands the true nature of this bug.

I don't know if this is related to the bug but when I run the kcmshell command from Terminal, using the command string from the Control Center's password dialog (e.g., "kcmshell kcmsambaconfig"), none of the Administrator Mode changes will take. The change is simply ignored and no error message is given. Control Center's Administrator Mode is really, really wonky. It is, thus, quite useless.

I am not impressed.

The command that KDE is running to try to authenticate root is:

kcmshell kde-clock.desktop --embed 37752185 --lang en_US

/var/log/syslog shows:

Jun  4 01:05:34 Monkey100 su[6356]: + pts/4 miles:root
Jun  4 01:05:34 Monkey100 su[6356]: (pam_unix) session opened for user root by (uid=1000)
Jun  4 01:05:34 Monkey100 su[6358]: + pts/4 miles:root
Jun  4 01:05:34 Monkey100 su[6358]: (pam_unix) session opened for user root by (uid=1000)

/var/log/user.log shows:

Jun  3 23:26:09 Monkey100 gconfd (miles-5159): starting (version 2.8.1), pid 5159 user 'miles'
Jun  3 23:26:10 Monkey100 gconfd (miles-5159): Resolved address "xml:readonly:/etc/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0
Jun  3 23:26:10 Monkey100 gconfd (miles-5159): Resolved address "xml:readwrite:/home/miles/.gconf" to a writable configuration source at position 1
Jun  3 23:26:10 Monkey100 gconfd (miles-5159): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2

Hey folks, please VOTE for this bug.  It appears as though KDE developers have not actually seen this bug report yet, and voting appears to be the only way to grab their attention.  Ridiculous.  Microsoft even has a better bug reporting/fixing cycle!!!!!!!!

Hello again, 

I still have this problem after compiling KDE-3.4.1 from source.  
  
I also had this problem using KDE-3.4.0 (please refer to comment #16)
http://bugs.kde.org/show_bug.cgi?id=61850#c16

This time I used a P4 instead of Athlon, new gcc, binutils and glibc and
rebuilt the entire system.

I am trying to adhere to the instructions from kde.org.
http://developer.kde.org/build/compile_kde3_4.html
I build manually: ./configure, make and make install.

uname -a 
Linux lfs 2.6.11.9 #3 Sun May 15 14:50:59 CEST 2005 i686 pentium4 i386 GNU/Linux
 
gcc version 3.4.3 
 
I have not managed to extract any useful crash information (.xsession-errors, gdb). Please advice. Thank you.

Best regards, 
 
Magnus Larsson 
 

Is kdesu installed? Is it setuid root?

Paul P.: we are aware of the bug. But until we can find its source, we can't fix it. And there are other bugs, and other tasks to do. Calling us incompetents (as you did) will not make us know more about the bug than we do now.

So, if you can't give constructive information, don't post.

This means you can't reproduce it even with the NFS setup?

I also have this problem, i can reproduce it everytime.. need a backtrace?

i dont have nfs -i have reiserfs on my home and ext3 on root partition

i'm on yoper linux and i made kde rpms by myself with checkinstall
here's my console output after i'm beeing send to default kcontrol screen

kdesu (kdelibs): [su.cpp:180] Read line <Password: >
kdesu (kdelibs): [process.cpp:350] Child pid 29001
kdesu (kdelibs): [su.cpp:180] Read line <>
kdesu (kdelibs): [su.cpp:180] Read line <kdesu_stub>
kdeprint: kdeprint: unregistering 0x8243d3c, number of objects = 5
kdeprint: kdeprint: unregistering 0x82ae18c, number of objects = 4
kdeprint: kdeprint: unregistering 0x82b86a8, number of objects = 3
kdeprint: kdeprint: unregistering 0x8308814, number of objects = 2
kdeui (KAboutDialog): setPixmap (iconName): kcontrol
QLayout "unnamed" added to QVBox "m_body", which already has a layout



i realised that reinstaling my kdeadmin rpm solves the problem until the next reboot i think

for now my solution is to run "kdesu kcontrol"

well i have a clue that can help You tracking the bug. After running kcontrol as a regular user and trying to log in to administrator mode in one of the kcontrol windows i get back to the maim window as everyone (almost). So i just try kdesu kcontrol and the interesting thing is that first execution of kdesu kcontrol dosn't open kcontrol at all but the second does.
It happens when u try as i did - after trying to login to administrator mode in kcontrol run as a regular user.
sometimes it's even second execution of kdesu kcontrol that doesn't run and i have to try 3rd time.Maybe it depends on time too

here's what i do to over come this problem:
run `kcontroledit` (as your user) and do save.
now you can run kcontrol and enter admin mode with no problem, it will work until the next reboot.

Here is what I do to fix the problem:

Reboot the computer.  When grub popps up, choose "WINDOWS XP".  Continue booting.  Now everything works fine.

ha         ha             ha so so so so funny - i would thank u for that usefull comment but i can't stop laughing - u should spend time in showbusiness isntead of waisting ur great jokes in kde forums

I also have this problem, every time. I get round it by running 'kcontrol' from the command line as root.

OK - just installed ubuntu with KDE 3.4.0.  Had exactly this problem.  The way it shows is I need to enter the ip address for my network interface.  Open kcontrol as user and click on admin mode.  Enter password and get dumped back at the network settings screen.  So far, same as everyone else.  Then - I used sudo or kdesu kcontrol and get root access.  Entered missing ip address under Route - applied changes and exited.  Open kcontrol again and the ip address has disappeared!!  This means I cannot get internet or network access on this machine.  Reproduceable on a second machine with same installation.  Upgraded to 3.4.1 but still the same problem.

My workaround is pathetic but it works!! I have found that I can make a change in network settings by kdesu kcontrol as long as I make the change, choose aply changes BUT DO NOT EXIT.  The changes registers as long as I do not close kcontrol.  Obviously if I close kcontrol and/or reboot all is lost.  PLEASE FIX THIS - IT IS CRIPPLING US BECAUSE OF NO NETWORK ACCESS without following this silly workaround.

Dude, if you use linux, I really shouldnt need to tell you this, but you do not *need* kcontrol to change your network settings.  True, kcontrol is nice....but it is also broken.  In fedora and several other flavors, you modify the following file to adjust network settings: 

/etc/sysconfig/network-scripts/ifcfg-eth0

Mine looks like this:

DEVICE=eth0
#BOOTPROTO=dhcp
BOOTPROTO=none
ONBOOT=yes
NETMASK=255.255.255.0
TYPE=Ethernet
IPADDR=192.168.1.101
USERCTL=no
PEERDNS=no
GATEWAY=192.168.1.1

PS, vote for this bug please.

Same here as in comment #35.

Strange enough, the kdesu dialog when started from within KControl asks me for root permission for "kcmshell kdm --embed 33556076 --lang de". However, when I type "kdesu kcmshell kdm" to start the dialog in command line it works just fine after giving me the following message box (translated from German):

"there has been a problem with setting up the communication between KDE processes. The system message was: <Authentication rejected. None of the authentication protocols specified are supported and host-based authentication failed.> Please make sure that dcopserver is running!"

Good news folks....I just updated to from 3.4.0 to 3.4.2-0.fc3.2 and this problem  finally seems to be resolved.

Hello bugs.kde

I does not work for me.

I still have this bug in KDE-3.4.2, built from source.

Moreover, I still have this bug in 3.4.90 (alpha1, >= 20050806), built from source. 

Kcontrol falls back to the default window of control centre if I try to log in to admin mode.

This is what I get from 3.4.90 (alpha1, >= 20050806) if a start Kcontrol in a Konsole, starting login manager admin mode:
>kcontrol 
...
 QLayout "unnamed" added to QVBox "m_body", which already has a layout
kdesu (kdelibs): [process.cpp:263] Running `/bin/su'
kdesu (kdelibs): [su.cpp:186] Read line <Password: >
kdesu (kdelibs): [process.cpp:263] Running `/bin/su'
kdesu (kdelibs): [su.cpp:186] Read line <Password: >
kdesu (kdelibs): [process.cpp:350] Child pid 6154
kdesu (kdelibs): [su.cpp:186] Read line <>
kdesu (kdelibs): [su.cpp:186] Read line <kdesu_stub>
kdesu (kdelibs): [process.cpp:263] Running `/bin/su'
kdesu (kdelibs): [su.cpp:186] Read line <Password: >
kdesu (kdelibs): [process.cpp:350] Child pid 6157
kdesu (kdelibs): [su.cpp:186] Read line <>
kdesu (kdelibs): [su.cpp:186] Read line <kdesu_stub>
kglobal_freeAll!!
[
0: /opt/kde-3.5-alpha1/lib/libkdecore.so.4(_Z11kdBacktracei+0x41) [0xb773bfe1]
1: /opt/kde-3.5-alpha1/lib/libkdecore.so.4(_Z11kdBacktracev+0x2b) [0xb773c35b]
2: /opt/kde-3.5-alpha1/lib/libkdecore.so.4 [0xb77f34a5]
3: /opt/qt-3.3.4/lib/libqt-mt.so.3(_ZN12QApplicationD2Ev+0x90) [0xb7104ef0]
4: /opt/kde-3.5-alpha1/lib/libkdecore.so.4(_ZN12KApplicationD1Ev+0x269) [0xb772b989]
5: kdesu(_ZN7QWidget6createEmbb+0xfe3) [0x804eb9b]
6: /lib/libc.so.6(__libc_start_main+0xcd) [0xb6a08e0d]
7: kdesu(_ZN7QWidget22windowActivationChangeEb+0x39) [0x804e091]
]
                                                                     
uname -a:
Linux lfs 2.6.12 #1 Sat Jun 18 20:54:49 CEST 2005 i686 pentium4 i386 GNU/Linux

Best regards,

Magnus Larsson

i confirm , still present in kde 3.4.2 build from source (konstruct)

Please disregard my message stating that 3.4.2-0.fc3.2 fixes the issue...it does not. After updating to 3.4.2-0.fc3.2, it worked at least once, but I tried it again today, and its broke again....

Also, way to go Magnus...it was about time someone took the time to compile w/ debug symbols.  

*** Bug 112639 has been marked as a duplicate of this bug. ***

Is this a problem for the minority or the majority?  I must admit I am new to these bug reports, but is anyone looking into this?  If not is there anything I can do to help?

yes, you could post a patch.

*** Bug 112896 has been marked as a duplicate of this bug. ***

I have had this problem for quite awhile also. After reading through the list above and following some of the leads you guys provided I think I have found the source of this problem. If I run kcontoledit as suggested above then everyting works fine, I can log in and out to KDM and still go to Administrator mode no problem. However everytime I reboot the system Administrator mode fails. So after tracing what file get changed by doing the save with kcontroledit I noticed that there are two copies of ksycoca. One in /var/tmp/kdecache-(username) and another in /tmp/kde-(username). On my system I have a bootscript that cleans out /tmp/ on every boot removing the later file. So I restarted the system copied the file from /var/tmp/kdecache-(username) to /tmp/kde-(username) and tried to log in to Administrator mode and viola it works.
For my solution I simply altered my boot script not to clean out /tmp/.
Looks like if kcontrol can't find the file ksycoca in /tmp/kde-(username) it just bails out.

Well a really weird thing happened.

I came to this page because I had more or less the same problem. I couldn't get to Administration Mode using K Menu -> System Settings, and all sorts of weird things happened when I tried to run systemsettings from the command line with any kind of privilege (I'm a newbie so I can't really remember what I did). I've also tried enabling and disabling the root account with no success.

Then, as I said, I came to this page via the ubuntu forums. And I learned about kcontrol and I thought I'd give it a try. And it worked! It asked me for my password and then entered administration mode as expected. And now my System Settings work too, like nothing ever happened!

I'm using kubuntu 5.10

Stan:

 Like most people, I came to this page hoping to find a solution to this problem I was having (entering administrator mode in KControl). Your solution (post #52) worked great for me - I copied the two ksyscoca (ksyscoca & ksyscocastamp) files from /var/tmp/kdecache-(username) to /tmp/kde-(username) and was able to enter administrator mode right away - with out rebooting (like Windows) or even restarting KControl. Thanks!

I am not sure but I think lnusertemp is the broken link in this story.
If you remove $KDEHOME/tmp-$LOCALHOST (/home/user_name/.kde/tmp-localhost), $KDEHOME/cache-$LOCALHOST (/home/user_name/.kde/cache-localhost), /tmp/kde-$USER , /var/tmp/kdecache-$USER and then run `lnusertemp tmp` and `lnusertemp cache` you'll be able to use kcontrol in admin mode until next time you reboot.
`lnusertemp tmp` and `lnusertemp cache` are executed in startkde and I have the feeling they do not do what they should do.
You can also temporarily fix the problem by running kbuildsycoca.

fhaked:

 You're right about that. After rebooting (damn power company), I get the same problems. I tried the steps you mentioned (checking administrator mode after each one). It was the one in /var/tmp/kdecache-$USER (after running `lnusertemp cache`) which worked for me, and changed the date-stamp of /var/tmp/kdecache-$USER/ksyscoca & ksyscocastamp (the same as by running kbuildsyscoca). 

 I noticed startkde runs kded (which "is responsible for keeping the syscoca database up to date." However, the date on mine was several days ago suggesting either it isn't kept up-to-date, or another copy of it is.

 I'm not sure how much this helps anyone, though. I think I'll just add to my Autostart directory a script which calls `kbuildsyscoca`.

Hi!

For me running kbuildsycoca after a reboot also restores admin mode.

If you want kded to run kbuildsycoca on every start, add

[General]
CheckFileStamps=false

to ~/.kde/share/config/kdedrc:

Without rebuilding ksycoca I get the following error messages from kcmshell when trying to start a kcontrol module in admin mode:

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

Just running `kded` in terminal will also do the job without rebuilding ksycoca.
kded will claim to already be running but it creates the link (/tmp/kde-user/ksycoca) anyway, which fixes the kcontrol problem.

Created attachment 13231 [details]
fix

Possible fix attached.  kdesu passes ksycoca path as /tmp/kde-user/ksycoca which is a symlink to /var/tmp/kdecache-jr/ksycoca.  Sometimes that symlink doesn't exist in which case admin mode fails.  Running kbuildsycoca recreates the symlink but rebooting removes it.

Patch applied to SVN (3.5 and trunk).

w00t.

I still got this bug in KDE 3.5.2 running under SuSE 10.0 (with kernel 2.6.13-8).  It seemed the bug is not distribution specific as I saw similar complaints in Fedora and Ubuntu forums as well.  Some even dated back to KDE 2.9!

Tried some workarounds mentioned here but they are not working for me.  I issued rm -rf /var/tmp/kdecache-(username), ran dcopserver --nosid, then kded, then kbuildsycoca, but the bug still there.  kdesu kcontrol once, works but with error messages about uid.  

For me the bug may be from kcmshell that cannot call the correct embed id.  I was working fine in KDE 3.5.1 (kdebase3-3.5.1-40.suse-x86_64.rpm) with no such problems before my recent upgrade.  

I am having the same "admin mode" failures after upgrading 32 bit KDE from 3.5.1 to 3.5.2.

the same bug on suse 10 32bit here after upgrade to 3.5.2

It's still in Kubuntu's 3.5.3 and I seem to have no success deleting the ksycoca file for a change.

yea its still there, but the work around i use in kubuntu is to open the system settings app via sudo... works everytime (that is when kdesu works :-/ )

Bug is still there -- opensuse 10.2 with KDE 3.5.7. 

Please see bug 175909 in kde-systemsettings/kcontrol at 

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

The error messages I get on console when the Administrator Mode button is clicked 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'.
***********************************