I think anything which causes gvfs to start "early enough" (before gnome-session has a chance to upload the environment to systemd) will trigger this problem.
So anything which starts from e.g. default.target, or maybe there are things like ibus which are started outside of systemd's control.
I did a little bit of investigation on the upstream bug, and I think what is happening is that we don't run pam_sss for systemd-user sessions - it's not in /etc/pam.d/systemd-user or included in there e.g. via common-session-noninteractive. That means that when the session starts `systemd --user`, in its own `systemd-user` PAM session, the env var is not instantiated there and so it's not available to stuff that starts really early. Early - but not early enough - in the startup process, gnome-session uploads environment variables into the systemd environment. Anything which starts after that will get the right environment. In other words this is a race condition.
Can someone experiencing this bug please undo all of the workarounds applied, and then try adding "session optional pam_sss.so" into /etc/pam.d/systemd-user just above the `pam_systemd.so` line? And then check that KRB5CCNAME is set in gvfsd's environment.
I don't have an environment to fully test this so I was just able to do it with a hack, but it worked that far for me.
I think anything which causes gvfs to start "early enough" (before gnome-session has a chance to upload the environment to systemd) will trigger this problem.
So anything which starts from e.g. default.target, or maybe there are things like ibus which are started outside of systemd's control.
I did a little bit of investigation on the upstream bug, and I think what is happening is that we don't run pam_sss for systemd-user sessions - it's not in /etc/pam. d/systemd- user or included in there e.g. via common- session- noninteractive. That means that when the session starts `systemd --user`, in its own `systemd-user` PAM session, the env var is not instantiated there and so it's not available to stuff that starts really early. Early - but not early enough - in the startup process, gnome-session uploads environment variables into the systemd environment. Anything which starts after that will get the right environment. In other words this is a race condition.
Can someone experiencing this bug please undo all of the workarounds applied, and then try adding "session optional pam_sss.so" into /etc/pam. d/systemd- user just above the `pam_systemd.so` line? And then check that KRB5CCNAME is set in gvfsd's environment.
I don't have an environment to fully test this so I was just able to do it with a hack, but it worked that far for me.