@kzimmermann I am not sure. Are gvfsd and gvfs-udisks2-volume-monitor running?
Monitoring communication over the D-Buses might give you some insight into what's wrong:
dbus-monitor --system
dbus-monitor --session
(each prints to stdout until Ctrl+C)
I'll post more when I can.
@kzimmermann in "ps dax" there should be at least 2 dbus-daemon processes, the global instance with "--system", and a "--session" process for each user's current login session. If you're not using a full desktop environment, the session DBus might be missing, so drive detection will fail in step 2 below, as would SFTP.
If that's the problem, you might be able to start a session DBus manually with "dbus-daemon --session", as yourself (not root).
@kzimmermann It's been possible to mount external media on #FreeBSD desktops for years now.
When you install devel/gvfs, (which desktops should do automatically), it also pulls in #bsdisks (sysutils/bsdisks) which implements the udisks2 DBus interface, and allows mounting drives from file managers.
@Anachron I both develop and package, and can tell you from experience, distro packaging is often broken or incomplete. Eg. the runtime dependency gvfs has on lsof (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254322) was only found accidentally, while developing gvfs code.
Distros don't stop telemetry in Firefox and Chrome even when they package them!
CVEs are a concern though. https://ludocode.com/blog/flatpak-is-not-the-future was proposing to link directly to distro binaries instead of the Flatpak runtimes that need to be patched separately.
@Anachron distros are often clueless and make packaging mistakes, or refuse to package software for political or legal reasons.
Upstream devs know their software best and have the greatest interest in keeping it working. Windows and macOS applications are packaged upstream.
Yes there are security and QA issues, but that's why #Snap and #Flatpak have sandboxing.