New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On KDE based systems open safes don’t show up in Dolphin #513

Closed
felix-wo opened this Issue Jun 5, 2017 · 17 comments

Comments

Projects
None yet
8 participants
@felix-wo
Copy link

felix-wo commented Jun 5, 2017

Hello there!

This is a bug report.
I'm using Linux in version KDE Neon 5.8 User LTS (based on Ubuntu 16.04).
I'm running Cryptomator in version 1.2.3.

Description:

  • what I do: open a safe OR from an open safe: arrow down > "Laufwerk anzeigen" (german version)
  • what I expect: Dolphin (file manager of KDE) opens up showing the decrypted safe
  • what actually happens: nothing

issue seems to be present on other distributions with KDE, too: #411

Further investigation:

  • Copying the address of the opened safe (arrow down > "WebDAV-URL kopieren") and manually opening it in Dolphin works (in Dolphin: F6 > paste URL in address field > replace "http" by "webdav" > return).
  • "dolphin [WebDAV-URL]" or "xdg-open [WebDAV-URL]" on the command line opens Dolphin as well, just as the Cryptomator gui should do.
  • in comparison, in Ubuntu GNOME or Ubuntu standard edition (with Unity), ver. 16.04: Nautilus (i.e. the file manager of these desktop environments) opens the location from the Cryptomator gui as expected.

Conclusion: Somehow Cryptomator doesn’t send the right command for KDE based systems to open Dolphin file manager with the decrypted safe. Speculating on the exact issue:

  • Cryptomator could use "xdg-open" as overall solution for Linux (does it already?), as this should open the standard file manager on any desktop environment.
  • Or it’s still this issue #57 : Natuilus and (afaik) any gtk based file manager accept "dav:" to specify the protocol in the address line, but Dolphin needs "webdav:".

Maybe there should also be an option to specify the command for the file manager within the gui or at least in a config file.

Workaround: open the URL manually (as discribed) and set a bookmark in Dolphin (right click on the left column showing the locations …); open the safe as usual in Cryptomator, then use the bookmark

Thank you, developers, for the great program!

@zell-mbc

This comment has been minimized.

Copy link

zell-mbc commented Jun 5, 2017

Same platform (KDE Neon 5.10), same issue. But I'd like to add that after I type in the password to unlock a vault in the Cryptomator console, the system shows the "Mounting failed..." message and stays on the unlock screen asking for the unlock password which makes it look like the vault is still locked. Which it isn't!
Workaround is to click on the settings wheel and back on the vault which will now correctly show that the vault is unlocked and also allows to lock the vault.

@felix-wo

This comment has been minimized.

Copy link

felix-wo commented Jun 5, 2017

Hi zell-mbc!

I can confirm basically what you are telling if and only if I have chosen "webdav" (not "dav") in the settings (gear wheel) > "WebDAV Schema". (Now I got the clue what’s actually going wrong … but hold on, I’ll report that later …)

The error situation as you (@zell-mbc) report is actually a little bug (or at least some strange behaviour) of its own. If "webdav" is enabled in the settings and we try to open a safe with its correct key for the first time since starting the program:

  • it says "Verbindung fehlgeschlagen. …" (german version) – which is actually correct as the WebDAV URL failed to mount, though the safe is opened (i.e. the decryption is working)
  • it shows a green dot for the safe in the column on the left (correct)
  • the input field "Passwort" is still visible with the masqued password, though the safe is already open. Then:
    • If we click settings (gear whel) and then back on the safe the password is still there! *) I don’t know if that might be a security risk. Anyway it’s confusing. Or:
    • We can click "Tresor entsperren" a second time without retyping the password. The usual diagramm then appears though it (correctly) says "Verbinden des Laufwerks fehlgeschlagen" on the bottom.

*) @zell-mbc : differs from your description; maybe because it was your second try; situation seems to appear only the first time the mounting error occurs

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Jun 7, 2017

We need to resolve WebDAV-NIO-Adapter's issue 8. If you have any idea how to detect whether a system prefers dav: or webdav: or http:, please comment on that issue! :)

Btw I thought we were using xdg-open, however it seems like we're invoking gvfs-open (see code)... Not sure what is more common...?

@felix-wo

This comment has been minimized.

Copy link

felix-wo commented Jun 24, 2017

Hi there! Sorry for my late reply.

First, I’m not a programmer, and I’ve not inspected the code. I did some investigation with the program and its behavior on my systems (Ubuntu, see above).

We need to resolve WebDAV-NIO-Adapter's issue 8.

I guess, you mean KIO.

If you have any idea how to detect whether a system prefers dav: or webdav: or http:, please comment on that issue! :)

