Comment 16 for bug 1624268

Hi,
I think this bug still occurs, at least on Debian testing (buster) with sddm 0.18.
I posted an analysis and a workaround on the following github issue, although already closed: https://github.com/sddm/sddm/issues/637#issuecomment-453838344

tl;dr:
There is an issue in /etc/pam.d/sddm-greeter, that calls pam_mount through '@include common-session'.
pam_mount will surely fail, as it is called for the local user sddm, which has probably no access right to the given shared volume.

What is not normal, maybe, is that sddm will then catch a SIGTERM and so will terminate.
The same kind of pam_mount failures occurs with /etc/pam.d/login (eg with user root), and login can proceed correctly.
Why is this a blocking issue when processed by /etc/pam.d/sddm-greeter?

I could imagine the following solutions:
  - modify the /etc/pam.d/sddm-greeter file, either by:
    - replacing the '@include common-session' statement by the actual directives in /etc/pam.d/common-session, EXCEPT the one with pam_mount. This is the workaround proposed by another user on github. It works, but I don't find it very clean, to be honest.
    - replacing the '@include common-session' statement with a substack, with some conditions? I'm not an expert with PAM, I don't know if this is even feasible?
  - do not terminate on a SIGTERM send by pam_mount? Is it feasible, too?
  - apply the workaround I propose: use the pam_mount extended user control features, to exclude the sddm user from trying to mount the volume. We can explicitly exclude this user, or a whole range (all local users for example).

Hope you will find this useful !

Cheers