This bug was fixed in the package tracker-miners - 3.4.3-1ubuntu1
---
tracker-miners (3.4.3-1ubuntu1) lunar; urgency=medium
[ Denison Barbosa ]
* debian/patches/ubuntu-fix-tracker-extract-start-order.patch:
Fix tracker-extract.service WantedBy target so that gvfsd has
acce
** Package changed: gvfs (Ubuntu) => tracker-miners (Ubuntu)
** Changed in: tracker-miners (Ubuntu)
Assignee: (unassigned) => Denison Barbosa (justdenis)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.l
So, I was investigating this issue for a while and after some debugging of
journalctl --user and dbus, it's possible to see that the gvfs-daemon.service
was being started too early due to another tracker:
"tracker-extract-3.service", which has WantedBy=default.target. This default
value of defa
Hi Sergio,
I tried your workaround, but the KRB5CCNAME environment variable is not
set, because I don't use krb5-user and libpam-krb5. In my case the
authentication is made by sssd-krb5 and the kerberos ticket is stored in
/tmp/krb5cc_...
--
You received this bug notification because you are a m
I found something odd... Setting KRB5CCNAME in /etc/environment does
work, but setting "default_ccache_name" in /etc/krb5.conf doesn't. In
theory, when KRB5CCNAME isn't set, kerberos should use that value for
the cache file. And although the command line tools do use it, it seems
that gvfsd doesn't
If you try my line, be sure to create the folder ~/kerberos before, so
maybe a better alternative would be the line
KRB5CCNAME=${HOME}/.config/krb5cc_${LOGNAME}
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://
I found a workaround for this: to define the KRB5CCNAME environment
variable at /etc/environment.d/91kerberos.conf
In my case, I store the cache file at ~/kerberos, so I set the content
of that file to:
KRB5CCNAME=${HOME}/kerberos/krb5cc_${LOGNAME}
So, if my username is "username", this resu
** Tags added: dt-798
--
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:
New
Stat
Is this bug still being worked on? I'm running into the issue. Took me a
couple of days before I found this bug here. I've applied the workaround
from Val (vk1266) listed on 2020-05-28 and that works, problem is not
visible anymore.
Can I be of assistance in anyway? Have an environment where I can
** Changed in: gvfs
Status: Unknown => New
--
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
Hi renbag,
Thanks for attaching your smb.conf and sssd.conf, I will try add them
into my reproducer and see if I get closer to seeing the problem.
Maybe when you log in, smbd mounts the samba shares to
/home/aduser/{Public},{Shared} before kerberos manages to acquire a new
ticket and place it in
I tried this to check if the problem is really the slow writing of the
kerberos ticket to the disk:
disable the workaround in /etc/systemd/user/gvfs-daemon.service
reboot the slow machine
connect to the slow machine with ssh as "aduser" (a kerberos ticket is acquired
and written to /tmp/krb5cc_11
** Attachment added: "AD_installed_packages.txt"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575198/+files/AD_installed_packages.txt
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://
** Attachment added: "smb.conf"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575197/+files/smb.conf
--
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
T
** Attachment added: "sssd.conf"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575196/+files/sssd.conf
--
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
** Attachment added: "1641_environ_slow-machine_with-workaround.txt"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575194/+files/1641_environ_slow-machine_with-workaround.txt
--
You received this bug notification because you are a member of Desktop
Packages, which i
** Attachment added: "1274_environ_slow-machine_no-workaround.txt"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575192/+files/1274_environ_slow-machine_no-workaround.txt
--
You received this bug notification because you are a member of Desktop
Packages, which is su
** Attachment added: "psauxf_slow-machine-with-workaroud.txt"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575193/+files/psauxf_slow-machine-with-workaroud.txt
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed t
** Attachment added: "psauxf_fast-machine-no-workaroud.txt"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575195/+files/psauxf_fast-machine-no-workaroud.txt
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gv
Hi Matthew,
I report the complete configuration of the machine in which I see the problem.
The machine is an Optiplex 745, with an Intel Core2 6320 CPU, 4 GB RAM and a
rotational HD, which I use as a test box for Ubuntu 22.04.
It was joined to an AD domain with the "net ads join -U aduser" comman
** Attachment added: "psauxf_slow-machine-no-workaroud.txt"
https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1779890/+attachment/5575188/+files/psauxf_slow-machine-no-workaroud.txt
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gv
Hi everyone, Fady, renbag,
I have been working on this bug on and off for a little while now, but I
am stuck because I can't reproduce what you are all seeing. Having a
reproducer will greatly speed up getting a fix created for this issue.
In my client gvfsd is always started via systemd --user,
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 controll
> It's being D-Bus activated by things early in the startup of the
> session. By disabling tracker or whatever you are stopping that D-Bus
> activation.
Indeed, i've seen that. But i actually intended to say tracker, not
gvfs.
I see little point in starting tracker before gnome-session. But i'm
p
On Tue, Nov 17, 2020 at 07:50:20AM -, Julien Blanc wrote:
> Same issue here.
>
> gvfsd is started by tracker-miner-fs. Disabling it made it work (note
> that i also made the /etc/pam/systemd-user pam_sss change), ie gvfsd now
> correctly has access to the kerberos token.
>
> I'm wondering why
Same issue here.
gvfsd is started by tracker-miner-fs. Disabling it made it work (note
that i also made the /etc/pam/systemd-user pam_sss change), ie gvfsd now
correctly has access to the kerberos token.
I'm wondering why gvfsd is started by systemd-user and not gnome-
session. Changing that may
I think maybe sssd needs to learn how to set the environment in
"session" mode. I did ask some people at Canonical who know about this
project, hopefully they will have some advice soon. :)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to
@laney: I have disabled all my workarounds and placed "session optional
pam_sss.so" just before "session optional pam_systemd.so" in
/etc/pam.d/systemd-user on my Ubuntu 18.04.5 system. Checking
"journalctl --user" for gfvs-daemon entries:
Nov 02 22:45:31 vk2011 dbus-daemon[6128]: [session uid=
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 d
I do not have tracker-miner-fs.service at all. My instance of gvfsd is
started by either ibus-daemon, or "systemd --user". Please see the
controversy at
https://gitlab.gnome.org/GNOME/gvfs/-/issues/481#note_948506
--
You received this bug notification because you are a member of Desktop
Packages,
The upstream bug got reopened now, could you try disabling the tracker
service and see if it resolves the issue for you?
--
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:
Nau
** Changed in: gvfs (Ubuntu)
Importance: Low => High
** Tags added: desktop-lts-wishlist focal
--
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 v
The upstream determined that gvfsd as a systemd user session is starting
too early in Ubuntu, before the desktop enviroment variables are set.
Specifically, KRB5CCNAME env var is missing at the time gvfsd is
started, causing this bug. See the detailed report at
ttps://gitlab.gnome.org/GNOME/gvfs/-/
Thanks for reporting the issue upstream
** Changed in: gvfs (Ubuntu)
Importance: Undecided => Low
** Changed in: gvfs (Ubuntu)
Status: Confirmed => Triaged
** Also affects: gvfs via
https://gitlab.gnome.org/GNOME/gvfs/-/issues/481
Importance: Unknown
Status: Unknown
--
Y
The problem persists in Ubuntu 20.04 as well.
I attempted to investigate this issue a little further, found that it is
caused by a race condition between gvfsd and ibus-daemon, and filed a
bug report upstream: https://gitlab.gnome.org/GNOME/gvfs/-/issues/481
My current workaround is hack, but it
As far as I know this problem comes from ubuntu 12.04 and still not resolved.
Kerberos now works in ubuntu 18.04.
This is ubuntu specific bug. Nautilus in Centos 7.x and 8 works fine with
kerberos
--
You received this bug notification because you are a member of Desktop
Packages, which is subs
Happens on Ubuntu 19.04 too.
--
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 pack
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: gvfs (Ubuntu)
Status: New => Confirmed
--
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
T
38 matches
Mail list logo