ubuntuusers.de

Entschuldigung abermals. Und ja ich habe immer BENUTZER korrekt mit monster ersetzt und auch auf Klein/Großschreibung geachtet.

Und daraufhin zeigte das Shell eben Benutzer und Rechte Änderungen in sehr schnell laufender Liste an.

jetzt weiss ich auf Anhieb auch keine Lösung.

Ich gehe von folgendem aus (korrigiere mich bitte wenn ich falsch liege):

• du nutzt eine X Sessien und nicht wayland

• du hast deine Änderungen an der .desktop Datei (siehe anderer thread)

• der login auf der virtuellen Konsole Terminal (Abschnitt „Virtuelle-Konsole“) mit dem user "monster" funktioniert

probiere mal folgendes aus:

in die virt. Konsole einloggen und einen neuen Nutzer zum testen anlegen.

1
2

sudo adduser testuser
sudo usermod -a -G sudo testuser

danach aus der virt. Konsole ausloggen und ausprobieren ob man sich mit dem testuser an eine Gnome session anmelden kann.

Ok. Also alle deine drei Annahmen sind korrekt. Und die .desktop ist aber wieser im Original Zustand als letztes gespeichert worden. Da ja bis zu dem besagten Abend das ganze noch nicht funktionierte.

Ähm und ja. Neuen Benutzer erstellt wie du gesagt hast. Und tada Login funktioniert. LOL...... Jetzt nur noch eine blöde Frage gibt es sowas wie ein Eroor Log wo ich den tatsächlichen fehler für den monster Account rausfinden kann?

h2oo schrieb:

Jetzt nur noch eine blöde Frage gibt es sowas wie ein Eroor Log wo ich den tatsächlichen fehler für den monster Account rausfinden kann?

Die Frage ist überhaupt nicht blöd! Aber ich habe hier nur rudimentäre Kenntnisse.Als Startpunkt deiner Recherche solltest du hier ansetzen Logdateien.

Es wäre schön wenn sich noch jemand meldet der sich besser auskennt als ich. ☺

h2oo schrieb:

doch also bei mir im Shell zeigt er das er die Rechte/Benutzer ändert und zeigt halt eine ellenlange Liste an Datein an.

Ah, stimmt, sorry. Hab das -v überlesen.

Dein Test mit dem neuen User spricht aber weiterhin dafür, dass es an den Rechten liegt. Wie ist denn die aktuelle Ausgabe von

ls -aluh | grep -v $(whoami)

wenn du dich mit dem User in der virtuellen Konsole anmeldest?

Hmm. Also also testuser@monster bekomme ich die selbe Liste von dem Befehl ausgespuckt mit den exakt gleichen Einträgen. Hab alle Rechte von monster@monster mit testuser@monster verglichen. ...

Wäre es eine allzu falsche Idee an eine frische Installation zu denken? Backup is ja von allen Daten da. Was mich halt extrem wurmt ist, dass ich gerne genau wüsste was mein Profil gebrickt hat ums in Zukunft aus Dummheit nicht nochmal zu machen.

poste doch bitte das komplette Ergebnis von

1

ls -aluh | grep -v $(whoami)

geb doch den Helfern die Möglichkeit die Ergebnisse zu interpretieren.

Natürlich gerne. Habe gerade nochmal das Terminal aufgemacht den Benutzer gewechselt und dann bekam ich aber nur eine Zeile als Antwort siehe Foto. Was genau heist das nun?

linne11 schrieb:

• du nutzt eine X Sessien und nicht wayland

Hallo h2oo,

zeig bitte mal die Ausgabe von

echo $XDG_SESSION_TYPE

h2oo schrieb:

Natürlich gerne. Habe gerade nochmal das Terminal aufgemacht den Benutzer gewechselt und dann bekam ich aber nur eine Zeile als Antwort siehe Foto. Was genau heist das nun?

Ich würde sagen das die Besitzerrechte im Homeverzeichnis in Ordnung sind. Da grep -v eine inverse Suche ist sollte als Ergebnis auch nur die eine Zeile ausgegeben werden.

linne11 schrieb:

h2oo schrieb:

Natürlich gerne. Habe gerade nochmal das Terminal aufgemacht den Benutzer gewechselt und dann bekam ich aber nur eine Zeile als Antwort siehe Foto. Was genau heist das nun?

Ich würde sagen das die Besitzerrechte im Homeverzeichnis in Ordnung sind. Da grep -v eine inverse Suche ist sollte als Ergebnis auch nur die eine Zeile ausgegeben werden.

Ok dann hab ich das schonmal richtig gemacht. Könnte ich sonst noch etwas überprüfen?

dirkolus schrieb:

linne11 schrieb:

• du nutzt eine X Sessien und nicht wayland

Hallo h2oo,

zeig bitte mal die Ausgabe von

echo $XDG_SESSION_TYPE

Also ich hoffe ich habe es richtig gemacht. Aus beiden Usern heraus ausgeführt gibt mir der echo Befehl nur eine leere Zeile zurück. Is das so richtig? Siehe hierzu Foto

