Provide as Flatpak app

[tobihagemann]

Just to be clear upfront: We have decided to provide Cryptomator for Linux as an AppImage (https://github.com/cryptomator/cryptomator/issues/469#issuecomment-375342207) and PPA. We are of course happy if anyone wants to provide Cryptomator as a Flatpak app but our official support will be limited on AppImage for now (https://github.com/cryptomator/cryptomator/issues/613#issuecomment-375343166) and PPA.

However, we're open for other methods to provide Cryptomator for Linux that are mainly contributed by the community (AUR being our prime example). We'll provide as much information as we can to make them possible.

To get started on providing Cryptomator as a Flatpak app, please read these comments: https://github.com/cryptomator/cryptomator/issues/613#issuecomment-392441852 and https://github.com/cryptomator/cryptomator/issues/613#issuecomment-420179669.

[bilelmoussaoui]

Hey, I'm that guy from Twitter. Will provide a fully working Flatpak today and push it to Flathub (the appcenter for flatpaks for now). This might require some additional modifications here like a correct AppData file (used to show the app information on the appcenter), a working desktop file and some shiny icons to be shipped! Updating the Flatpak packages is easy, you just edit the release tarball & sha256sum on a JSON/YAML file, test the build from a github comment using bot, build checkout the results, merge and voila the users will be getting the latest release no matter which distro they are using!

[overheadhunter]

This might require some additional modifications here like a correct AppData file (used to show the app information on the appcenter), a working desktop file and some shiny icons to be shipped!

You might want to copy them from here.

[bilelmoussaoui]

The desktop file is fine. Still, the desktop file, the icons & the appdata has to follow a RDNN (reverse domain name) specification. It's to avoid having two application with the same name shipping the same data in the same place. The appdata file has to be created too, otherwise, the application will look like an alien on every software center out there on Linux.

[infeo]

to provide them i forked temporary crypomator/cryptomator-linux: Under https://github.com/infeo/cryptomator-linux/tree/master/resources you can find a first suggestion for the appdata file in the flatpack directory. If there are some wrong settings, just let me know.

[bilelmoussaoui]

@infeo Prefect. The .desktop here is not needed https://github.com/infeo/cryptomator-linux/blob/master/resources/flatpack/org.cryptomator.cryptomator.appdata.xml#L64 You could also add some screenshots! and OARS tags (they are optional but they allow users or parents to control which apps their kids can use) https://hughsie.github.io/oars/

[overheadhunter]

@infeo Please also move/update the build.sh to the appimage subdirectory. Maybe we can then use build stages to first do common stuff (like downloading the .jars and executing ant) followed by the different package builds.

[bilelmoussaoui]

@infeo The icon name here https://github.com/infeo/cryptomator-linux/blob/master/resources/common/org.cryptomator.cryptomator.desktop#L5 should be updated too. For the icons, you could try to provide more sizes. This will make sure that the icons will look great on every distro/screen :+1:

[infeo]

@bilelmoussaoui is the .desktop ending not needed or should be removed? Because in the documentation examples the value of the launchable property has the .desktop. ending Oh, yeah. that should be another name.

@overheadhunter i changed the build paths in the build script. Using build stage sounds reasonable.

[bilelmoussaoui]

@infeo It can be removed :+1:

[bilelmoussaoui]

Also, the categories from here https://github.com/infeo/cryptomator-linux/blob/master/resources/flatpack/org.cryptomator.cryptomator.appdata.xml#L49 are not needed. They are extracted automatically from the desktop file. So they can be moved there instead. This file is not a Flatpak specification. It should be installed with whatever Linux packaging system under /usr/share/metainfo/ and the desktop file under /usr/share/applications The same for the icon here https://github.com/infeo/cryptomator-linux/blob/master/resources/flatpack/org.cryptomator.cryptomator.appdata.xml#L10 It should be removed as you're shipping a desktop file too.

[bilelmoussaoui]

Also you might want to add update_contact & developer_name For the https://github.com/infeo/cryptomator-linux/blob/master/resources/flatpack/org.cryptomator.cryptomator.appdata.xml#L65 You can use desktop instead of desktop-id and remove .desktop extension On linux you can validate that file using appstream-util validate myawesomeappdatafile.appdata.xml

[infeo]

Ohh, that is really a helpful tool!

soo, added, removed and changed some stuff. checked the appdata file with appstream-util, should be fine now.

i'll stick to the desktop-id property since it is recommended in the offical documentation.

[bilelmoussaoui]

@infeo Thanks for your work on this! For the release tags, as it's XML you can just use <release version="1.3.2" date="2017-11-25" urgency="medium" />

[thamch]

RDC to Windows 10 and running Cryptomator 1.4.0-Beta2 using DOKANY and getting error mapping Google Drive storage. Getting command failed and prompting "Please insert a disk into removable disk" cryptomator.log

[x80486]

Some more stuff/idea/tweaks!

For the AppStream Metadata file:

• You should use <content_rating type="oars-1.1" />, then you can have an empty tag
• (nice to have) Screenshots should have a 16:9 aspect ratio, and should have a width that is no smaller than 620px – reference here

...and I think that you wouldn't need a PNG if you have an SVG for the (future Flatpak) manifest.

[x80486]

I have something almost working on this branch. It's failing at startup because it JavaFX / OpenJFX is not in the classpath (read: present).

I'm going to wait to see if there is an extension for OpenJFX any time soon, otherwise I think installing it would do the trick also – but I'm not sure how to do that.

Using FUSE there are no problems...but WebDAV doesn't work:

[machina@pacific flathub]$ flatpak run org.cryptomator.Cryptomator 
22:41:14.462 [main] INFO  org.cryptomator.launcher.Cryptomator - Starting Cryptomator 1.4.0 on Linux 4.18.16-300.fc29.x86_64 (amd64)
Gtk-Message: 22:41:14.534: Failed to load module "canberra-gtk-module"
22:41:14.540 [main] INFO  o.c.launcher.FileOpenRequestHandler - Unable to setOpenFileHandler, probably not supported on this OS.
22:41:14.541 [main] WARN  o.c.l.InterProcessCommunicator - System property cryptomator.ipcPortPath not set.
22:41:14.541 [main] DEBUG o.c.l.InterProcessCommunicator - Could not connect to running process.
22:41:14.595 [main] DEBUG o.c.l.InterProcessCommunicator - Server listening on port 34217.
22:41:14.730 [JavaFX Application Thread] INFO  o.c.launcher.MainApplication - JavaFX application started.
22:41:14.793 [JavaFX Application Thread] INFO  o.c.common.settings.SettingsProvider - Settings loaded from /home/machina/.Cryptomator/settings.json
22:41:14.794 [JavaFX Application Thread] DEBUG org.cryptomator.logging.DebugMode - Debug mode initialized
22:41:14.797 [JavaFX Application Thread] DEBUG org.cryptomator.ui.l10n.Localization - Loaded localization default file: /localization/en.txt
22:41:14.797 [JavaFX Application Thread] DEBUG org.cryptomator.ui.l10n.Localization - Detected language "en" and region "US"
22:41:14.798 [JavaFX Application Thread] TRACE org.cryptomator.ui.l10n.Localization - Attempting to load localization from: /localization/en_US.txt
22:41:14.798 [JavaFX Application Thread] TRACE org.cryptomator.ui.l10n.Localization - Attempting to load localization from: /localization/en.txt
22:41:14.893 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
22:41:14.919 [JavaFX Application Thread] INFO  o.c.ui.controllers.MainController - Unable to setPreferencesHandler, probably not supported on this OS.
22:41:21.513 [pool-2-thread-1] INFO  o.c.common.settings.SettingsProvider - Settings saved to /home/machina/.Cryptomator/settings.json
22:41:23.954 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
22:41:31.103 [Background Thread 2] INFO  org.eclipse.jetty.util.log - Logging initialized @16875ms to org.eclipse.jetty.util.log.Slf4jLog
22:41:31.134 [Background Thread 2] INFO  o.c.frontend.webdav.WebDavServer - Binding server socket to localhost:42427
22:41:31.149 [Background Thread 2] INFO  o.e.jetty.server.AbstractConnector - Started ServerConnector@44d87ae6{HTTP/1.1,[http/1.1]}{localhost:42427}
22:41:31.150 [Background Thread 2] INFO  org.eclipse.jetty.server.Server - jetty-9.4.z-SNAPSHOT; built: 2018-08-30T13:59:14.071Z; git: 27208684755d94a92186989f695db2d7b21ebc51; jvm 10.0.2+13
22:41:31.169 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@1a1d164c{/,null,AVAILABLE}
22:41:31.170 [Background Thread 2] INFO  org.eclipse.jetty.server.Server - Started @16941ms
22:41:31.170 [Background Thread 2] INFO  o.c.frontend.webdav.WebDavServer - WebDavServer started.
22:41:31.203 [Background Thread 2] INFO  org.eclipse.jetty.server.session - DefaultSessionIdManager workerName=node0
22:41:31.203 [Background Thread 2] INFO  org.eclipse.jetty.server.session - No SessionScavenger set, using defaults
22:41:31.203 [Background Thread 2] INFO  org.eclipse.jetty.server.session - node0 Scavenging every 600000ms
22:41:31.210 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - authenticate-header = Basic realm="Jackrabbit Webdav Server"
22:41:31.211 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - csrf-protection = null
22:41:31.211 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - createAbsoluteURI = true
22:41:31.211 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@ce39c23{/1R6k8zhYTWtq/vault,null,AVAILABLE}
22:41:31.211 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - WebDavServlet started: /1R6k8zhYTWtq/vault
22:41:31.227 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - Mounting http://localhost:42427/1R6k8zhYTWtq/vault using org.cryptomator.frontend.webdav.mount.LinuxGioMounter
org.cryptomator.frontend.webdav.mount.Mounter$CommandFailedException: Command failed with exit code 2. Expected 0. Stderr: gio: dav://localhost:42427/1R6k8zhYTWtq/vault: volume doesn’t implement mount

    at org.cryptomator.frontend.webdav.mount.ProcessUtil.assertExitValue(ProcessUtil.java:28)
    at org.cryptomator.frontend.webdav.mount.LinuxGioMounter.mount(LinuxGioMounter.java:39)
    at org.cryptomator.frontend.webdav.servlet.WebDavServletController.mount(WebDavServletController.java:102)
    at org.cryptomator.ui.model.WebDavVolume.mount(WebDavVolume.java:60)
    at org.cryptomator.ui.model.WebDavVolume.mount(WebDavVolume.java:47)
    at org.cryptomator.ui.model.Vault.unlock(Vault.java:109)
    at org.cryptomator.ui.controllers.UnlockController.lambda$didClickUnlockButton$0(UnlockController.java:392)
    at org.cryptomator.ui.util.Tasks.lambda$create$0(Tasks.java:33)
    at org.cryptomator.ui.util.Tasks$TaskImpl.call(Tasks.java:139)
    at javafx.graphics/javafx.concurrent.Task$TaskCallable.call(Task.java:1425)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:844)
