Comments

dcopserver is a server for the Desktop communication protocol, the common interprocess communication of kde and uses unix domain sockets. unix domain sockets stores established sockets in files, which are read by clients.
The problem is that cygwin supports a cr to cr/lf conversation mode for files (called "textmode"), which let dcopserver fails to read this socket file.

I was having this same problem, but only when I logged in as a non-root user. I was not able to find anything that helped at http://kde-cygwin.sourceforge.net. After messing with it for quite a while on my Solaris 8 box I got it to work by chmod 01777 on /tmp/.ICE-unix, /tmp/.X11-pipe, and /tmp/.X11-unix. As best as I can tell, this gives the non-root user enough rights to create the files unix domain sockets stores established sockets in for Solaris. The problem is that these permissions get reset on boot so I had to create a small script to fix this. Hope this helps.

I had this problem too. (Red Hat Linux 9.0, fully updated to final releases)

It began about two weeks ago. The only effort I made to correct it was to start dcopserver manually at last login. Dcopserver ran fine so I guessed at startup script/config probs. Since then I haven't had the problem, so I can't comment further.

One of my users had the same problem after he tried to append to his PATH in .cshrc (his default shell). Apparently, he overwrote the default path rather then appending to it. When the user login, DCOPserver is run which then runs `iceauth' using the user's PATH. The path to `iceauth' is /usr/X11R6/bin, which was not in the user's PATH statement, hence the DCOPserver error. After he corrected his PATH statement, it fixed the DCOPserver issue.

Another fix to this problem, at least in my situation, was my home directory did not have group and global write access. Changing it over to 777 fixed the DCOPserver problem along with a slew of other problems

Hy i discovered this thread in an effort to get my kanotix_2005_04 working. i've just installed it on my machine and DCOPserver keeps throwing kde inter-process communication failure on root and on my user. I am able to login but under a second WM provided IceWM(i guess) but this error pops up every time i press smth related to kde (e.g: running kde applications). Where is the problem and how can I solve it -i've hured it might be related to ICEauthority but i am new to linux and don't know anything about cli or commands or getting to that dir from cli etc. Please can u give me an answer and eventually write down some steps to accomplish this.Thank you,
Ford.

My solution to the problem was found on another post... it wasnt permissions or the chsrc file... I had to reinstall kdelibs (I just installed all available from my repositories) this cleared it right up... hope this helps someone!

I've got the same problem with my SuSE Linux 7.3:
Starting Linux and X-Server will show me the graphical login-screen. I switch to Textmode [Ctrl-Alt-F3], login as root and start the text-based setup-tool YAST.
I searched for installed packages with "dcopserver", deinstall & reinstall it and shutdown the computer.
After starting again, everything works fine (until the next time error ??). I can't explain it, because I'm Linux-newbie. May be, specialists will do it for me.

One of my colleagues had this problem.
It appeared that she was out of disk space (due to quota limitations).
When logging in, the system could not make a .DCOPserver_hostname:0 file under her account that contains data about the sockets KDE uses.
Starting KDE, the system starts looking for this .DCOPserver_hostname:0 file, which is not there (of course).
This generates the error.

I don't know if you found anything out as of yet, but I had the same issue and resolved it by deleting both the /tmp/.ICE_unix directory and the ~/.DCOPserver__-0 link. Logged out and it worked fine. Trying to find out if KDE's bugzilla has a report on this as of yet

on my machine (mandrake 9.1) the problem was that it was configured to get a hostname (which looked like this: 1,6,) from the dhcp server of my isp, which dcopserver seems quite to dislike.

the solution was to enter a hostname in /etc/hostname and to prevent dhcp from resetting it. to achieve this you just have to open /etc/sysconfig/network-scripts/ifcfg-eth1 (in my case eth1 is the nic connected to my cable modem) and change the line "NEEDHOSTNAME=yes" to "NEEDHOSTNAME=no"

One of my users recently switched to a tcsh default shell and the default .cshrc that comes with RH 7.3 does not include the /usr/X11R6/bin path in the $PATH env variable. I had to add to their path.

Note: the deafult .cshrc that comes with RH 7.3 overwrites the $PATH env variable, It was very frustrating to figure this one out. especially since I checked the default rc's and .logins to make sure the paths were there.

