On both SuSE10 OSS and Fedora Core 5 I have had an error message
'.DCOP authentication error' or 'check that your DCOP server is running' when I've attempted to use kdar to restore a backup following a fresh install. On the first time it boots into a login screen and logs in ok, but often when I reboot X doesn't start and I get error message like 'connection to Xserver refused'.

Somehow restoring a kdar backup seems to much up authentication and logins. Can anyone tell me what is going on? Also how do I fix it?

I'd have to suspect something in Kdar is causing the problem. I use Dar, the command-line backend to Kdar, and I've never gotten such errors after restoring.

Thank you for your quick reply. As I have to install dar as an extra in Fedora Core 5 to restore backup, I just use kdar as a convenience tool. But will try just using dar command exported from kdar. Still mucking about with backup/restore automation/scripting.

Cheers

Sometimes running a program as root will create a root owned file that you can't delete, such as a stale pid file in /var/run. In your home directory, a log file may be root owned and so the program can't append log entries to the end of it.

Look in your home directory for root owned hidden files like .Xauthority or .xsession-errors. For KDE, try the command:
find ~/.kde -uid 0


Look in the latest xorg log for details on why it wouldn't start.

If it is a problem with running kdar, then try starting it from the console. It may provide better information on what the problem is.

Dear jschiwal

Your comments have suggested an answer to two other things I was puzzled about as well such as comment from chkrootkit and why firefox will only run as root since I accidentally started it as root.

Have reloaded from CD both KDE and Gnome desktops. I tar -cvf home.tar /home and
tar -cvf root.tar /root and ran backup using kdar (pretty much scripted the whole process now, including dar commands, so some good has come of it!)which went well. Then I restored the pristine post install tarred directories. Now able to open konsoles and xterms, which was a related problem to .DCOP and login authentication hassle.

After getting another caffeine and sugar hit, I will now try what you suggested and see how I go once I reboot.

Thank you for your quick reply! I'll let you know how it goes.

Cheers

On the Fedora Core 5 desktop I reinstalled both KDE and Gnome, ran kdar backup and untarred the home.tar root.tar files from new install. Logged out of root and logged into user ok. Rebooted from user and now again cannot login to either user or root using terminal, gnome,kde,failsafe etc interface. The error message is as below:

(~/.xsessions-errors file)
/etc/gdm/PreSession/Default: running: /usr/bin/sess reg -a -w /var/log/wtmp -u /var/run/utmp -x
"var/gdm/:0 .Xservers -h" "-1 ":0" "root" session-child-run:
Could not exec /etc/X11/xinit/Xsession default

I mainly use SuSE and know what the error messages mean now, but just learning Fedora and the above is a bit beyond me. I suspect it may be a permissions problem.
Also I did originally install the default gnome interface but later switched to KDE, which is why I installed both KDE and Gnome interfaces on reinstall.

Any help appreciated!

Look at the long listing of "/etc/X11/xinit/Xsession" and see what the permissions are.

Are you missing a dash or underscore in your error message. I'm not on my Linux computer now so I can't look at mine. is -default an option?

Using Fedora Core, you also should check the SELinux error log. SELinux can prevent you from reading a config file. Also, it could have blocked restoring certain files.

Here is a quick test that can tell you if the problem is with something in your home directory or is system wide: Create a new user. Can the new user log in?

Another quick thing it do is to boot up with a rescue disk and delete the contents of /tmp/. Then reboot.

Also, if you restored the contents of your old SuSE home directory to your new Fedora Core installation, then you have a new UID. I think that Fedora Core starts UIDs at 500 while SuSE starts them at 1000.

Go into your home directory and do a long list of the contents. If you have files with an unknown owner (UID) or a different UID, then you can use the find command to locate all of them and run chown and chgrp on them. You will need to su to root to have permision to do that however.

For example, suppose that the uid on the restored files are 1000, and your new uid is 500, and your username is "mazinoz".

#find ~mazinos/ -uid 1000 -execdir chown mazinos '{}' \;

Wow.

Basically I use SuSE10 OSS on laptop and Fedora core 5 on desktop. The default is an option on the session menu when you log in, or at least attempt to do so.
The problem I'm dealing with now is solely Fedora on the desktop. Sorted .DCOP problem in SuSE on laptop. Didn't try to restore a SuSE 10 backup to Fedora Core CD install, but a Fedora backup on top of a fresh Fedora CD install. Your right Fedora is 500. Basically it objects to the Xsession file in /etc/X11/xinit.

The home directory doesn't have any root owned files, I have already chown the one I found.

I recall enabling SElinux and setting it at restricted on one of my installs but I recall setting it to permissive on the last one. How can I disable it altogether without having to do a fresh CD install? ie what config files do I need to change if you know off hand. Anyway need to find out more about it and try the new user and tmp suggestions, and will let you know.

Thank you for your help. Although I tried a few things what finally seemed to be the solution was disabling selinux in not only menu.lst but also /etc/sysconfig/selinux. After that I could login and I'm fairly certain this was the problem. SuSE uses AppArmour now not SElinux and I haven't had time to learn the details of it. Got caught on this using an external USB drive also.

Once again, thanks for your patience and suggestions!

Oh and best wishes for Christmas / New Year! What the hell, why am I doing this?

Cheers

Thank you! Merry Christmas and Happy New Year to you as well.