22:41:31.247 [JavaFX Application Thread] ERROR o.c.ui.controllers.UnlockController - Unlock failed for technical reasons.
org.cryptomator.ui.model.Volume$VolumeException: org.cryptomator.frontend.webdav.mount.Mounter$CommandFailedException: Command failed with exit code 2. Expected 0. Stderr: gio: dav://localhost:42427/1R6k8zhYTWtq/vault: volume doesn’t implement mount

    at org.cryptomator.ui.model.WebDavVolume.mount(WebDavVolume.java:63)
    at org.cryptomator.ui.model.WebDavVolume.mount(WebDavVolume.java:47)
    at org.cryptomator.ui.model.Vault.unlock(Vault.java:109)
    at org.cryptomator.ui.controllers.UnlockController.lambda$didClickUnlockButton$0(UnlockController.java:392)
    at org.cryptomator.ui.util.Tasks.lambda$create$0(Tasks.java:33)
    at org.cryptomator.ui.util.Tasks$TaskImpl.call(Tasks.java:139)
    at javafx.graphics/javafx.concurrent.Task$TaskCallable.call(Task.java:1425)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:514)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at java.base/java.lang.Thread.run(Thread.java:844)
Caused by: org.cryptomator.frontend.webdav.mount.Mounter$CommandFailedException: Command failed with exit code 2. Expected 0. Stderr: gio: dav://localhost:42427/1R6k8zhYTWtq/vault: volume doesn’t implement mount

    at org.cryptomator.frontend.webdav.mount.ProcessUtil.assertExitValue(ProcessUtil.java:28)
    at org.cryptomator.frontend.webdav.mount.LinuxGioMounter.mount(LinuxGioMounter.java:39)
    at org.cryptomator.frontend.webdav.servlet.WebDavServletController.mount(WebDavServletController.java:102)
    at org.cryptomator.ui.model.WebDavVolume.mount(WebDavVolume.java:60)
    ... 12 common frames omitted
