Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   presumably an apt upgrade

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
     set permissions on file .config/user-dirs.dirs 0700 and owned by
     myself

   * What was the outcome of this action?
   able to log in again as normal

   * What outcome did you expect instead?
   able to log in without changing automatically set permisisons

*** End of the template - remove these template lines ***

more details:
=============
after what seemed like a hung xserver (nouveau) while watching a video a
reboot was performed.
after this reboot was unable to log in as my normal user. however after
some experimentation i found that if i made a new user i was able to log
in as before with this new user (but still not with the old/normal user).
this gave me reason to investigate the user config files
and eventually i narrowed it down to the file .config/user-dirs.dirs --
if it was present in the old/normal account i could not log in. i then
realized that the
permissions on that file were different (now owned by root) than the
permissions in the new user
account that i had made (owned by new user). once i changed the permissions in the old
account to be owned by that user the problem disappeared and i was able
to log in properly again.

i am guessing that at some point the program 'xdg-user-dirs-update'
modified the permissions perhaps, because the top of the .config/user-dirs.dirs file says:
# This file is written by xdg-user-dirs-update

there was no relevant debugging info that i could find in dmesg, syslog,
or journalctl. only related messages seemed to point to pam closing the
session for no reason.

one last bit of perhaps relevant info: for some time before this issue,
two things have been happening on this machine that are odd and
noteworthy. one is the aforementioned xserver hang. this seems to happen
when watching youtube videos. the computer continues to work, but the
mouse pointer slows down rapidly until it won't move any longer. the audio
continues in the video however, and i can switch to a non-x terminal and
observe that the machine is reletively unloaded.

the second odd piece of info is that also for some time (2 weeks
estimate) when logging in with the regular user or with a newly created
one, if the wrong password is input, sddm and/or lightdm quickly reshows
the login screen. however if the correct password is input the session
hangs for what looks like exactly 2 minutes, before displaying the
desktop session. during this time i am able to switch to a terminal and
use the computer without x.

hope some of this helps!

i would like to make two corrections to this report:

where i wrote
   * What led up to the situation?
   presumably an apt upgrade

this is incorrect. not a apt upgrade issue, but x hanging and a subsequent
reboot (possibly hard reboot -- can't recall at this moment) let up to it.

------------

where i wrote:
[... and i can switch to a non-x terminal and
observe that the machine is reletively unloaded....]

this is incorrect. i CAN switch to a terminal, but the x-hang/stuck screen
does not disappear. i can perform commands in the terminal blindly such as
killall firefox-esr
(which does seem to kill firefox, as the audio then stops) but
the hung x-screen remains until a reboot.

-----------

when the screen seems hung during the login/sddm problem described i AM
able to work in a non-x terminal however, so that part is correct.

apologies for the confusion. i think the x problem and sddm problem are
unlikely to be related anyway, but i include them here just in case, for
completeness.