Mon, 2 Sep 2024 00:19:32 -0400 Felix Miata <mrmazda@earthlink.net> :
bent fender composed on 2024-09-01 23:36 (UTC-0400):
Sun, 1 Sep 2024 22:14:18 -0400 Felix Miata composed:
bent fender composed on 2024-09-01 06:30 (UTC-0400):
Still cannot log-in if home folder is on a data partition NOT mounted undedr /home but as data and linked to.
This sounds like could be a disparity between UIDs/GIDs in /etc/passwd output,
Yes, it happens when the data drive doesn't get mounted for any reason. Then I usually mount it manually and all works as it should.
on /home/* without any filesystem mounted upon it, and those on the filesystem you wish mounted to /home/. Mount that filesystem somewhere other than /home/, then doing the following:
tail /etc/passwd (*)
Why tail, that lists only the last 10 lines, no?
If you have more than 10 users, capture the relevant data however else you please, like appending -25 to tail. Egrep them all by names if you want. Most systems don't have a whole lot of ordinary users, and most are usually in some portion of the file's tail.
ls -dn /home/ ls -n /home/ ls -n /mountpoint-of-data-filesystem/
-n means long list owner and group by numerical values instead of customary strings produced by -l.
Compare output of these to see if the username and groupnames correctly correlate among those outputs for each existing regular user that needs a GUI login to work.
* If relevant username/groupname do not appear in tail output, simply scan the file with any file viewer for the relevant username(s) and groupname(s) applicable for/to the needed comparison.
I'll have to be clearer paraphrasing my setup:
- all users are members of group g (1999)
To be clear, my proposal was all about numbers, nothing to do with permissions. Now that we know all users are in same 1999 group, it cuts in half the amount of data needing evaluation. If you already know there are no conflicts caused by mismatches of numeric UIDs among files, directories and passwd files, then this is pointless. OTOH...
I had two unfounded suspicions about two possibilities one of which hit pay dirt minutes ago. Somewhere in all this struggle & strife I issued # systemctl set-default multi-user.target to be able to log in as root at least and then call SDDM. THAT's when logging in as UserMe died. I'm saying this because (on a hunch as I said) as soon as I reverted with # systemctl set-default graphical.target I could log-in again. Systemd suck like Electrolux if you ask me; of course it ain't my boat, my bridge or my watch :-)