22:41:33.287 [JavaFX Application Thread] INFO  o.c.launcher.MainApplication - JavaFX application stopped.
22:41:33.289 [main] DEBUG o.c.l.InterProcessCommunicator - Server shut down.
22:41:33.290 [Thread-0] DEBUG o.c.launcher.CleanShutdownPerformer - Running graceful shutdown tasks...
22:41:33.291 [Thread-0] INFO  o.c.launcher.CleanShutdownPerformer - Goodbye.

...maybe some missing dependency?

[x80486]

...and it's working right now, with FUSE:

[machina@pacific flathub]$ flatpak run org.cryptomator.Cryptomator 
18:31:17.957 [main] INFO  org.cryptomator.launcher.Cryptomator - Starting Cryptomator 1.4.0 on Linux 4.18.16-300.fc29.x86_64 (amd64)
Gtk-Message: 18:31:18.026: Failed to load module "canberra-gtk-module"
18:31:18.033 [main] INFO  o.c.launcher.FileOpenRequestHandler - Unable to setOpenFileHandler, probably not supported on this OS.
18:31:18.034 [main] WARN  o.c.l.InterProcessCommunicator - System property cryptomator.ipcPortPath not set.
18:31:18.034 [main] DEBUG o.c.l.InterProcessCommunicator - Could not connect to running process.
18:31:18.074 [main] DEBUG o.c.l.InterProcessCommunicator - Server listening on port 40821.
18:31:18.201 [JavaFX Application Thread] INFO  o.c.launcher.MainApplication - JavaFX application started.
18:31:18.234 [JavaFX Application Thread] INFO  o.c.common.settings.SettingsProvider - Failed to load settings, creating new one.
18:31:18.243 [JavaFX Application Thread] DEBUG org.cryptomator.ui.l10n.Localization - Loaded localization default file: /localization/en.txt
18:31:18.243 [JavaFX Application Thread] DEBUG org.cryptomator.ui.l10n.Localization - Detected language "en" and region "US"
18:31:18.313 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
18:31:18.335 [JavaFX Application Thread] INFO  o.c.ui.controllers.MainController - Unable to setPreferencesHandler, probably not supported on this OS.
18:31:22.130 [pool-2-thread-1] INFO  o.c.common.settings.SettingsProvider - Settings saved to /home/machina/.Cryptomator/settings.json
18:32:02.882 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
18:32:03.854 [pool-2-thread-1] INFO  o.c.common.settings.SettingsProvider - Settings saved to /home/machina/.Cryptomator/settings.json
18:32:10.926 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
18:32:23.491 [Background Thread 2] WARN  org.cryptomator.ui.model.FuseVolume - Could not delete mounting directory:/home/machina/.Cryptomator/vaultQ5Q2-bkLRqG8: Device or resource busy

...and WebDAV:

18:32:23.493 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
18:32:48.246 [pool-2-thread-1] INFO  o.c.common.settings.SettingsProvider - Settings saved to /home/machina/.Cryptomator/settings.json
18:32:52.898 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
18:32:54.770 [Background Thread 2] INFO  org.eclipse.jetty.util.log - Logging initialized @97084ms to org.eclipse.jetty.util.log.Slf4jLog
18:32:54.802 [Background Thread 2] INFO  o.c.frontend.webdav.WebDavServer - Binding server socket to localhost:42427
18:32:54.821 [Background Thread 2] INFO  o.e.jetty.server.AbstractConnector - Started ServerConnector@2242b833{HTTP/1.1,[http/1.1]}{localhost:42427}
18:32:54.823 [Background Thread 2] INFO  org.eclipse.jetty.server.Server - jetty-9.4.z-SNAPSHOT; built: 2018-08-30T13:59:14.071Z; git: 27208684755d94a92186989f695db2d7b21ebc51; jvm 10.0.2+13
18:32:54.839 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@7318c4e5{/,null,AVAILABLE}
18:32:54.839 [Background Thread 2] INFO  org.eclipse.jetty.server.Server - Started @97153ms
18:32:54.839 [Background Thread 2] INFO  o.c.frontend.webdav.WebDavServer - WebDavServer started.
18:32:54.869 [Background Thread 2] INFO  org.eclipse.jetty.server.session - DefaultSessionIdManager workerName=node0
18:32:54.870 [Background Thread 2] INFO  org.eclipse.jetty.server.session - No SessionScavenger set, using defaults
18:32:54.870 [Background Thread 2] INFO  org.eclipse.jetty.server.session - node0 Scavenging every 660000ms
18:32:54.873 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - authenticate-header = Basic realm="Jackrabbit Webdav Server"
18:32:54.873 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - csrf-protection = null
18:32:54.873 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - createAbsoluteURI = true
18:32:54.874 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@40b9d526{/Q5Q2-bkLRqG8/vault,null,AVAILABLE}
18:32:54.874 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - WebDavServlet started: /Q5Q2-bkLRqG8/vault
18:32:54.890 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - Mounting http://localhost:42427/Q5Q2-bkLRqG8/vault using org.cryptomator.frontend.webdav.mount.LinuxGioMounter
18:32:55.016 [etp527152263-131] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 0:
OPTIONS /Q5Q2-bkLRqG8/vault/ HTTP/1.1
Connection: keep-alive
User-Agent: gvfs/1.38.1
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9

18:32:55.043 [etp527152263-131] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 0:
200
DAV: 1, 2
MS-Author-Via: DAV
Date: Mon, 10 Dec 2018 23:32:55 GMT
Allow: OPTIONS, GET, HEAD, TRACE, PROPFIND, PROPPATCH, MKCOL, COPY, PUT, DELETE, MOVE, LOCK, UNLOCK

18:32:55.047 [etp527152263-121] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 1:
PROPFIND /Q5Q2-bkLRqG8/vault/ HTTP/1.1
User-Agent: gvfs/1.38.1
Connection: keep-alive
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9
Content-Length: 146
Depth: 0
Content-Type: application/xml

18:32:55.115 [etp527152263-121] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 1:
207
Content-Length: 416
Date: Mon, 10 Dec 2018 23:32:55 GMT
Content-Type: text/xml;charset=utf-8

18:32:55.135 [Background Thread 2] DEBUG o.c.f.webdav.mount.LinuxGioMounter - Mounted dav://localhost:42427/Q5Q2-bkLRqG8/vault
18:32:55.200 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 2:
PROPFIND /Q5Q2-bkLRqG8/vault/ HTTP/1.1
Apply-To-Redirect-Ref: T
Connection: keep-alive
User-Agent: gvfs/1.38.1
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9
Content-Length: 235
Depth: 0
Content-Type: application/xml

18:32:55.208 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 2:
207
Content-Length: 593
Date: Mon, 10 Dec 2018 23:32:55 GMT
Content-Type: text/xml;charset=utf-8

18:32:55.238 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 3:
PROPFIND /Q5Q2-bkLRqG8/vault/ HTTP/1.1
Apply-To-Redirect-Ref: T
Connection: keep-alive
User-Agent: gvfs/1.38.1
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9
Content-Length: 235
Depth: 0
Content-Type: application/xml

18:32:55.242 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 3:
207
Content-Length: 593
Date: Mon, 10 Dec 2018 23:32:55 GMT
Content-Type: text/xml;charset=utf-8

18:33:04.920 [etp527152263-136] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 4:
PROPFIND /Q5Q2-bkLRqG8/vault/ HTTP/1.1
Apply-To-Redirect-Ref: T
Connection: keep-alive
User-Agent: gvfs/1.38.1
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9
Content-Length: 235
Depth: 0
Content-Type: application/xml

18:33:04.929 [etp527152263-136] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 4:
207
Content-Length: 593
Date: Mon, 10 Dec 2018 23:33:04 GMT
Content-Type: text/xml;charset=utf-8

18:33:04.943 [etp527152263-136] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 5:
PROPFIND /Q5Q2-bkLRqG8/vault/ HTTP/1.1
Apply-To-Redirect-Ref: T
Connection: keep-alive
User-Agent: gvfs/1.38.1
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9
Content-Length: 235
Depth: 1
Content-Type: application/xml

18:33:04.944 [etp527152263-136] INFO  o.c.webdav.core.servlet.DavFolder - get members of /
18:33:04.952 [etp527152263-136] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 5:
207
Content-Length: 2660
Date: Mon, 10 Dec 2018 23:33:04 GMT
Content-Type: text/xml;charset=utf-8

18:33:04.953 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 6:
PROPFIND /Q5Q2-bkLRqG8/vault/ HTTP/1.1
Apply-To-Redirect-Ref: T
Connection: keep-alive
User-Agent: gvfs/1.38.1
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9
Content-Length: 235
Depth: 0
Content-Type: application/xml

18:33:04.955 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 6:
207
Content-Length: 593
Date: Mon, 10 Dec 2018 23:33:04 GMT
Content-Type: text/xml;charset=utf-8

18:33:04.956 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - REQUEST 7:
PROPFIND /Q5Q2-bkLRqG8/vault/ HTTP/1.1
Apply-To-Redirect-Ref: T
Connection: keep-alive
User-Agent: gvfs/1.38.1
Host: localhost:42427
Accept-Encoding: gzip, deflate
Accept-Language: en-us, en;q=0.9
Content-Length: 235
Depth: 0
Content-Type: application/xml

18:33:04.959 [etp527152263-133] INFO  o.c.w.core.filters.LoggingFilter - RESPONSE 7:
207
Content-Length: 593
Date: Mon, 10 Dec 2018 23:33:04 GMT
Content-Type: text/xml;charset=utf-8

18:33:17.104 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Stopped o.e.j.s.ServletContextHandler@40b9d526{/Q5Q2-bkLRqG8/vault,null,UNAVAILABLE}
18:33:17.104 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - WebDavServlet stopped: /Q5Q2-bkLRqG8/vault
18:33:17.106 [JavaFX Application Thread] WARN  o.c.k.WindowsProtectedKeychainAccess - Windows DataProtection module loaded, but no cryptomator.keychainPath property found.
18:33:33.710 [JavaFX Application Thread] INFO  o.c.launcher.MainApplication - JavaFX application stopped.
18:33:33.721 [main] DEBUG o.c.l.InterProcessCommunicator - Server shut down.
18:33:33.723 [Thread-0] DEBUG o.c.launcher.CleanShutdownPerformer - Running graceful shutdown tasks...
18:33:33.726 [Thread-0] INFO  o.c.launcher.CleanShutdownPerformer - Goodbye.

[x80486]

So @overheadhunter, is there a way to control where these files are stored:

• .ipcPort.tmp – created in the user's home directory, and it actually goes away once the application is closed
• ic2_something.log (or something like that) – created when there are some error with the JVM

I guess that wouldn't be a problem when #710 is addressed, but I would like to know if there is one of those -D settings I can use in the meantime.

On a different note, @bilelmoussaoui, would you want to team up on this one? I've seen that you are pretty good on these things...and for instance, right now I can't even figure it out how to install fuse 3 :rofl:

[overheadhunter]

@x80486 you can use -Dcryptomator.ipcPortPath

Btw: How did you include the JVM? Or is it an external dependency?

[bilelmoussaoui]

Yeah definitely. Let me know whatever help you need from me. You can reach me by email or on Twitter

[x80486]

@x80486 you can use -Dcryptomator.ipcPortPath

Great! I'll use it to force the file to be created (and recreated) inside $HOME/.Cryptomator until you start using the Freedesktop XDG Standard.

Btw: How did you include the JVM? Or is it an external dependency?

A compatible JRE (version 10.0.2+13) is included in the Flatpak "container" itself — as a dependency. Same for fuse and whatever is needed for WebDAV...so it should behave exactly the same between distros 🤞

On a different subject, I'm just reusing the generated JAR file from your build. I believe that Flathub folks like to build the artifact from scratch, but I don't see the need for Java applications; once you have the generated JAR, it's only a matter of guaranteeing the compatible JRE in order to run it successfully...but let's see how that goes. That's why I was poking on the OpenJFX issue, because if that's included we wouldn't even need to provide that dependency since the (fat) JAR would have all contained.

I don't know what's your preference on that.

[stale[bot]]

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]

A compatible JRE (version 10.0.2+13) is included in the Flatpak "container" itself — as a dependency. Same for fuse and whatever is needed for WebDAV...so it should behave exactly the same between distros 🤞

We shouldn't need to depend on a flatpak runtime that includes the JRE, since we're building a self-contained package that includes the required subset of said JRE. I think the freedesktop runtime is sufficient.

On a different subject, I'm just reusing the generated JAR file from your build. I believe that Flathub folks like to build the artifact from scratch, but I don't see the need for Java applications; once you have the generated JAR, it's only a matter of guaranteeing the compatible JRE in order to run it successfully...but let's see how that goes. That's why I was poking on the OpenJFX issue, because if that's included we wouldn't even need to provide that dependency since the (fat) JAR would have all contained.

I don't know what's your preference on that.

We should not build everything from source. This is not the way Maven works. There are already plenty pre-compiled libraries involved anyway. Instead I'll try to split our CI build process into two stages. The first stage creates a "directory" containing the ELF executable as well as the stripped-down JRE and all the libraries. The second stage will then build the AppImage. You can then get the artifact from the fist stage and wrap it into a Flatpak package.

[x80486]

We should not build everything from source. This is not the way Maven works. There are already plenty pre-compiled libraries involved anyway. Instead I'll try to split our CI build process into two stages. The first stage creates a "directory" containing the ELF executable as well as the stripped-down JRE and all the libraries. The second stage will then build the AppImage. You can then get the artifact from the fist stage and wrap it into a Flatpak package.

I agree, there is no need for that if some other process is taken care of it already. Eventually, all of that output would have to be published somewhere.

I don't know what's the content of that ELF executable; is that something platform-dependent or a wrapper for a fat JAR? I was under the assumption that you were delivering a "fat" JAR file with everything required (including JavaFX / OpenFX, in the future) to run it as java -jar /path/to/Cryptomator.jar.

[overheadhunter]

@x80486 still just experimenting, but this is what the multi-stage CI-build will produce after completing its first stage: https://dl.bintray.com/cryptomator/cryptomator/snapshot/ appdir.tar.gz contains the directory structure of the application that can then be amended to become an AppImage or Flatpak.

If you can provide a reproducable build instruction (i.e. a shell script) to generate a Flatpak from this directory structure, I'd be glad to add it to our build server, so the package can be generated automatically.

[bilelmoussaoui]

Oh nice! I will take a look at that and help providing a flatpak nightly and a stable one on flathub to boost the application on Linux:)

[x80486]

Maybe I didn't get it, but I was under the impression that, if I download appdir.tar.gz, extract everything, and run ./appdir/Cryptomator/Cryptomator it should work without any other (run-time) dependency...but I'm getting this:

Feb 15 19:25:17 pacific systemd[1489]: Starting Tracker metadata extractor...
Feb 15 19:25:17 pacific systemd-coredump[3596]: Removed old coredump core.Cryptomator.1000.6fdda7ef26a145968235b9d4cf3e8474.3349.1550276694000000.lz4.
Feb 15 19:25:17 pacific dbus-daemon[1518]: [session uid=1000 pid=1518] Successfully activated service 'org.freedesktop.Tracker1.Miner.Extract'
Feb 15 19:25:17 pacific systemd[1489]: Started Tracker metadata extractor.
Feb 15 19:25:18 pacific systemd-coredump[3596]: Process 3547 (Cryptomator) of user 1000 dumped core.

                                                Stack trace of thread 3592:
                                                #0  0x00007f69a6c9153f raise (libc.so.6)
                                                #1  0x00007f69a6c7b895 abort (libc.so.6)
                                                #2  0x00007f69986b9b39 n/a (/var/home/machina/Downloads/appdir/Cryptomator/runtime/lib/server/libjvm.so)
                                                #3  0x00007f69988e2569 n/a (/var/home/machina/Downloads/appdir/Cryptomator/runtime/lib/server/libjvm.so)
                                                #4  0x00007f69988e2deb n/a (/var/home/machina/Downloads/appdir/Cryptomator/runtime/lib/server/libjvm.so)
                                                #5  0x00007f69988e2e1e n/a (/var/home/machina/Downloads/appdir/Cryptomator/runtime/lib/server/libjvm.so)
                                                #6  0x00007f69986c4950 n/a (/var/home/machina/Downloads/appdir/Cryptomator/runtime/lib/server/libjvm.so)
                                                #7  0x00007f69986b8538 n/a (/var/home/machina/Downloads/appdir/Cryptomator/runtime/lib/server/libjvm.so)
                                                #8  0x00007f69a6c915c0 __restore_rt (libc.so.6)
                                                #9  0x00007f6990638830 n/a (n/a)
                                                #10 0x0000000000000000 n/a (n/a)
Feb 15 19:25:18 pacific audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@1-3595-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

...and I do have glibc-2.28-26.fc29.x86_64 that includes libc.so.6 (although I don't know much about these stuff):

[machina@pacific ~]$ rpm -ql glibc-2.28-26.fc29.x86_64
...
/lib64/libc.so.6
/lib64/libdl-2.28.so
/lib64/libm-2.28.so
/lib64/libm.so.6
/lib64/libmvec-2.28.so

I do see the JAR files there, so it looks like that wouldn't be an issue when this runs. And like I mentioned before, I have a branch that works already (@bilelmoussaoui you can take a look in there and see if you can make some improvements if you would like instead of starting from scratch...of course, provided that everything looks "decent"). It would be a matter of changing the location for the .tar.gz file and removing some of the dependencies, like JavaFX, and probably the Java Runtime Environment.

[overheadhunter]

Maybe I didn't get it, but I was under the impression that, if I download appdir.tar.gz, extract everything, and run ./appdir/Cryptomator/Cryptomator it should work without any other (run-time) dependency

Yep that was the plan. As I said the setup is still a bit experimental... The binary is built by a buildtool that itself is a backport of an unstable JDK early access release. 🙈

It does start on my Mint 19.1 / Linux 4.15.0 VM. These are the linked libraries:

ldd Cryptomator 
    linux-vdso.so.1 (0x00007ffc721cc000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcc338d4000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fcc33536000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcc33145000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fcc33ad8000)

[x80486]

All right...it (half) works when I build the Flatpak :sunglasses:

Not sure why FUSE is giving this error now:

23:20:47.271 [Background Thread 2] DEBUG org.cryptomator.cryptofs.ReadonlyFlag - Vault opened for read and write.
23:20:47.623 [Background Thread 2] DEBUG org.cryptomator.ui.model.FuseVolume - Successfully created mount point: /home/machina/.Cryptomator/G6gZM3EiQL8v_0
Portal call failed: Failed to start command: Failed to change to directory “/app/Cryptomator/app” (No such file or directory)
23:20:47.819 [JavaFX Application Thread] ERROR org.cryptomator.ui.controllers.UnlockController - Unlock failed for technical reasons.
org.cryptomator.ui.model.Volume$VolumeException: Unable to mount Filesystem
    at org.cryptomator.ui.model.FuseVolume.mount(FuseVolume.java:97)
    at org.cryptomator.ui.model.FuseVolume.mount(FuseVolume.java:59)
    at org.cryptomator.ui.model.Vault.unlock(Vault.java:117)
    at org.cryptomator.ui.controllers.UnlockController.lambda$didClickUnlockButton$0(UnlockController.java:439)
    at org.cryptomator.ui.util.Tasks.lambda$create$0(Tasks.java:33)
    at org.cryptomator.ui.util.Tasks$TaskImpl.call(Tasks.java:139)
    at javafx.concurrent.Task$TaskCallable.call(Task.java:1425)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.cryptomator.frontend.fuse.mount.CommandFailedException: ru.serce.jnrfuse.FuseException: Unable to mount FS
    at org.cryptomator.frontend.fuse.mount.AbstractMount.mount(AbstractMount.java:25)
    at org.cryptomator.frontend.fuse.mount.LinuxMounter.mount(LinuxMounter.java:20)
    at org.cryptomator.ui.model.FuseVolume.mount(FuseVolume.java:95)
    ... 12 common frames omitted
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS
    at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:287)
    at org.cryptomator.frontend.fuse.mount.AbstractMount.mount(AbstractMount.java:23)
    ... 14 common frames omitted
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 1
    at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:283)
    ... 15 common frames omitted

WebDAV works fine. Funny thing is, if I use the JAR version: Cryptomator-1.4.0.jar, FUSE works fine. Let me see what's going on here, but I assume what you are trying to do (the ELF executable) works.

[overheadhunter]

Not sure what return code = 1 means. Could be anything, maybe libfuse2.so needs more privileges in the sandbox?

Btw I think it should be sufficient to use the freedesktop runtime and add xdg-utils as a module.

Also, I suggest commenting what the different sandbox permissions are used for. I.e.

    "--device=dri", /* GUI rendering */
    "--filesystem=home", /* access vaults stored in user's home directory */
    "--persist=.Cryptomator", /* settings, logs and mount points */
    "--share=network", /* check for updates, launch webdav server */
    "--socket=x11" /* GUI rendering */

[x80486]

I've tried to use Freedesktop 18.08 from time to time, but WebDAV doesn't work...and I know why: there are some dependencies in GNOME 3.30 not present in Freedesktop 18.08 that makes it happen – I just don't know what are those :rofl:

When the Flatpak becomes stable (and before submitting it to Flathub) I can dig those; I already tried gvfs alone...no luck. I would also want to use libfuse 3.x but I think that needs some serious modifications to make it work in Flatpak.

The comments can be added, but once you work on a couple of manifests you realize they are not needed – and you might get some heat from reviewers in Flathub because of that :sunglasses:

[overheadhunter]

We don't support fuse 3 features anyway, yet. Regarding the comments: I find them helpful to understand why the permission is needed. It should be good practice to do this, otherwise what is the point of sandboxing at all? But you're right: The first goal should be to get it working at all.

[stale[bot]]

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.

[bilelmoussaoui]

@x80486 Is there anything left to be done here in order to ship cryptomator as a flatpak? :D

[x80486]

I gave it another try with latest release, but still, FUSE mounts don't work:

22:09:46.520 [pool-1-thread-1] INFO  o.c.common.settings.SettingsProvider - Settings saved to /home/x80486/.config/Cryptomator/settings.json
fusermount: fuse device not found, try 'modprobe fuse' first
22:09:49.466 [JavaFX Application Thread] ERROR o.c.ui.controllers.UnlockController - Unlock failed for technical reasons.
org.cryptomator.ui.model.Volume$VolumeException: Unable to mount Filesystem
    at org.cryptomator.ui.model.FuseVolume.mount(FuseVolume.java:105)
    at org.cryptomator.ui.model.FuseVolume.mount(FuseVolume.java:56)
    at org.cryptomator.ui.model.Vault.unlock(Vault.java:113)
    at org.cryptomator.ui.controllers.UnlockController.lambda$didClickUnlockButton$0(UnlockController.java:439)
    at org.cryptomator.ui.util.Tasks.lambda$create$0(Tasks.java:33)
    at org.cryptomator.ui.util.Tasks$TaskImpl.call(Tasks.java:139)
    at javafx.concurrent.Task$TaskCallable.call(Task.java:1425)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
    at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: org.cryptomator.frontend.fuse.mount.CommandFailedException: ru.serce.jnrfuse.FuseException: Unable to mount FS
    at org.cryptomator.frontend.fuse.mount.AbstractMount.mount(AbstractMount.java:25)
    at org.cryptomator.frontend.fuse.mount.LinuxMounter.mount(LinuxMounter.java:20)
    at org.cryptomator.ui.model.FuseVolume.mount(FuseVolume.java:103)
    ... 12 common frames omitted
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS
    at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:281)
    at org.cryptomator.frontend.fuse.mount.AbstractMount.mount(AbstractMount.java:23)
    ... 14 common frames omitted
Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 1
    at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:277)
    ... 15 common frames omitted
22:09:51.566 [JavaFX Application Thread] INFO  org.cryptomator.launcher.Cryptomator - JavaFX application stopped.

WebDAV works fine:

22:09:21.499 [pool-1-thread-1] INFO  o.c.common.settings.SettingsProvider - Settings saved to /home/x80486/.config/Cryptomator/settings.json
22:09:22.607 [Background Thread 2] INFO  org.eclipse.jetty.util.log - Logging initialized @12525ms to org.eclipse.jetty.util.log.Slf4jLog
22:09:22.667 [Background Thread 2] INFO  o.c.frontend.webdav.WebDavServer - Binding server socket to localhost:42427
22:09:22.687 [Background Thread 2] INFO  o.e.jetty.server.AbstractConnector - Started ServerConnector@143192a{HTTP/1.1,[http/1.1]}{localhost:42427}
22:09:22.688 [Background Thread 2] INFO  org.eclipse.jetty.server.Server - jetty-9.4.14.v20181114; built: 2018-11-14T21:20:31.478Z; git: c4550056e785fb5665914545889f21dc136ad9e6; jvm 11.0.2+9
22:09:22.712 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@4b0da640{/,null,AVAILABLE}
22:09:22.712 [Background Thread 2] INFO  org.eclipse.jetty.server.Server - Started @12629ms
22:09:22.712 [Background Thread 2] INFO  o.c.frontend.webdav.WebDavServer - WebDavServer started.
22:09:22.741 [Background Thread 2] INFO  org.eclipse.jetty.server.session - DefaultSessionIdManager workerName=node0
22:09:22.742 [Background Thread 2] INFO  org.eclipse.jetty.server.session - No SessionScavenger set, using defaults
22:09:22.742 [Background Thread 2] INFO  org.eclipse.jetty.server.session - node0 Scavenging every 660000ms
22:09:22.748 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - authenticate-header = Basic realm="Jackrabbit Webdav Server"
22:09:22.749 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - csrf-protection = null
22:09:22.749 [Background Thread 2] INFO  o.a.j.w.server.AbstractWebdavServlet - createAbsoluteURI = true
22:09:22.750 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Started o.e.j.s.ServletContextHandler@59d86edb{/JO1zglW_Q4jY/dsfggsdfg,null,AVAILABLE}
22:09:22.750 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - WebDavServlet started: /JO1zglW_Q4jY/dsfggsdfg
22:09:22.781 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - Mounting http://localhost:42427/JO1zglW_Q4jY/dsfggsdfg using org.cryptomator.frontend.webdav.mount.LinuxGioMounter
22:09:36.041 [Background Thread 2] INFO  o.e.j.server.handler.ContextHandler - Stopped o.e.j.s.ServletContextHandler@59d86edb{/JO1zglW_Q4jY/dsfggsdfg,null,UNAVAILABLE}
22:09:36.041 [Background Thread 2] INFO  o.c.f.w.s.WebDavServletController - WebDavServlet stopped: /JO1zglW_Q4jY/dsfggsdfg

I'm installing FUSE in exactly the same way org.gnome.Builder does :sunglasses: – like copy and paste. Maybe MOUNT_FUSE_PATH is not correctly set, but I would need to learn about it since I'm flying blind here. I don't know anything about FUSE.

Would be nice if you can pull the branch, give it a shot and see if you arrive to a different end.

[stale[bot]]

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]

We're still interested in this topic. If we can get FUSE working inside a Flatpak, we may start publishing Cryptomator this way.

[bilelmoussaoui]

Perfect, I will take care of that tomorrow. Don't hesitate to ping me by the end of the week in case I forget 😅

[x80486]

If I use this one: https://github.com/cryptomator/cryptomator/releases/download/1.4.12/buildkit-linux.zip ...FUSE works till some extent. I have no idea what was changed, but it's working, so who cares :rofl:

There are some permission issues when trying to lock the folder, but I think that's easier to solve.

One question, I know you are using a bunch of JVM arguments (the -D settings):

java -cp "libs/*" \
  -Dcryptomator.settingsPath="~/.config/Cryptomator/settings.json" \
  -Dcryptomator.ipcPortPath="~/.config/Cryptomator/ipcPort.bin" \
  -Dcryptomator.logDir="~/.local/share/Cryptomator/logs" \
  -Dcryptomator.mountPointsDir="~/.local/share/Cryptomator/mnt" \
  -Djdk.gtk.version=2 \
  -Xss20m \
  -Xmx512m \
  org.cryptomator.launcher.Cryptomator

