I have two user accounts on the computer. One can login using lxde, the other can’t. Can anyone tell me where to look to fix this?
Thanks
That is nice story telling, but not much technical information.
Why can that user not login using LXDE. Mental issue? Does not appear as posibility in the DM screen/menu (and when so, which DM is in use? Is the user able to choose for LXDE, but thus then happens something different then expected and when yes, what?
In short, my fantasy is larger then your amount of information , but that would not help you much I am afraid.
A little less snark would be appreciated.
Display manager software:
xdm
lightdm
lightdm-gtk-greeter
Using lightdm.
On the dm login screen the user can choose the desktop environment (openbox, lxde, xfce4).
the user can choose an account of 2.
When I choose lxde, choose my user account, type in my correct password, click login, the screen goes dark and returns to the login screen.
When I choose the other user account, using lxde, type in the correct password and click login the login correctly occurs.
This is most likely due to a problem with user configuration.
Things to check:
Is the user HOME directory actually owned by this user?
If that is okay, then check the shell startup files (typically “.profile” or “.bashrc”). Can this user login at the command line (use CTRL-ALT-F2 to get to a command line login prompt)? If the user can login at the command line, and does not see error messages, then try renaming shell startup files (or move them to a different directory). Can the user then login to LXDE?
Yes
Logged in at CTRL-ALT-F2 with no errors.
I renamed them from .xxxxxx to xxxx.bak.
Still can’t log in with lxde.
Login at the command line, and then:
rm -rf .cache
That probably won’t fix it, but it is worth a try. Removing cache doesn’t normally affect anything, except that the next startup will be slower (rebulding the cache).
If that does not fix it, then the next step would be to rename “.config” and “.local”. But that’s more drastic, and will lose this users settings.
I removed the .cache.
I looked through .local and .config, but didn’t see anything related to lxde. If I rename .config and .local, and am successful in logging in, won’t that rebuild a .config and .local? If I don’t have a successful login nothing they won’t?
Yes. And you will have to setup the session the way you want it.
It is also possible that the problem is in other hidden files/directories (with names that begin with “.” – possible there’s a “.lxde” or similar directory or in “.gtk*” directories/files.
This is reversed. DE is per user, so when you choose user account you reset DE to whatever was saved for this user.
If you remove .config, you’re using a sledge hammer to kill an ant. Several web browsers and many other applications that wouldn’t affect the login problem put their userdata there. Some of the same results if you delete .local entirely.
I agree with nrickert that inappropriate file ownerships can cause this, so either examine your home tree a few levels deep, and/or run this command that assumes something in the tree needs fixing:
sudo chown -R *myuser*:*mygroup* /home/*myuser*
I chowned my home folder. No joy.
I renamed .config to .config.bak and .local to .local.bak.
No joy.
I’ve also deleted the generated th .config and .local and replaced them with the .baks.
Please be aware that, for each and every human user of the system, all the files and directories, hidden or not hidden, located in ‘/etc/skel/’ have to be present in the user’s home/login directory and, owned by that user, with the default permissions as defined by the system wide “User Skeleton” directory.
I have never heard of /etc/skel. I’ll to check it out.
EDIT: all present in my home directory and owned by me.
That’s not strictly true.
When you create a new user, “/etc/skel” is used to create initial files for that user. However, in my experience, a completely empty home directory still works, and desktop software installs any other needed files.
I agree, /etc/skel is just a place where a system manager can prearrange stuff the he wants to create within the home directory of a new user. And openSUSE has pre-filled that with an adequate amount of stuff. It is up to the system manager to change there to his/her needs. The user then can change of course afterwards to his/her needs and part of what the users does is done by the desktop(s) (s)he starts. AFAIK it belongs originaly to the tool useradd. And YaST > User Management uses it also (it may do, or simulate useradd under the hood).
There is of course no need to use any of those tools. Just creating a user by adding entries to /etc/passwd and /etc/shadow, creating the home directory and chown it to the user:group. setting a password, is all that is needed (I do not award prizes, but love it to hear what should be done more then that to get a user going).
That said, when things are created and have the wrong owner, that will result into problems.
Does ls -n /home/myuser UID and GID for all files reconcile with UID and GID in /etc/passwd for myuser? Is there any username duplication in /etc/passwd?
I have no idea and don’t know how to check.
grep *myuser* /etc/passwd
will show myuser’s UID and GID.
ls -n /home/*myuser*
shows UID and GID of each file instead of username:groupname of each file by using ls -l.
Thanks for that.
Everything that showed up matched UID and GID. None of the hidden files or folders showed.I did chown the entire directory previously to my user and group from the terminal logging in as su - so everything would be properly changed.
EDIT: I did a ls -aln and everything still matched.