Automatic detection would be nice, of course, but that’s not the issue in the first place. The call under KDE systems obviously is implemented fundamentally wrong. If "webdav" is selected under "webdav Schema" in Cryptomator ~/.Cryptomator/cryptomator.log shows:

gvfs-open: webdav://localhost:[port]/[id]/[safe_name]: Fehler beim Öffnen des Ortes: Der angegebene Ort wird nicht unterstützt

This indicates a misconception. gvfs-open never accepts the syntax with the prefix "webdav://" for the protocol, but always and only "dav://". Anyway, under KDE after opening a safe it is possible to access the share manually with Dolphin (as described above), as Dolphin does not rely on gvfs in this case (WebDAV protocol). But obviously, Dolphin doesn’t get called with "webdav://…" as it should.

On the other hand, if "dav" is selected as "webdav Schema", even under a KDE system the share gets mounted correctly by gvfs. (gvfs is installed by default on a KDE Ubuntu derivate, too, as, for example, Dolphin uses gvfs for mounting external drives.) In consequence, the share is also accessible under its conventional mount point in the file system (/run/user/[user-id]/gvfs/[settings_string]/), on the command line or for any application. But this gvfs mount is – other than under many gtk file managers, which seem to use gvfs internally also for webdav and furter remote mounts – not even needed to open the webdav share with Dolphin (KDE file manager).

Be welcome to ask back for further information or investigation.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Aug 11, 2017

gvfs-open never accepts the syntax with the prefix "webdav://" for the protocol, but always and only "dav://".

Thats not entirely true. Apparently it passes on the URL to the file manager. This comment is very interesting.

@stale

This comment has been minimized.

Copy link

stale bot commented Jun 17, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Jun 17, 2018

We've released our first beta of 1.4.0, which brings FUSE support to macOS and Linux.

Please retest this issue with FUSE enabled and report your findings in this thread.


If you experience any new issues, please report them and tell us what software version (including macOS version, linux kernel, display manager, desktop environment) you're using.

⚠️ This is a beta version! Make backups and don't use this version for production data. ⚠️

@overheadhunter overheadhunter added this to the 1.4.0 milestone Jun 17, 2018

@no-response no-response bot closed this Jul 1, 2018

@no-response

This comment has been minimized.

Copy link

no-response bot commented Jul 1, 2018

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

@gatohaus

This comment has been minimized.

Copy link

gatohaus commented Sep 11, 2018

Yes, the Beta 1.4.0 does reveal the drive upon entering the password. :-)
This was under a fresh install of Kubuntu 18.04.

Slight problem with the binary version.. on opening Cryptomator, the application's window is tiny (24,94 pixels) and cannot be resized the usual way. It can be forced by selecting: More Actions > Special Window Settings.. -> Size, Force, 800,800.

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Sep 11, 2018

Great to hear! There is already an issue for the small window: #656.

@thewinner666

This comment has been minimized.

@infeo

This comment has been minimized.

Copy link
Member

infeo commented Sep 17, 2018

@thewinner666 basically yes, but there are several informations missing here: What OS are you using, which cryptomator version is running, can you provide any log files? Without this info we cannot help.

But most importantly, if you just need help, you should use the forum. This git-repositroy is for developing cryptomator, e.g. bugreports, feature requests etc.

@thewinner666

This comment has been minimized.

Copy link

thewinner666 commented Sep 18, 2018

Oh ok

@RebelCoderRU

This comment has been minimized.

Copy link

RebelCoderRU commented Oct 20, 2018

I am running Debian 9 Stable and I do not get an access to a virtual drive. No Window is opened when vault is mounted.

@thewinner666

This comment has been minimized.

Copy link

thewinner666 commented Oct 20, 2018

yeah same issue here but I was told to post it in the forum and I did not get a response after that

@overheadhunter

This comment has been minimized.

Copy link
Member

overheadhunter commented Oct 21, 2018

@thewinner666 @RebelCoderRU Since webdav scheme isn't properly supported by the file managers of all Linux distros, we are unable to universally fix this for 1.3.x. "Me too" comments regarding 1.3.x don't help if you're unwilling to read the whole conversation: As confirmed above, this issue is resolved in 1.4.0.

Given the fact that no new issues have been reported for the 1.4.0 betas under Linux, we consider it stable and recommend you to use 1.4.0-beta3.

@infeo

This comment has been minimized.

Copy link
Member

infeo commented Oct 21, 2018

Additional note @thewinner666 :
Oh, I remeber that I answered som time ago someone with a strange name and funny picture such a question. I can remember this, since the person rambled about like a little kid that none answered his request.
But the person ddin't gave enough info in the post to dig into this, therfore i had to asked a few question to analyze it better. But up to this very day these question leave unanswered and the remaining of the user is unbeknowst...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment