13.1 update: now user cannot log in to KDE, but root can

System updated many times (probably from 12.0) now refuses to run KDE as user. After stopping SDDM, I'm able to log in as either user or root via a terminal using startx, but KDE will only allow a login from root. When in the KDE root screen, the user can be seen but not altered. The user .profile is blank - no home directory etc. - but haven't attempted to edit it.
Very frustrating. I guess there is a missing or corrupt file somewhere, but I cannot figure it out.
All help / suggestions welcome. Thanks.
 
Thanks, didn't think of that. Will post the result tomorrow in case others have the same issue. Delayed - before the end of the week.
No, didn't work. I added the user to wheel, and it still won't even get to the KDE login screen.
In fact, I went so far as to delete the user and add it back pointing to the user's old directory, and it seemed to work - but wouldn't run KDE either from startx or sddm onestart.
There was a blizzard or messages such as could not resolve kysym XF86Macros which I could not understand.
It seems to me that there is a step I'm missing in adding a new user to FreeBSD / KDE.
Unless someone can help me here, I'll write a question asking how to add a new KDE user the proper way - but I continue to look.
Thanks again.
 
We checked the basic steps in search of a bug, but it is difficult to give solutions without showing the logs and configuration files.

Show the user outputs of id and ls -l /home. Is SDDM displayed? Login to Xorg or Wayland? Are kysym XF86Macros warnings messages or errors?

