Find out how to get gfvs to work

[probonopd]

Filer right now relies on gvfs for computer://, network:// and other things. (Is this a good thing? Hell No!)

In any case, it currently does not work on the Live ISO:

liveuser@furybsd:~ % pkill gvfs
[liveuser@furybsd ~]$ GVFS_DEBUG=1 /usr/local/libexec/gvfsd --replace 2>&1 | tee gvfsd.log
fuse: failed to open fuse device: No such file or directory

[probonopd]

[liveuser@furybsd ~]$ sudo kldload fuse.ko
[liveuser@furybsd ~]$ GVFS_DEBUG=1 /usr/local/libexec/gvfsd --replace 2>&1 | tee gvfsd.log
mount_fusefs: /dev/fuse on /usr/home/liveuser/.cache/gvfs: Operation not permitted

Why is this?

[liveuser@furybsd ~]$ GVFS_DEBUG=1 /usr/local/libexec/gvfsd --replace 2>&1 | tee gvfsd.log
mount_fusefs: /dev/fuse on /usr/home/liveuser/.cache/gvfs: Operation not permitted

Why?

[probonopd]

[liveuser@furybsd ~]$ sudo sysctl vfs.usermount=1
vfs.usermount: 0 -> 1

[liveuser@furybsd ~]$ GVFS_DEBUG=1 /usr/local/libexec/gvfsd --replace -d

(process:87460): GLib-GObject-CRITICAL **: 19:11:22.555: g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed

(process:87460): GLib-GIO-CRITICAL **: 19:11:22.556: g_volume_monitor_get_mounts: assertion 'G_IS_VOLUME_MONITOR (volume_monitor)' failed

(process:87460): GLib-GObject-WARNING **: 19:11:22.556: invalid (NULL) pointer instance

(process:87460): GLib-GObject-CRITICAL **: 19:11:22.556: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(process:87460): GLib-GObject-WARNING **: 19:11:22.556: invalid (NULL) pointer instance

(process:87460): GLib-GObject-CRITICAL **: 19:11:22.556: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

Still not good.

[probonopd]

According to https://wiki.gnome.org/Projects/gvfs/doc gvfs is highly complex, convoluted (multiple daemons, talking over D-Bus etc.) and deeply rooted in Gnome tech. We should get rid of it yesterday.

There is no clear howto on how to use it without Gnome.

Can't they make something like gfvs in one single binary that "just works" with zero configuration?

[probonopd]

On a system on which it is working, we somehow magically(?) have many gvfs related processes running:

user@FreeBSD$ ps ax | grep vfs
 2514  -  I      0:00,05 /usr/local/libexec/gvfsd                                                                                                                                             
 2516  -  I      0:01,41 /usr/local/libexec/gvfsd-fuse /var/run/user/1001/gvfs -f -o big_writes                                                                                               
 2520  -  I      0:00,01 /usr/local/libexec/gvfs-hal-volume-monitor                                                                                                                           
 2522  -  S      0:04,30 /usr/local/libexec/gvfsd-trash --spawner :1.7 /org/gtk/gvfs/exec_spaw/0                                                                                              
 2524  -  I      0:00,01 /usr/local/libexec/gvfs-gphoto2-volume-monitor                                                                                                                       
21449  -  I      0:00,10 /usr/local/libexec/gvfsd-metadata                                                                                                                                    
97269  -  I      0:00,28 /usr/local/libexec/gvfsd-network --spawner :1.7 /org/gtk/gvfs/exec_spaw/1                                                                                            
97280  -  I      0:00,28 /usr/local/libexec/gvfsd-dnssd --spawner :1.7 /org/gtk/gvfs/exec_spaw/5  

What is supposed to be launching them?

[probonopd]

Why does this all have be so convoluted. gfvs stuff all over the place, and tying in lots of the Red Hat stack including PolicyKit and D-Bus and whatnot. And like with all of those, if you look closely enough, you see that they are basically written for Gnome, and for Gnome first and foremost.

/usr/local/share/dbus-1/services
/usr/local/share/polkit-1/actions
/usr/local/share/gvfs/mounts
/usr/local/share/glib-2.0/schemas/org.gnome.system.gvfs.enums.xml
/usr/local/share/glib-2.0/schemas/org.gnome.system.dns_sd.gschema.xml

