1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1101025: gvfs-fuse: gvfsd-fuse daemon refuses to start

    From Vladimir K@21:1/5 to All on Sat Mar 22 08:20:01 2025
    Package: gvfs-fuse
    Version: 1.57.2-1+b1
    Severity: important

    Dear Maintainer, /usr/libexec/gvfsd-fuse refuses to start, leaving filesystems accessed via gvfs without real mountpoint representation.

    Error message as reported by gvfsd:

    gvfsd[3623]: fuse: both 'want' and 'want_ext' are set

    Same with manual start:

    $ /usr/libexec/gvfsd-fuse -f /run/user/1000/gvfs
    fuse: both 'want' and 'want_ext' are set

    /run/user/1000/gvfs is not mounted as a result.

    -- System Information:
    Debian Release: trixie/sid
    APT prefers unstable
    APT policy: (500, 'unstable'), (200, 'experimental')
    Architecture: amd64 (x86_64)
    Foreign Architectures: i386

    Kernel: Linux 6.12.19-amd64 (SMP w/14 CPU threads; PREEMPT)
    Kernel taint flags: TAINT_USER
    Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
    Shell: /bin/sh linked to /usr/bin/dash
    Init: systemd (via /run/systemd/system)
    LSM: AppArmor: enabled

    Versions of packages gvfs-fuse depends on:
    ii fuse3 3.17.1~rc1-3
    ii gvfs 1.57.2-1+b1
    ii libc6 2.41-6
    ii libfuse3-4 3.17.1~rc1-3
    ii libglib2.0-0t64 2.84.0-2

    gvfs-fuse recommends no packages.

    gvfs-fuse suggests no packages.

    -- no debconf information

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jens Yllman@21:1/5 to All on Sat Mar 22 12:10:02 2025
    Hi,

    I believe this is related to #1100487, and that it if gvfs-fuse that is
    what really is failing.

    Jens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jens Yllman@21:1/5 to jens@yllman.se on Sat Mar 22 12:20:01 2025
    Hi,

    I also wonder why we who have this problem have version 1.57.2-1+b1 when
    the official sites like PTS and Salsa have no list of that version. And
    there is no way to see what is changed.

    Jens

    On Sat, 22 Mar 2025 11:48:52 +0100 Jens Yllman <jens@yllman.se> wrote:
    Hi,

    I believe this is related to #1100487, and that it if gvfs-fuse that is
    what really is failing.

    Jens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jens Yllman@21:1/5 to jeremy.bicha@canonical.com on Sat Mar 22 13:00:01 2025
    On Sat, 22 Mar 2025 07:32:58 -0400 =?UTF-8?Q?Jeremy_B=C3=ADcha?= <jeremy.bicha@canonical.com> wrote:
    Control: severity -1 serious
    Control: affects -1 src:fuse3

    On Sat, Mar 22, 2025 at 7:15 AM Jens Yllman <jens@yllman.se> wrote:
    I also wonder why we who have this problem have version 1.57.2-1+b1 when the official sites like PTS and Salsa have no list of that version. And there is no way to see what is changed.

    One major difference is that 1.57.2-1+b1 was built against fuse
    3.17.1~rc1 instead of fuse 3.14.

    Would you be interested in reporting this issue to the gvfs
    maintainers upstream at https://gitlab.gnome.org/GNOME/gvfs/-/issues ?

    There is already an issue reported on fuse, https://github.com/libfuse/libfuse/issues/1171.

    So, the question is fuse doing this wrong or is gvfs-fuse doing it wrong?

    Jens

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw@21:1/5 to jeremy.bicha@canonical.com on Sat Mar 22 13:40:01 2025
    Hi,

    On Sat, Mar 22, 2025 at 1:06 PM Jeremy Bícha <jeremy.bicha@canonical.com> wrote:
    On Sat, Mar 22, 2025 at 7:51 AM Jens Yllman <jens@yllman.se> wrote:
    So, the question is fuse doing this wrong or is gvfs-fuse doing it wrong?

    I don't know. Someone should report the issue to the gvfs maintainers also.
    Quick check done. It seems in the past FUSE capabilities were a 32
    bit bitfield. It was moved to a 64 bit struct, causing an ABI break.
    It was handled by the SONAME bump and more importantly the FUSE helper functions started to use the new bitfield. See the mentioned bitfield
    comments [1][2] in the FUSE header. Both say use the FUSE helper
    functions fuse_set_feature_flag() and fuse_unset_feature_flag()
    instead of accessing internal parts directly.
    But then gvfs (even the one in Trixie / Sid) manipulates the old 32
    bit bitfield directly [3] (and at other places). Meaning it is a gvfs
    bug, a proposed fix is already provided [4].
    In very short, gvfs needs to be fixed. I can't do anything on the FUSE side.

    Regards,
    Laszlo/GCS
    [1] https://github.com/libfuse/libfuse/blob/fuse-3.17.x/include/fuse_common.h#L596
    [2] https://github.com/libfuse/libfuse/blob/fuse-3.17.x/include/fuse_common.h#L699
    [3] https://gitlab.gnome.org/GNOME/gvfs/-/blob/1.57.2/client/gvfsfusedaemon.c?ref_type=tags#L2478
    [4] https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/248/diffs?commit_id=77581bc426025bd04bd7ccb3b61e9c20114bc44b

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Simon McVittie@21:1/5 to All on Sat Mar 22 16:40:01 2025
    On Sat, 22 Mar 2025 at 13:34:36 +0100, László Böszörményi (GCS) wrote:
    Quick check done. It seems in the past FUSE capabilities were a 32
    bit bitfield. It was moved to a 64 bit struct, causing an ABI break.
    It was handled by the SONAME bump and more importantly the FUSE helper >functions started to use the new bitfield. See the mentioned bitfield >comments [1][2] in the FUSE header. Both say use the FUSE helper
    functions fuse_set_feature_flag() and fuse_unset_feature_flag()
    instead of accessing internal parts directly.
    But then gvfs (even the one in Trixie / Sid) manipulates the old 32
    bit bitfield directly [3] (and at other places). Meaning it is a gvfs
    bug, a proposed fix is already provided [4].
    In very short, gvfs needs to be fixed. I can't do anything on the FUSE side

    I think your footnotes have got lost?

    Is [4] perhaps meant to point to commit "fuse: use
    fuse_(un)set_feature_flag instead of setting manually" from <https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/248>?

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw@21:1/5 to smcv@debian.org on Sat Mar 22 16:50:01 2025
    On Sat, Mar 22, 2025 at 4:27 PM Simon McVittie <smcv@debian.org> wrote:
    I think your footnotes have got lost?
    I don't know if it was lost or not. It's in the bug log at least: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101025#39

    Is [4] perhaps meant to point to commit "fuse: use
    fuse_(un)set_feature_flag instead of setting manually" from <https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/248>?
    Yes, exactly commit 77581bc4 which can be viewed only at: https://gitlab.gnome.org/GNOME/gvfs/-/commit/77581bc426025bd04bd7ccb3b61e9c20114bc44b?merge_request_iid=248

    Laszlo/GCS

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Jeremy_B=C3=ADcha?=@21:1/5 to All on Mon Mar 24 12:20:01 2025
    https://github.com/libfuse/libfuse/pull/1172 was merged upstream.

    Thank you,
    Jeremy Bícha

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)