Gut, das war jetzt irgendwie semi-schlau von mir, in einer virtuellen Konsole läuft natürlich keine graphische Session - daher konnte bei dem letzten Befehl nichts herauskommen.

Dennoch glaube ich ganz stark daran, dass Du als graphische Oberfläche nicht X11, sondern Wayland laufen hast, denn

• Die core-Datei hat einen aktuellen Timestamp und enthält einen Wayland-Abzug.

• es gibt keine .xsession-errors Datei (oder eigentlich überhaupt keine .xsession-* Datei)

Das können wir aber trotzdem nochmal verifizieren, indem Du diesen Befehl im (grafischen) Terminal nochmal absetzt, wenn bei Dir die Grafik mal wieder laufen sollte (in 10% der Fälle):

echo $XDG_SESSION_TYPE

Du hast Ubuntu (ohne das X,K,L o.ä. davor) in der Version 17.10 installiert und von dort ein Update auf 18.04 gemacht, oder?

Vielleicht bekommen wir Dein Problem in den Griff, indem wir auf X11 umstellen. Bitte gib mir mal die Ausgaben an von

file /etc/systemd/system/display-manager.service
cat /etc/gdm3/custom.conf

Der erste Befehl zeigt, welchen Login-Manager Du verwendest und der zweite Befehl gibt die Konfiguration aus, für den Fall, dass Du gdm3 nutzt. Könnte also sein, dass der zweite Befehl einen Fehler ausgibt.

@All: Ich habe selbst kein Wayland und kann momentan auch sonst nichts auf Ubuntu nachstellen, bin also noch auf Mithilfe von Wissenden angewiesen.

Dirk

dirkolus schrieb:

Gut, das war jetzt irgendwie semi-schlau von mir, in einer virtuellen Konsole läuft natürlich keine graphische Session - daher konnte bei dem letzten Befehl nichts herauskommen.

Dennoch glaube ich ganz stark daran, dass Du als graphische Oberfläche nicht X11, sondern Wayland laufen hast, denn

• Die core-Datei hat einen aktuellen Timestamp und enthält einen Wayland-Abzug.

• es gibt keine .xsession-errors Datei (oder eigentlich überhaupt keine .xsession-* Datei)

Also ich weiß nicht genau den Unterschied zwischen Wayland und Xsessions, aber hätte ich da nicht gezielt Wayland mit dem Einstellungszahnrad im LoginScreen auswählen müssen?

dirkolus schrieb:

Das können wir aber trotzdem nochmal verifizieren, indem Du diesen Befehl im (grafischen) Terminal nochmal absetzt, wenn bei Dir die Grafik mal wieder laufen sollte (in 10% der Fälle):

echo $XDG_SESSION_TYPE

Eingeloggt als testuser liefert der Befehl dann folgendes zurück.

1

x11

dirkolus schrieb:

Du hast Ubuntu (ohne das X,K,L o.ä. davor) in der Version 17.10 installiert und von dort ein Update auf 18.04 gemacht, oder?

Ich habe direkt das reine Ubuntu 18.04 http://releases.ubuntu.com/18.04/ (ohne extra Buchstaben) via DVD installiert. Ohne Update mit formatierter Partition, also keine Vorlasten.

dirkolus schrieb:

Vielleicht bekommen wir Dein Problem in den Griff, indem wir auf X11 umstellen. Bitte gib mir mal die Ausgaben an von

file /etc/systemd/system/display-manager.service
cat /etc/gdm3/custom.conf

Der erste Befehl zeigt, welchen Login-Manager Du verwendest und der zweite Befehl gibt die Konfiguration aus, für den Fall, dass Du gdm3 nutzt. Könnte also sein, dass der zweite Befehl einen Fehler ausgibt.

Also der erste Befehl liefert:

1

/etc/systemd/system/display-manager.service: symbolic link to /lib/systemd/system/gdm3.service

und der zweite Befehl bringt dann die übersicht übers custom.conf File siehe Bild.

Hmm mein grrade erster Beitrag ist grau geblieben und kein Bild lies sich hinzufügen. Darum sorry fürn Doppelpost.

h2oo schrieb:

Eingeloggt als testuser liefert der Befehl dann folgendes zurück.

1

x11

Ich habe direkt das reine Ubuntu 18.04 http://releases.ubuntu.com/18.04/ (ohne extra Buchstaben) via DVD installiert.

Ok, dann läuft bereits alles mit X11 / Xorg (Default-Einstellung in 18.04). Die Datei ~/core von Wayland irritiert mich dennoch.

Noch ein Test:

cat /usr/share/wayland-sessions/*

Das sollte ausgeben, welche Einstellung in GDM Wayland startet.

Vorsichtshalber könnte man noch in der Datei /etc/gdm3/custom.conf die Zeile

#WaylandEnable=false

so editieren, dass dort steht:

WaylandEnable=false

Und Wayland hier nicht gestartet wird.