SFTP: No storage locations configured

[daleosm]

Describe the bug
Most recent update on Ubuntu 19.04 produces error "No storage locations configured" I have ran the support tool but the action of opening a file manager connection with my device produces no error output.

To Reproduce
Steps to reproduce the behavior:
Action of opening a file manager connection with my device.

[ferdnyc]

That message means that you haven't configured any storage locations in the KDE Connect app on the Android end — in recent Android versions, the "Filesystem expose" plugin needs to be granted permission to access to directories before they can be opened remotely.

If you go into the app and view the paired device, you should see a message about the "Filesystem expose" plugin, or you can directly access its settings from the "Plugin settings" menu.

[daleosm]

Fixed, Thank you

[rrthomas]

I just came across this issue for the same reason. Thanks for the solution! Any chance of changing the error message so that it's more obvious what needs to be done?

[andyholmes]

Any chance of changing the error message so that it's more obvious what needs to be done?

Nope, this error message is one of a number of pre-translated strings sent by the Android app. If you have a suggestion for the error string, you'll have to open an issue on the KDE Connect bug tracker.

[rrthomas]

Thanks, @andyholmes, I'll open an issue there.

[rrthomas]

For anyone else who might want to track this bug, I've filed https://bugs.kde.org/show_bug.cgi?id=426541

[Craig-Macomber]

Any chance of changing the error message so that it's more obvious what needs to be done?

Nope, this error message is one of a number of pre-translated strings sent by the Android app. If you have a suggestion for the error string, you'll have to open an issue on the KDE Connect bug tracker.

I think the confusion is that the desktop app is reporting an error from the phone, and is not clarifying the origin of the error. For example I just got this error, and thought I could configure it on the desktop side, and found this thread when trying to find out how (I assumed the discoverability of how to do this was bad and I just couldn't find it).

Once I found this thread I learned that I was wrong, and got the information I needed. I don't think I was alone in this confusion based on the over 50 responses to @ferdnyc's very useful post above. I think the error message would be improved by saying something like: "KDE Connect app on device failed to allow browsing its file system. Instead the following error was reported: {Error message here}".

This avoids parsing/interpreting the string, but provides enough extra context to the user to point them in the right direction.

I also think presenting a notification in response to a "Browse this Device" button is a bad way to present the error. Especially with my multi monitor setup: I click something expecting it to open a file browser and instead I get a message (that depending on settings might not even display at all) on a different screen that vanishes after a couple seconds. Notifications are for async/external messages and should not be he only response to a local user action that in the success case presents some non-notification UI.

Lastly, I think an error code should be included to make the web searchable for these errors. If the strings change or if using less common locals, users would not find this thread. (Ex: If I was not using English, I wouldn't have debugged this nearly as fast since I would not have found this thread, but with an error code I could have).

[ferdnyc]

@Craig-Macomber

Well, same problem there, generating error codes would be the purview of the app. We don't parse the responses, and since they're pre-translated we'd have to be able to match every possible string in every language, to assign our own.

We might be able to change the message output to something like "Device responded: _______", (but localized), to make the origin clearer.

[andyholmes]

Also see #882, where the notification title was emended to read <device name> reported an error, and should remain in the notification area after shown to the user:

[ferdnyc]

Oh, cool, so that's basically already done.

I concede that the message can still be read as somewhat ambiguous as to where the problem lies — you have to interpret/intuit that the storage locations are configured on the device. But I still think that's something that would need to be addressed in the Android app, if anything. It might arguably be clearer if it were to respond with a message like, "No storage locations available to share". (Then again, some people may find that less clear.)

[ferdnyc]

It's a tricky problem because in the success case, the response to the user request is to open the file browser to the mounted location. Ideally, you'd want the error to be displayed the same way, but we have no access to Nautilus' built-in toasts, to move the error message into Nautilus instead of using the system notifications. And if we were to open our own error dialog, it feels likely we'd end up with exactly the same problem: The message might come up on a different screen, and it might be missed. (I'm far from confident we'd have access to reliable information about which screen a menu selection was made on, using the user menu API when running on Wayland.)

The issues here are somewhat similar to the ones discussed in #1203, and in response to @andyholmes' #1203 (comment) I was going to half-jokingly suggest that instead of mounting the device's filesystem, we could mount one shared by the local GSConnect daemon containing nothing but a README file describing possible reasons why the mount attempt failed, and open a file browser to that mount instead.

I didn't suggest that, there, but (as you can see) based on this conversation I'm re-entertaining that terrible idea. 😏

[andyholmes]

Yes, I'm not sure there's really good UX for errors like these that can be implemented client-side. Apparently Dolphin can show a message like this:

Even if that were possible, it would likely depend on the Nautilus extension and really isn't much better, in my opinion.