You say you can't get to the login screen. Look, in this case it was a driver issue:

 
Does X start for up your user if you're using a X terminal like the good, old xterm as window manager instead of a whole KDE session? If that's the case the problem is related to your users "KDE-dot-files"; You could also narrow things down by setting up temporarily a blank, new user account (don't forget to create that users "/.xsession" and/or "~/.xinitrc").
 
Many thanks to all the replies above. I will test later today / tomorrow.
However, as I have your attention the delays I have in fixing this issue is that I have a newly installed 13.1 installed on one NVMe, and this older, many times updated 13.1 on another. The older NVMe won't boot with the newer NVMe in place - it just stops. So I have to remove the new NVMe to boot the old one. I presume this is a loader version problem, and I don't even want to go there - but I should report it. Any advice on who/how to report it?
And anyway, can the loader (or whatever) be updated without losing the system?
Sorry if I seem to be complicating things - but this is the worst problem I've had in using FreeBSD for about 8 years - but I'm a desktop user, not a FreeBSD guru.
Thanks.
 
Sorry if I seem to be complicating things - but this is the worst problem I've had in using FreeBSD for about 8 years - but I'm a desktop user, not a FreeBSD guru.
Yes you are complicating things. I'm not any sort of guru either, but whether FreeBSD, Windows, Linux or a broken lawnmower - best to tackle one thing at a time.

Don't worry about reporting NVMe issues etc. (well not in this thread).

Choose the system and the issue you want to tackle and start again.
 
Yes you are complicating things. I'm not any sort of guru either, but whether FreeBSD, Windows, Linux or a broken lawnmower - best to tackle one thing at a time.

Don't worry about reporting NVMe issues etc. (well not in this thread).

Choose the system and the issue you want to tackle and start again.
I agree - it's just that this system has been driving me crazy for about a week.
 
Huge progress, but very mysterious (to me).
Advice still needed - but I hope this helps someone.
Originally, I had a user called "usera" but after an update, the KDE screen froze, and "usera" would not get into KDE. Tried all sorts of stuff, but nothing worked.
However, after disabling SDDM and getting to a prompt, I was able to log in as root (and even run KDE as root).
I then tried many things to create additional users (adduser) but nothing seemed to work, and the kde login screens seemed to reject the passwords; even newly created passwords.
In most cases I created these users by including them in "wheel" but couldn't seem to add them to "video"
In desperation, I updated with "pkg upgrade" which downloaded a lot of stuff.
Still no dice.
Then I created a completely new user (usera) and pointed it at the file system of the original user that went bad.
sddm onestart didn't work, so I tried startx while in the usera directory.
And here we are.
I shamefully admit, I have no idea how any of this came about.
Apart from the above, everything seems to work except I have no audio - somehow the system failed to find the devices.

If anyone can shed some light on the above, I would be very grateful.
I still don't know how to return this system to using sddm, and of course there is the matter of the audio devices.

If I have a criticism, it is that the adduser utility needs more documentation, or some feedback when a window manager / whatever fails.
In my naivety, I assumed that adduser would create all the necessary functionality - but that doesn't seem the case.

I continue to search for explanations, and will update this if I find anything I think is of value.
Thanks to everyone who commented - I did try many of the ideas that the comments generated.
 
I have no idea how any of this came about.
It is very difficult to help when basically you did some random stuff that "didn't work" and you did some more random stuff in a bunch of areas and now it "does work".

Good on you for getting this far, but it is a very chaotic approach.

For example:

If I have a criticism, it is that the adduser utility needs more documentation, or some feedback when a window manager / whatever fails.

adduser is a shell script that adds users to a FreeBSD system.

That's nothing to do with GUIs, window managers, or KDE failing to "do something". So I'm not sure what needs to be added to the documentation for a shell script about KDE.

Good luck!
 
It is very difficult to help when basically you did some random stuff that "didn't work" and you did some more random stuff in a bunch of areas and now it "does work".

Good on you for getting this far, but it is a very chaotic approach.

For example:



adduser is a shell script that adds users to a FreeBSD system.

That's nothing to do with GUIs, window managers, or KDE failing to "do something". So I'm not sure what needs to be added to the documentation for a shell script about KDE.

Good luck!
Thanks for your very rapid reply.
When I do get further in my understanding, I'll post here.
BTW, I think you are being a little harsh.
In many cases, the KDE login scree just froze, in others passwords just set were rejected. There were no logs I could figure that could help me. In such cases, everyone resorts to trying everything again twice. Your comment about adduser may be valid, but to me, if the system allows a user to be created, then that user should be valid enough to allow a login, and if not a login a message with what's wrong. Otherwise, the time wasted will be huge.
I'm still puzzled with why startx allows KDE to start and smmd doesn't - and that in itself seems to have disabled my audio devices.
 
I now have the KDE desktop behaving itself, and it responds to sddm and allows me to log in as a user in the normal way.
I replaced the .xinitrc file in the user directory, with just one entry "exec ck-launch-session startplasma-X11" and that enabled almost all functionality at the KDE desktop.
But for people suffering similar issues, PLEASE WATCH OUT THE DEFAULT LOGIN SCREEN IS SET TO WAYLAND WHICH DOES NOT WORK. CHANGE IT TO PLASMA (or whatever it says).
I still have a problem in that although I have sound, I have no control from the KDE panel.
I don't like mysteries, so is it worth posting this issue as a separate question?
 
...
I still have a problem in that although I have sound, I have no control from the KDE panel.
...
Code:
# pkg install dsbmixer
 
Code:
# pkg install dsbmixer
Thanks, but didn't work. The curious thing is that the OS detects the devices, but KDE Plasma doesn't show them at all. Never experienced anything like this before - it must be a setting in KDE.
Thanks again.
 
Kmix not working. It seems that trying to run kmix, and as advised running
export $(dbus-launch)
I get:
Unable to set up transient service directory: XDG_RUNTIME_DIR "/var/run/user/1003" is owne
d by uid 1003, not our uid 0

That presumably means that I have a user / systems permissions problem.
If anyone can point me somewhere I can learn more, I'd be very grateful.
BTW, the confusion with UIDs probably comes from having to delete users that didn't work, and creating new users in the same name. Currently, id user gives
uid=1003(user) gid=1004(user) groups=1004(user),0(wheel),5(operator),44(video),1004(user)
but I must admit to not understanding what it all means.
As said, help gratefully received.
 
Are you running as root? I don’t use KDE or a GUI but that message is saying uid 0 (root) accessing a file owned by uid 1003 and it thinks that is a bad idea.
 
Are you running as root? I don’t use KDE or a GUI but that message is saying uid 0 (root) accessing a file owned by uid 1003 and it thinks that is a bad idea.
No, running as user. in the conventional fashion started by sddm.
However, this is a user I was forced to create after deleting the old user that worked for years, but which then locked me out of the system.
The only way I could find to recover was to delete the user that couldn't be mended, and create a new user pointing at the same user directory.
As you can see, my new user is a member of a number of groups (including your suggestion video) - but I really don't understand what it means.
Maybe there's a group called audio or something, but I haven't looked at that yet.
 
For those still interested in trying to recover from user being locked out by deleting the faulty user and recreating a new user pointing at the same user directory (using adduser).
It seems that the UID created for the new user doesn't necessarily allow running KDE (for example).
My original user had UID 1001 (I assume), but the new replacement user has been given the UID of 1003 - so I get a message like this from /var/log/auth.log:
_secure_path: /home/"user"/.login_conf is not owned by uid 1003

Is there some way of rectifying this? For my level of expertise (ha) it would be insane to try and manually adjust such things.
This issue apparently is the cause of the audio not working, and probably other things.
All information gratefully received. Thanks,
 
For those still interested in trying to recover from user being locked out by deleting the faulty user and recreating a new user pointing at the same user directory (using adduser).
It seems that the UID created for the new user doesn't necessarily allow running KDE (for example).
My original user had UID 1001 (I assume), but the new replacement user has been given the UID of 1003 - so I get a message like this from /var/log/auth.log:
_secure_path: /home/"user"/.login_conf is not owned by uid 1003

Is there some way of rectifying this? For my level of expertise (ha) it would be insane to try and manually adjust such things.
This issue apparently is the cause of the audio not working, and probably other things.
All information gratefully received. Thanks,
1. Back up the user's original files from user's home directory to a safer place, like the /tmp/ directory, /root/, or, probably safer still, a USB thumb drive.

2. Delete the user with uid = 1003, and it's private user group, which will probably have the same group id as user's user id.

3. If there another user account with uid = 1001, delete it and its group in similar fashion.

4. Create a new user and private group with uid = 1001 and gid = 1001.

5. Add the new user to the desired public groups, for example, group names wheel, video, and operator.

6. Restore the user's original files and directories to its new home directory.

Reference: pw()

Hint:
Code:
# cd /home; tar -czpf user.tgz user; mv user.tgz /root/ #--- back up offending user account's files and directories
# pw userdel -n user -u 1003 -r #--- delete the offending user account
# pw groupdel -n user -g 1003 #--- delete offending user account's group account
# pw userdel -n SomeOtherUserName -u 1001 #--- Only if found, delete any other user who might have uid = 1001.
# pw groupadd -n user -g 1001 #--- add back the group account, this time with the desired group id
# pw useradd -n user -u 1001 -c "Comment about user" -d /home/user -g user -m -s /bin/sh #--- add user account with same id no.
# pw groupmod wheel -m user #--- add user to wheel group
# pw groupmod video -m user #--- add user to video group
# pw groupmod operator -m user #--- add user to operator group
# cp /root/user.tgz /home/ ; rm -rf user ; tar -xzpf user.tgz #--- restore original files and directories to new user account
I haven't tested these commands lately, some of it may be a bit of overkill, and there are undoubtedly more elegant ways to go about this, but hopefully it will help you get back on the right track. It might only be necessary to add user to its private group and the wheel account. This is just a rough sledgehammer approach which probably doesn't check for everything which might possibly go wrong. Be careful. If I were doing this, I would test each command on some throw-away accounts before trying them out with the actual files and directories you're dealing with. Please don't put too much faith in me, my mouth is not a prayer book and I'm always in too much of a hurry. Remember, I'm just some anonymous and unaccountable dude on the internet who's trying to be helpful. If the damage is already very extensive, it may be faster just to reinstall and start from scratch with a clean system.
 
1. Back up the user's original files from user's home directory to a safer place, like the /tmp/ directory, /root/, or, probably safer still, a USB thumb drive.

2. Delete the user with uid = 1003, and it's private user group, which will probably have the same group id as user's user id.

3. If there another user account with uid = 1001, delete it and its group in similar fashion.

4. Create a new user and private group with uid = 1001 and gid = 1001.

5. Add the new user to the desired public groups, for example, group names wheel, video, and operator.

6. Restore the user's original files and directories to its new home directory.

Reference: pw()

Hint:
Code:
# cd /home; tar -czpf user.tgz user; mv user.tgz /root/ #--- back up offending user account's files and directories
# pw userdel -n user -u 1003 -r #--- delete the offending user account
# pw groupdel -n user -g 1003 #--- delete offending user account's group account
# pw userdel -n SomeOtherUserName -u 1001 #--- Only if found, delete any other user who might have uid = 1001.
# pw groupadd -n user -g 1001 #--- add back the group account, this time with the desired group id
# pw useradd -n user -u 1001 -c "Comment about user" -d /home/user -g user -m -s /bin/sh #--- add user account with same id no.
# pw groupmod wheel -m user #--- add user to wheel group
# pw groupmod video -m user #--- add user to video group
# pw groupmod operator -m user #--- add user to operator group
# cp /root/user.tgz /home/ ; rm -rf user ; tar -xzpf user.tgz #--- restore original files and directories to new user account
I haven't tested these commands lately, some of it may be a bit of overkill, and there are undoubtedly more elegant ways to go about this, but hopefully it will help you get back on the right track. It might only be necessary to add user to its private group and the wheel account. This is just a rough sledgehammer approach which probably doesn't check for everything which might possibly go wrong. Be careful. If I were doing this, I would test each command on some throw-away accounts before trying them out with the actual files and directories you're dealing with. Please don't put too much faith in me, my mouth is not a prayer book and I'm always in too much of a hurry. Remember, I'm just some anonymous and unaccountable dude on the internet who's trying to be helpful. If the damage is already very extensive, it may be faster just to reinstall and start from scratch with a clean system.
Thanks, will try over the next few days (have to be clear-headed).
 
Back
Top