Version: (using KDE 4.0.3) Installed from: SuSE RPMs KDE 4.03 does not start, instead an error message appears in a terminal, saying: "Call to lnusertmp failed (temporary directories full?), check your installation" After clicking "okay" I find myself thrown back to the login screen. This only affects KDE 4.03, KDE 3.5 starts up normally.
Problem solved. I've unstalled the most recent updates offered by SuSe and KDE4 starts again.
Same behavior under 4.0.4 (latest Fedora 9 rpms). Workaround appears to be to do the following: rm -rf /usr/tmp/k*-USER rm ~/.kde/tmp-HOST rm ~/.kde/cache-HOST rm ~/.kde/socket-HOST (where USER is replaced by your username and HOST by your machine name) Then you can log in. But have to repeat this again each login.
*** Bug 159434 has been marked as a duplicate of this bug. ***
Mine is a very recent upgrade from Fedora8 to Fedora9. I'm running the KDE packages prepared by Rex Dieter from KDE-redhat-unstable, which are running fine on a different machine. I get the message each time I try to log in; it acts as though the xserver is being restarted after I click on the 'OK' button. I've tried creating a new user, but same result; I've tried removing all the files suggested by Tom Shield above, but I still can't log in; in another location, I found a suggestion to check whether I'd lost ownership of my home folder and I ran the command to ensure that ownership -- still no success. I can log in to Gnome and XFCE. Unfortunately, the 'fix' suggested by Edgar is too vague to be useful. I haven't updated any packages recently, except to migrate from KDE3.5 to KDE4
To add to the above, I have tried logging in as other users and as root as well, but I always get the same message. I've disabled Selinux as well, and before doing that, I'd tried a relabel.
It turns out there was a bug related to finding lnusertemp in the kdelibs-4.0.83-3 package I was using from kde-redhat-unstable; this was cured by an update, and KDE now starts fine. Here's the explanation: Fwiw, /usr/bin/lnusertemp is incorrect, it should be looking in /usr/libexec kde4/ , and kde4-config --path exe didn't include that correctly
Marking as WORKSFORME, as your update seems to have fixed the problem. Thanks for providing a clear descriptions.