Filesystem not mounting when clicking "Browse Files" about gnome-shell-extension-gsconnect

[andyholmes]

Hi, it doesn't seem like there's anything obviously wrong in the debug output. There are some known issues with KDE Connect and SSHFS 3.x (only < 3.3 I think, but may be present as a regression in some distros), but being able to connect manually would imply that those aren't in play here.

Because of the DSS algorithm requirement GSConnect actually just spawns sshfs pretty much like you did. I'm all tied up at the moment, but I'll mark this as a bug and come back to it when I can.

[andyholmes]

Hi, I've had a couple looks at this, and although the SFTP plugin is one of the less reliable plugins (even for KDE Connect) I'm not sure this is a GSConnect issue.

I believe this may be an Android Oreo issue, although I'm unsure. Do you (or maybe a friend) have a device with Nougat or earlier you could test this with to confirm?

I'm planning a v9 bugfix release soon that will be distributed on the extension website and will be around for quite awhile (until v10 is complete), so if this is not Oreo issue we should track it down ASAP.

[arngo]

I get the same results on Android 7.1.2 (LineageOS 14.1).

[andyholmes]

Hi, thanks for checking that. Since it's not an Oreo issue, very likely not an sshfs issue, and there are no errors reported in the debug output, I suspect this is an issue with the (actual) Shell extension part of GSConnect.

GSConnect mounts the remote device under /run/user/<uid>/gsconnect/<device-id>/, for me this is /run/user/1000/gsconnect/5dd3aea571d9f746. Can you confirm that the device is in fact mounted/unmounted with: mount | grep gsconnect? Probably best to mount it by clicking the icon, but don't select a folder to avoid compounding errors.

There is a known quirk here, where GSConnect reports the device is mounted, slightly before it's ready to go, although it shouldn't be big issue. The message below should print a second or two after the _prepare():

JS LOG: Sftp: Warning: Permanently added '[192.168.1.70]:1739' (DSA) to the list of known hosts.

[arngo]

My device is mounted: [email protected]:/storage/emulated/0 on /run/user/1000/gsconnect/a493e8288f2112ab type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=100), I didn't actually know it mounted there. (This is my Oreo device)

[andyholmes]

Okay, that's somewhat good news. I believe the culprit is this line used for opening the directory:

Gio.AppInfo.launch_default_for_uri("file://" + item.path, null);

It's unfortunate this doesn't work, since I chose it to address xdg-open opening "Disk Usage Analyzer" on many Ubuntu installs. There are several ways to launch/fetch the default handler in GLib, but I suspect they all end up using the same method under the hood.

Here is a build with minor adjustment (not relying on a nullable function arg), if you could test this I'll cross my fingers, otherwise I'll open another 40 or so tabs and keep digging ;)

[email protected]

[arngo]

Well, I just found something new. When I open a directory (All files/Camera), my music player Quod Libet opens up. This is both on v9 and the build you just posted.

I hadn't noticed this before because I usually keep QL running, and only on this new build the app menu for QL shows up for a second with the loading icon when I try to open a directory with QL running. On v9 if QL was already running, there was no loading icon to indicate QL was trying to open something. (I'm not sure if this is really relevant but I hope I explained that well).

So, I uninstalled Quod Libet and now it opens properly in Nautilus, in v9 as well.

[andyholmes]

Ah, that probably has some relation to the xdg-open issue. I could never track that down to baobab/'Disk Usage Analyzer", but I suspect this could be considered a bug in QL packaging on Arch with regard to default handler registering (and so too, baobab on Ubuntu).

[arngo]

I installed QL again and checked it was not set as default for directories with xdg-mime query default inode/directory and got org.gnome.Nautilus.desktop, but I still ran xdg-mime default org.gnome.Nautilus.desktop inode/directory anyways and it solved my problem (I also tested it after reinstalling QL)! I found this strange, though, since I couldn't find anywhere indicating QL was set as default for opening directories.

[andyholmes]

That is odd, I bet it's the same as baobab. I would assume if it was claiming the mime-type, then it would be whichever was installed last would win. I'm glad that fixes it. I'll mark the adjustment I made as the fix, since that seemed to make it clear another application was grabbing the URI, and then mention this issue in the FAQ with the xdg-mime fix.

Thanks for taking the time to work through this with me, it helps out a lot.