I see the same problem with Ubuntu 20.04 and 22.04, inside an Active Directory domain. With slow machines (e.g. with rotational hard disks) it is always present; with fast machines (with SSDs) it is randomly present, maybe because it depends also on the time needed to contact the domain controller.
(I'm using a cinnamon desktop and I do not have ibus installed) I have applied the following workaround: copy /usr/lib/systemd/user/gvfs-daemon.service to /etc/systemd/user/gvfs-daemon.service insert in the last file the following line, at the start of the [Service] section: ExecStartPre=bash -c "for i in echo {1..20} ; do if [ $(env | grep KRB5CCNAME) == "" ]; then sleep 0.2 ; fi ; done" In this way it is possible to browse the network with Nemo or Nautilus, without asking for user authentication. When the workaround is not present I see this message in /var/log/syslog: Mar 30 10:30:36 pc000327 gvfsd[2656]: got no contact to IPC$ Mar 30 10:30:39 pc000327 gvfsd[2672]: Kerberos auth with 'aduser@WORKGROUP' (WORKGROUP\aduser) to access '10.1.0.107' not possible (Here kerberos is not aware of the real domain name and tries the generic WORKGROUP) I report here also the relevant processes in the case of no workaround: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ... root 977 0.0 0.4 78692 19508 ? Ss 12:52 0:00 /usr/sbin/winbindd --foreground --no-process-group root 985 0.0 0.2 78596 11168 ? S 12:52 0:00 winbindd: domain child [PC000327] root 989 0.1 0.7 105008 28716 ? Ss 12:52 0:00 /usr/sbin/smbd --foreground --no-process-group root 990 0.0 0.4 79840 17180 ? S 12:52 0:00 winbindd: domain child [DOMAIN] root 994 0.0 0.4 80464 16344 ? S 12:52 0:00 winbindd: idmap child root 1002 0.0 0.5 97132 20524 ? S 12:52 0:00 /usr/lib/x86_64-linux-gnu/samba/samba-bgqd --ready-signal-fd=48 --parent-watch-fd=12 --debuglevel=0 -F root 1014 1.2 2.5 153464 99180 ? S 12:52 0:01 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files root 1015 0.0 0.3 98056 14612 ? S 12:52 0:00 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files root 1021 0.1 0.2 57304 8144 ? Ss 12:52 0:00 /lib/systemd/systemd-logind root 1121 15.2 2.7 272756 108420 ? S 12:52 0:18 /usr/libexec/sssd/sssd_be --domain addomain.it --uid 0 --gid 0 --logger=files root 1213 0.0 0.2 190492 11168 ? Sl 12:53 0:00 lightdm --session-child 12 19 root 1271 0.0 0.4 138968 16544 ? Ss 12:53 0:00 /usr/libexec/sssd/sssd_pac --logger=files --socket-activated aduser 1279 0.5 0.2 17388 10136 ? Ss 12:53 0:00 /lib/systemd/systemd --user aduser 1292 0.6 0.1 29736 5824 ? Ss 12:53 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only aduser 1294 0.0 0.1 241124 7680 ? Sl 12:53 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login aduser 1298 0.1 0.2 240844 8672 ? Ssl 12:53 0:00 /usr/libexec/gvfsd aduser 1305 0.0 0.1 380884 7012 ? Sl 12:53 0:00 /usr/libexec/gvfsd-fuse /run/user/1136602666/gvfs -f aduser 1314 0.6 0.6 376912 27500 ? Ssl 12:53 0:00 cinnamon-session --session cinnamon aduser 1326 1.5 0.6 707460 26600 ? SNsl 12:53 0:00 /usr/libexec/tracker-miner-fs-3 aduser 1372 0.0 0.2 325748 10224 ? Ssl 12:53 0:00 /usr/libexec/gvfs-udisks2-volume-monitor and when the workaround is present: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ... root 873 0.4 2.5 153440 98936 ? S 12:43 0:01 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files root 874 0.0 0.3 98068 14344 ? S 12:43 0:00 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files root 885 0.0 0.3 70704 15060 ? Ss 12:43 0:00 /usr/sbin/nmbd --foreground --no-process-group root 973 0.0 0.4 78692 19632 ? Ss 12:43 0:00 /usr/sbin/winbindd --foreground --no-process-group root 981 0.0 0.2 78596 11108 ? S 12:43 0:00 winbindd: domain child [PC000327] root 982 0.0 0.4 79844 17164 ? S 12:43 0:00 winbindd: domain child [DOMAIN] root 986 0.0 0.7 105008 28736 ? Ss 12:43 0:00 /usr/sbin/smbd --foreground --no-process-group root 1001 0.0 0.4 80464 16344 ? S 12:43 0:00 winbindd: idmap child root 1004 0.0 0.5 97132 20376 ? S 12:43 0:00 /usr/lib/x86_64-linux-gnu/samba/samba-bgqd --ready-signal-fd=48 --parent-watch-fd=12 --debuglevel=0 -F root 1010 0.0 0.2 249880 8900 ? Ssl 12:43 0:00 /usr/libexec/accounts-daemon root 1013 0.0 0.2 57312 7968 ? Ss 12:43 0:00 /lib/systemd/systemd-logind root 1297 0.0 0.2 190448 11264 ? Sl 12:44 0:00 lightdm --session-child 12 19 root 1336 7.3 2.7 272260 106544 ? S 12:44 0:21 /usr/libexec/sssd/sssd_be --domain addomain.it --uid 0 --gid 0 --logger=files root 1349 0.0 0.4 138968 16868 ? Ss 12:45 0:00 /usr/libexec/sssd/sssd_pac --logger=files --socket-activated aduser 1357 0.1 0.2 17384 10152 ? Ss 12:45 0:00 /lib/systemd/systemd --user aduser 1370 0.1 0.1 29728 5880 ? Ss 12:45 0:00 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only aduser 1372 0.0 0.2 241096 7968 ? Sl 12:45 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login aduser 1383 0.2 0.6 377016 27412 ? Ssl 12:45 0:00 cinnamon-session --session cinnamon aduser 1651 0.0 0.2 240848 8636 ? Ssl 12:45 0:00 /usr/libexec/gvfsd aduser 1656 0.0 0.1 455668 6784 ? Sl 12:45 0:00 /usr/libexec/gvfsd-fuse /run/user/1136602666/gvfs -f The difference that I can see is that in the first case gvfsd is started before cinnamon-session, while in the latter case gvfsd is started after cinnamon-session. -- 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 : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp