Probleme mit KDE, .ICEauthority und .DCOPserver

B

bluez

0
Auf einem Rechner mit Kubuntu8, auf den ich im moment nur per ssh zugreifen kann, kann sich ein lokaler Nutzer nicht anmelden.
Nach Eingabe des Passwortes bekommt er die Fehlermeldung:
"The following installation problem was detected, while trying to start KDE:
No write access to '/home/username/.ICEauthority'.
KDE is unable to start.
Zum Vergrößern anklicken....

klickt man auf OK kommt:
Could not start ksmserver.
Check your isntallation
Zum Vergrößern anklicken....

Andere am Rechner angelegte Benutzer bekommen ebenfalls erstere Fehlermeldung, aber eine andere zweite:
Could not start kstartupconfig.
Check your installation
Zum Vergrößern anklicken....

Google spuckt haufenweise Leute mit demselben Fehler aus, aber ohne Lösung oder nur die:
Ich soll die Datei /home/username/.ICEauthority allen zugänglich machen (chmod 777). Der Gedanke eine anscheinend wichtige Datei (was bewirkt die?) jedem Zugriff zu öffnen behagt mir irgendwie nicht. Oder kann ich das bedenkenlos tun?
Um zu sehen ob das überhaupt funktioniert hab ichs mal gemacht, woraufhin der Nutzer sich tatsächlich einloggen konnte - Beim Zugriff auf die Speichermedien wurde dann aber ein Fehler mit der Datei .DCOPserver gemeldet. Tatsächlich scheint diese Datei nirgends auf dem Rechner zu existieren...

Auch wird hier (vorletzter Post) geraten fsck --rebuild-tree laufen zu lassen. Nun habe ich schon ab und an gehört, dass das häufig zu Problemen führt ... Mir wäre es aber zumindest wichtig für eine begrenzte Zeit ein notdürftiges GUI-Interface für einen Benutzer zu erstellen um rund 5GB Daten zu sichern (für ssh ist das zuviel, der Nutzer kriegt es per shell nicht hin und ich kriege von hier aus keinen Zugang zu seinen Speichermedien per ssh)...
 
Die Datei muss für den User selbst les- und schreibbar sein, nicht aber ausführbar (das ist wichtig). Die umask des Users muss also auch so eingestellt sein, dass die Datei für den Benutzer entsprechende Rechte bekommt, wenn sie vom dcopserver angelegt wird. Es handelt sich meines Wissens nach dabei um ein einfaches Lock-File, in dem der dcopserver u.a. vermerkt welche Devices er in /tmp/.ICE-unix/ angelegt hat.
 
Ok also müsste chmod 600 reichen?

gut soviel zur .ICEauthority ... und was ist mit dem dcopserver? wo finde ich die Datei? Ich konnte die nämlich nicht finden (muss normalerweise doch unter /home/username stehen...) und wie sollten die Zugriffsrechte auf die sein? welche Rechte muss die Datei selbst haben?

derzeit steht übrigens auch /temp/.ICE-unix auf 777, da sie nich im /home verzeichniss liegt kann 600 ja nicht reichen, es müsste schon 660 sein, oder?
 
Das Verzeichnis mit den Devices in /tmp muss auf rwx für alle gesetzt sein. Das macht der dcopserver automatisch so, bei der Lock-Datei im Home ist das aber nicht notwendig und die Datei dort wird im Normalfall mit Read-Write-Rechten für den Benutzer angelegt. Die Datei .DCOPserver befindet sich im Home, heisst aber nicht wirklich so. Im Normalfall nennt sie sich .DCOPserver_<hostname>__<X-Session-ID> und liegt im Home des Users. Ausserdem existiert ein Link namens.DCOPserver_<hostname>_:<X-Session-ID>. Diese Datei hat normalerweise Lese-Schreib-Rechte für den Benutzer und für alle anderen Leserechte. Darin ist lediglich die PID des dcopserver-Prozesses vermerkt, der mit dem kdeinit-Prozess verbunden ist.

Alles in allem klingt es für mich nach zerschossenen Rechten zumindest im Home-Verzeichnis des Users, ggf. auch in anderen Stellen des Systems.
 
Ach je, so ist es ... die Besitzrechte der Datei .ICEauthority lagen bei root und nicht beim Nutzer ...mit etwas abgänderten Suchbegriffen bin ich darauf gestoßen, dass es anscheinend ein (Ubuntu?) Bug ist: bei einigen Einstellungen die man als root vornimmt (ich hatte vorher Benutzer angelegt) ändert sich die Besitzzuordnung von .ICEauthority.

Ich habs jetzt manuel wieder gerichtet und hoffe dass es eine Weile so bleibt...

Da es zu dem Problem schon teilweise Beiträge von 2004 gibt, werde ich wohl auch nicht der einzige mit dem Problem bleiben ...

Also zusammengefasst: chmod 777 /home/user/.ICEauthority ist schwachsinn.
chown user /home/user/.ICEauthority müsste helfen.
 
Prinzipiell sollte man als root niemals in User-Homes rumpfuschen. Dann gibt es auch solche Probleme nicht. Ich kenne diesen Fehler bisher nicht und würde daher auf einen Benutzer-Fehler tippen. Legt man Benutzer und sein Home-Verzeichnis normal mit useradd oder adduser an, tritt dieses Problem jedenfalls nicht auf. Bei Ubuntu gibt es einfach das Problem des sudo. Das verleitet User zu oft mit root-Rechten in ihrem Home Änderungen zu machen.
 
eher würde mich das "su" anderer Distributionen dazu verleiten ständig als root zu arbeiten ... denn wenn ich einmal umgeloggt bin, bin ich zu faul mich auch wieder auszulogen :D

Aber glaubs oder glaubs nicht: ich habe wirklich nur als der betreffende Nutzer per sudo neue user erstellt... nicht mehr und nicht weniger ... alles was ich sonst gemacht hab lief mit normalen Rechten.
 
mag sein (hab das zwar nicht gewusst, weil meine letzten nicht-ubuntu experimente schon ne weile zurück liegen) aber es ist noch bequemer wenn man tatsächlich nur einen befehl als root gibt und dann erneut über sudo gehen muss ...nene ich bleib dabei: ich finde sudo weit sicherer als su.

wobei das aber eigtl nicht mehr zum Thema gehört :D
 
Da sudo lediglich das Benutzerpasswort benötigt und bei Ubuntu damit alles möglich ist, ist sudo bei Weitem nicht sicherer als su. Gut konfiguriert kann es aber durchaus eine Arbeitserleichterung sein und Benutzern die Rechte geben, die sie tatsächlich benötigen ohne dass sie alles dürfen.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben