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. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gvfs in Ubuntu. https://bugs.launchpad.net/bugs/1779890 Title: Nautilus does not use a valid Kerberos ticket when accessing Samba share Status in gvfs: Unknown Status in gvfs package in Ubuntu: Triaged Bug description: Nautilus prompts for username and password when accessing a Samba share on a network drive, despite having a perfectly valid unexpired Kerberos ticket. The Kerberos ticket is obtained automatically at logon by authentication against a Samba Active Directory server (Samba AD-DC). Accessing the same Samba share with the same Kerberos ticket via "smbclient //host/sharename -k" works fine. One known workaround is: "nautilus -q", and then "killall gvfsd". After that, accessing the Samba share with Nautilus works normally as it should. I did not experience this issue in Ubuntu 16.04. It appears that a regression was introduced somewhere between 16.04 and 18.04. The issue is quite annoying and confusing for the users who are used to accessing Samba shares on the network drive without being prompted for their username and password. The issue appears to manifest itself usually not on the first access to a Samba share, but on subsequent accesses after a system reboot or upon user logout/login. Strangely, removing ~/.cache/ibus/bus/registry file before user login appears to fix the issue for the current user session, but then the problem reappears upon subsequent user logins or after a system reboot. Nemo appears to have the same problem as Nautilus. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gvfs-daemons 1.36.1-0ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-24.26-generic 4.15.18 Uname: Linux 4.15.0-24-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu7.2 Architecture: amd64 Date: Tue Jul 3 11:12:06 2018 ExecutablePath: /usr/lib/gvfs/gvfsd InstallationDate: Installed on 2018-04-27 (66 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) ProcEnviron: LANG=en_CA.UTF-8 PATH=(custom, no user) SHELL=/bin/bash XDG_RUNTIME_DIR=<set> SourcePackage: gvfs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gvfs/+bug/1779890/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