It would probably be quicker to throw out gfvs and use a combination of fuse-sshfs and Zeroconf to achieve a simiilar thing...

[probonopd]

https://askubuntu.com/questions/31468/who-is-calling-gvfsd-and-when implies that the various gvfs processes get started by D-Bus activation.

Which means that we don't have to start it manually, but something automatically starts it when "needed".

And indeed, if I kill all of those processes, and then click on "Network" in Filer, they get "magically" restarted. dbus-monitor shows:

method call time=1604090014.481298 sender=:1.6 -> destination=org.freedesktop.DBus serial=58 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=StartServiceByName
   string "org.gtk.vfs.Daemon"
   uint32 0

Who is sender=:1.6? Why can't dbus-monitor clearly say which process is sending which message to which process.

This does not happen on the system where it is not working.

So, what is sending that StartServiceByName message?

Is this whole thing documented somewhere in straightforward terms?

[probonopd]

On the system where it is working:

user@FreeBSD$ echo $DBUS_SESSION_BUS_ADDRESS
unix:path=/tmp/dbus-IyiTunw6Q0,guid=...

On the system where it is not working, this environment variable is unset.

Boy is this stuff overly complicated!

[probonopd]

...and indeed, looks like this D-Bus activation stuff comes from someone who had been working for Red Hat from Aug 2004 to Jan 2013... D-Bus activation came in 2006... am I really surprised?

[probonopd]

https://wiki.gnome.org/Projects/gvfs/doc just says

Everything is autostarted on-demand on first access through GIO. No need to start any daemon explicitly. Some mounts may require credentials, this is done using standard GMountOperation object.

...except when it is not working. Why?

DBUS_SESSION_BUS_ADDRESS - if unset, gvfs will refuse to load to prevent spawning private bus

So us not having a DBUS_SESSION_BUS_ADDRESS environment variable may be part of the issue. Where is this environment variable supposed to be coming from?

Maybe we need

# Start D-Bus and export DBUS_SESSION_BUS_ADDRESS
export $(dbus-launch)

as part of our desktop start script?

YES.

https://lists.gnu.org/archive/html/guix-devel/2018-08/msg00003.html confirms this.

Hardly surprising that one gets pointed in the direction of systemd when one searches about where $DBUS_SESSION_BUS_ADDRESS is supposed to come from. You use one Red Hat component, you go down the rabbit hole of ending up with a stack that resembles... Gnome on Fedora.

[probonopd]

Note that Network discovery apparently requires avahi-daemon to be running. But I want mDNSResponder or something non-Read Hat...

[grahamperrin]

SMB context, FreeBSD-CURRENT:

• https://old.reddit.com/r/freebsd/comments/km3n2b/-/ghdi422/?context=1