I am facing (it seems) the mother of all the problems described in this thread. I am running KDE using RedHat 7.3 on Linux. I logged in just fine to KDE, but tried to use KUser to add a new user - this gave me an error message saying that "error in /my/path/dcopserver__0 make sure dcopserver is running".

Not sure what to do, I went ahead and added the user alright and tried to log out of X to see if I could reboot and figure something out. Big mistake - I have not been able to log in _AT ALL_ ever since. I have tried both Runlevel 5 and 3 and _no_user_ can log in, including root (me). I am currently reduced to Runlevel 1 and have tried bizarre things to no avail. First, deleteing .ICE-UNIX or .Xauthority did not do anything for me. I also deleted some files to free up space. Finally, I managed to get dcopserver running on Runlevel 1 but of course as soon as I say "telinit 3", it seems to wipe it out. If I reboot, it automatically shuts down dcopserver. Is there anything I can do to avoid this problem? I can possibly write a script in /etc/rc.d/rc3d that tries to start up dcopserver (and switch at boot to runlevel 3) but I wonder if that would do any good.

Hi I am facing similiar problems. I have three logins two users a1 and a2 and a root. With login a1 I am able login, but with other login a2 I am facing similiar problem. I tryied to change the owner ship on .ICEauthority file. now the problem is if I try to login as root it overwriting .ICEauthority filr for login a2, because of that root login is also failing. Any suggestion to avoid this issue.

Yes! We had the same problem with DCOP on a
bunch of Sun Rays, which have a bunch of users
on one server. The first user to fire up KDE
ends up creating /tmp/.ICE-unix/ and of course,
they own it. The next user is unable to write
to the directory! When this is fixed the next
user can run KDE. I guess that the directory
should be owned by root with world write?

Problem here is slightly different in that root and users (with accounts) other than me have no problem. Trying to log in as myself I run into the same DCOPserver problem though it seems. Problem started for no apparent reason; just simply was there one morning at startup.

I have tried removing myself as a user (500), then creating a new myself (502) did not help. Also removing the /tmp/.icw* directory mentioned above did not help. There is no .DCOP* file or link to be found in the affected home directory.

I have even tried removing the entire KDE, then reinstalling KDE but whatever the problem seems to be tied to files not affected by removing/reinstalling.

System(s) here use SuSE 8.2 on, the one in question is SMP with plent of gigs to spare on HD.

I also use a SuSE 8.2, so your situation should be faily similar to mine. With me the same problem occured while I was experimenting with network settings, so I guessed it was due to that, but I'm not sure.

Anyway, I logged in as root and just did a SuSEconfig after I read that some people mentioned their settings were screwed up. The script told me that I had modified my kderc (somewhere in /etc/opt...; it tolfd me exactly where it was) and that it had generated a fresh one. So I copied that onto the old one and the problem was gone.

Hi all,
I am running SUSE 10.1 official version and i had the same problem when i tried to use konqueror to access a network folder. I was running konqueror as the only user that exist other than root.

FIX :
The fix for me to as root chown the users home folder.
chown -R XXX /home/XXX where XXX is the username

After that all worked fine.
I have found that few earlier weired problem like this also was due to some file in the users home folder with only root permission. I would be happy if someone can tell, whether there are any log files that we can look for the error messages like these in linux.
I mean like a log file which would have suggested that a file having only root permission failed to load the DCOPServer loading,

I had a similar problem doing a Debian Sarge install (using the Debian Next-Gen installer). The problem was permissions on /usr/X11R6/bin, which contains the program iceauth, which (I think) dcopserver needs to start. As installed, the directory was owned by root:root, and permissions were set to drwx------.

I used CTRL+ALT+F1 to get a text terminal. Logged as root, and then `cd /usr/X11R6` and `chmod go+rx bin`. Permissions are then drwxr-xr-x.

I had the same problem with dcopserver but didn't find the solution here.
When fixing something under gnome I fixed dcopserver. I am running gentoo
and when I installed it I didn't set up /etc/hosts correctly. That made
an anoying message pop up in gnome and caused kde to crash. By adding
127.0.0.1 localhost
all was well. Hope this helps someone out there.