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