...but why don't you default them to the XDG dirs, and provide an override with JVM arguments? What I meant is that this should be using the XDG variables and not a hard-coded ~/.config/..., etc. Right now Cryptomator is going to use the actual user's home XDG dirs (that's one advance), but with Flatpak that's mapped into ${HOME}/.var/app/${APP_ID}.

[overheadhunter]

Woah @x80486 that is great news!

Did you try changing to XDG variables? The only reason why we didn't use them is that we didn't want to check whether they are actually set. We changed to hard-coded ~/.config/ and ~/.local/share due to issue #793 As described in https://github.com/cryptomator/cryptomator-linux/issues/12, we're able to specifiy multiple paths to migrate existing settings.

I.e. feel free to modify the launcher script to something like:

#!/bin/sh
XDG_CONFIG_HOME="${XDG_CONFIG_HOME:~/.config}" # it is possible XDG_CONFIG_HOME isn't set yet (see https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html#variables)
XDG_DATA_HOME="${XDG_DATA_HOME:~/.local/share}"

java -cp "libs/*" \
  -Dcryptomator.settingsPath="${XDG_CONFIG_HOME}/Cryptomator/settings.json:~/.config/Cryptomator/settings.json:~/.Cryptomator/settings.json" \
  -Dcryptomator.ipcPortPath="${XDG_CONFIG_HOME}/Cryptomator/ipcPort.bin" \
  -Dcryptomator.logDir="${XDG_DATA_HOME}/Cryptomator/logs" \
  -Dcryptomator.mountPointsDir="${XDG_DATA_HOME}/Cryptomator/mnt" \
  -Djdk.gtk.version=2 \
  -Xss20m \
  -Xmx512m \
  org.cryptomator.launcher.Cryptomator

(note the : in cryptomator.settingsPath to read settings from "old" paths if XDG_CONFIG_HOME is set to some different location)

[x80486]

I did some more changes and tried the Freedesktop 18.08 and everything works fine also, except for WebDAV; looks like the GNOME runtime is bringing up some dependencies needed for that. It's either using GNOME 3.32 or figure it out the dependencies and including them in the manifest with Freedesktop 18.08.

I modified the launch script a little bit (as you suggested) and now Cryptomator stores everything as it should when running Flatpak'ed.

Now, there is one real issue (still) I can't overcome. I'm getting sort of a warning message when trying to do Lock Vault:

[overheadhunter]

Good job there! We're fine with ditching WebDAV on Linux anyway, since FUSE is available on basically more Linux desktop distros than WebDAV.

Regarding the force lock thing I need to do some experiments myself. This warning suggests that some process (usually some shell's working directory) is accessing the mount.

Do you think we can reproduce the build on a CI server (via https://github.com/cryptomator/cryptomator-linux)? Then we can officially start publishing Cryptomator as a Flatpak package.

[x80486]

All right, but in order to "ditch" WebDAV on Linux you would need to remove the option from the application itself, right?

On reproducing the build...you meant to build the Flatpak using TravisCI? If so, that's exactly what Flathub offers – and on top of that publishing. You can leverage all of that to them, since they are already established in those matters and pretty much everyone uses (and refers to) Flathub for distribution. Those are my thoughts. Eventually, every application owner could take different paths. It's really up to you to decide.

[overheadhunter]

All right, but in order to "ditch" WebDAV on Linux you would need to remove the option from the application itself, right?

Yes in order to make the option unavailable, we'd need to introduce a new flag to the launcher script. I assume you tried both, dav:// and webdav:// url prefixes when trying to mount via WebDAV? This seems to be some kind of religious war between Gnome and KDE. Cryptomator simply invokes an xdg-open (web)dav://localhost:port/vaultid. Maybe this command is unavailable in the freedesktop runtime?

On reproducing the build...you meant to build the Flatpak using TravisCI? If so, that's exactly what Flathub offers – and on top of that publishing. You can leverage all of that to them, since they are already established in those matters and pretty much everyone uses (and refers to) Flathub for distribution. Those are my thoughts. Eventually, every application owner could take different paths. It's really up to you to decide.

Ah I see. So how do we trigger a new build then? Make a PR on flathubs repo? How long does it take to get merged?

[overheadhunter]

@x80486: I cloned your repo, but FUSE still fails to mount with exit code 1.

Tested with flatpak 1.0.8 and flatpak-builder 0.10.9. Maybe the version makes a difference?

[x80486]

@x80486: I cloned your repo, but FUSE still fails to mount with exit code 1.

Tested with flatpak 1.0.8 and flatpak-builder 0.10.9. Maybe the version makes a difference?

OK, I just did another round "just in case" and it works fine.

Can you try with these versions and see of you have a different result?

x80486@ubuntu-vm:~/Workshop/flathub$ flatpak-builder --version
flatpak-builder 1.0.5
x80486@ubuntu-vm:~/Workshop/flathub$ flatpak --version
Flatpak 1.2.4

I think there is a way to lock down the minimum Flatpak version in the manifest...if that's required.

[overheadhunter]

Installed Flatpak 1.4.2 and flatpak-builder 1.0.8 from the ppa, but without success. Mounting still fails with exit code 1. Tried building with --force-clean --disable-cache but without success.

[x80486]

OK, that's weird. The magic question (that shouldn't be asked with Flatpaks): what distro and version are you using?

I went ahead and send a Draft Pull Request for Cryptomator in Flathub: https://github.com/flathub/flathub/pull/1091/ ...can you try the builds over there?

---

And I just tried that build also in Arch Linux (what I use)...and everything is fine.

[overheadhunter]

what distro and version are you using?

Linut Mint 19.2 Cinnamon with flatpak from ppa:alexlarsson/flatpak and all other packages (at the time of writing this) in their latest versions from ubuntu bionic as well as linux mint package repositories.

So I guess we need to find out the differences between our setups and then we might find the cause why FUSE didn't mount in the first place.

I went ahead and send a Draft Pull Request for Cryptomator in Flathub: flathub/flathub#1091 ...can you try the builds over there?

Same result:

Caused by: ru.serce.jnrfuse.FuseException: Unable to mount FS, return code = 1
    at ru.serce.jnrfuse.AbstractFuseFS.mount(AbstractFuseFS.java:277)
    ... 14 common frames omitted

I can access the vault via webdav, though. Mounting fails (as you've described) but entering the address into the file manager manually works (still not the kind of user experience we want, though).

Before releasing: I'd like to discuss whether we want to bundle a smaller JRE instead of depending on the openjdk flatpak extension. But let's postpone this discussion to the future when everything else is solved.

[x80486]

I was able to reproduce the issue in Mint. I can't really see what's the difference other than the host's Fuse is a lower version than the other Linuxes I've tried.

Another thing is, I don't see the fusermount-wrapper.sh being executed when the mount is successful, but only when it fails. I would have to play around with this to see if I can figure it out what's going on.

And yes, I agree that a bundled, slimmed-down JRE is better; and even better if you can specify the modules in the CLI at runtime. If that's the case, there is no need to include the OpenJDK from the Sdk Extension.