… I could not use my preferred text editor :-(

[probonopd]

If we can get rid of gvfs without losing functionality (especially zeroconf-based network browsing and ssftp mounting), I'd be all for it.

[probonopd]

Using something like

FreeBSD% sudo mkdir -p /media/Test
FreeBSD% sshfs -o idmap=user root@libreelec.local.: /media/Test

we can mount sftp shares, but we'd need to reimplement a dialog which asks for username and password, similar to what is currently in Filer using gvfs.

[fearedbliss]

Thanks for this research @probonopd. It helped me get trash support working in i3 + Thunar on FreeBSD 13.1-STABLE. Mounting USB drives also worked as well. The only weirdness is that if I delete something in the USB drive, it will (slowly) move it to the .Trash-1001 folder located on the USB drive, but those files won't be visible in the normal Trash displayed in Thunar. Furthermore, if I try to delete the individual trash files within the hidden .Trash-1001 dir on the USB drive, it will basically "re-delete" it with an appended extension. Deleting the entire .Trash-1001 folder yields an error message, but also displays another box saying if I want to permanently delete it, which ends up failing as well if I click "Yes to all". So the files are just there lol. I would need to delete it via CLI if anything.

EDIT: smb:// also seems to work in that it allows me to connect to my samba shares (normally something that isn't really possible on FreeBSD with the native kernel drivers). However it's janky. It would sometimes allow me to create files and folders, but when editing some files, it may either be slow, or it would write to the disk successfully, but throw a "read only" error. I'll continue to use NFS for FreeBSD <> FreeBSD machines, and use CIFS for my Windows machines connecting to the FreeBSD box.

jon@leslie:~ $ uname -a
FreeBSD leslie 13.1-STABLE FreeBSD 13.1-STABLE #0 stable/13-n252908-7a254e64bf3: Wed Nov  2 12:15:14 EDT 2022     root@leslie:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

I also didn't need to load fusefs. I just added the export $(dbus-launch) to my .xinitrc right before I launched i3 and it's working.

jon@leslie:~ $ kldstat
Id Refs Address                Size Name
 1  136 0xffffffff80200000  1f3b558 kernel
 2    1 0xffffffff8213c000    1b0d8 geom_eli.ko
 3    1 0xffffffff82158000   59a660 zfs.ko
 4    1 0xffffffff826f3000     a4a0 cryptodev.ko
 5    1 0xffffffff83802000   1808b8 i915kms.ko
 6    1 0xffffffff83983000    72bd8 drm.ko
 7    1 0xffffffff839f6000     22b0 iic.ko
 8    2 0xffffffff839f9000     30fc linuxkpi_gplv2.ko
 9    3 0xffffffff839fd000     62d8 dmabuf.ko
10    1 0xffffffff83a04000    590f0 vboxdrv.ko
11    1 0xffffffff83a5e000    33568 if_wg.ko
12    1 0xffffffff83a92000     3378 acpi_wmi.ko
13    1 0xffffffff83a96000     3250 ichsmb.ko
14    1 0xffffffff83a9a000     2180 smbus.ko
15    1 0xffffffff83a9d000    880c8 if_iwlwifi.ko
16    1 0xffffffff83b26000     5e7c ig4.ko
17    1 0xffffffff83b2c000     84e0 if_ure.ko
18    1 0xffffffff83b35000     3178 uether.ko
19    1 0xffffffff83b39000     2340 uhid.ko
20    1 0xffffffff83b3c000     4350 ums.ko
21    1 0xffffffff83b41000     3380 usbhid.ko
22    7 0xffffffff83b45000     31f8 hidbus.ko
23    1 0xffffffff83b49000     3320 wmt.ko
24    1 0xffffffff83b4d000     4d00 ng_ubt.ko
25    3 0xffffffff83b52000     aac8 netgraph.ko
26    2 0xffffffff83b5d000     a238 ng_hci.ko
27    2 0xffffffff83b68000     25a8 ng_bluetooth.ko
28    1 0xffffffff83b6b000     3240 iichid.ko
29    1 0xffffffff83b6f000     21e8 hcons.ko
30    2 0xffffffff83b72000     30a8 hidmap.ko
31    1 0xffffffff83b76000     21e8 hms.ko
32    1 0xffffffff83b79000     3328 hmt.ko
33    1 0xffffffff83b7d000     22b0 hconf.ko
34    1 0xffffffff83b80000     2240 pflog.ko
35    1 0xffffffff83b83000    3fa78 pf.ko

jon@leslie:~ $ cat .xinitrc 
#exec xfce4-session

# Enables Trash Support in Thunar (GVFS)
export $(dbus-launch)
exec i3

[probonopd]

Thanks for the info @fearedbliss.

We have been using gvfs on helloSystem now for a while; but may eventually want to get rid of it because it adds complexity to the system and depends on GLib.

[fearedbliss]

@probonopd Yea I completely agree. We need to get rid of it completely. All of these programs have gotten really complicated and heavy over the years. Let alone a lot of them only care about Linux (and I used to be a Gentoo Dev).

[probonopd]

In helloSystem my stretch goal is to get rid of GLib and everything that depends on it. Interestingly there is a large overlap between things that depend on GLib and things that are unnecessarily complicated and un-Unix-like.

(Yes, it's a stretch goal.)

[fearedbliss]

I'm rooting for you and I've been keeping an eye on your project <3.