Cryptomator disconnects with errors when using "unstable" network storage

Help Desktop App
1

I am using MountainDuck to mount remote WebDAV volumes, in the “online” mode - so that all read and write directly goes to the internet.

Those volumes contain my encrypted Crytomator files and then get mounted with Cryptomator.

When I copy or update lots of files, or just one large file, I constantly see error messages like those:

rsync: [receiver] stat “/Volumes/HD_MEDIA/.IMG_0848.MOV.XWfOLQ” failed: Device not configured (6)
rsync: [receiver] rename “/Volumes/HD_MEDIA/.IMG_0848.MOV.XWfOLQ” → “IMG_0848.MOV”: Device not configured (6)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1356) [sender=3.2.7]

Often, the Cryptomator vault will then be shown as locked - even as it was unlocked before.

I now tested the behavior when directly writing to the WebDAV volumes, mounted with MountainDuck and saw such messages:

$ cp -p IMG_0848.MOV ~/MountainDuck/HIDRIVE/users/myself.hidrive/
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: not responding
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: not responding
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: not responding
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: not responding
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: not responding
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: not responding
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: not responding
nfs server HIDRIVE (webdav.hidrive.ionos.com):/: is alive again

So, it seems that the MountainDuck volume again and again runs into timeouts of some sort - which are not a problem!
MountainDuck normally retries successfully and the files get uploaded.

But Cryptomator cannot handle this “unstable” storage as it seems …

Is there a way to make Cryptomator retry longer or forever?
Any other workaround?

Probably a new setting or feature?

It is crucial for me to use WebDAV and this seems to be too unstable to be used with Cryptomator.

I am on macOS, latest Monterey, using macFUSE (not T-FUSE) and Cryptomator 1.6.17 - this was the most stable combination for my OS.

Any idea?

2

I now also got an Cryoptomator error in a pop-up:

Error Code TB89:QJIL:QJIL
java.nio.file.NoSuchFileException: /Volumes/XTRMQ/MountainDuck/HIDRIVE/users/tja.hidrive/CRYPTOMATOR/HD_MEDIA/vault.cryptomator
	at java.base/sun.nio.fs.UnixException.translateToIOException(Unknown Source)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
	at java.base/sun.nio.fs.UnixException.rethrowAsIOException(Unknown Source)
	at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(Unknown Source)
	at java.base/java.nio.file.Files.newByteChannel(Unknown Source)
	at java.base/java.nio.file.Files.newByteChannel(Unknown Source)
	at java.base/java.nio.file.Files.readAllBytes(Unknown Source)
	at java.base/java.nio.file.Files.readString(Unknown Source)
	at org.cryptomator.cryptofs@2.5.3/org.cryptomator.cryptofs.CryptoFileSystems.readVaultConfigFile(CryptoFileSystems.java:113)
	at org.cryptomator.cryptofs@2.5.3/org.cryptomator.cryptofs.CryptoFileSystems.create(CryptoFileSystems.java:49)
	at org.cryptomator.cryptofs@2.5.3/org.cryptomator.cryptofs.CryptoFileSystemProvider.newFileSystem(CryptoFileSystemProvider.java:196)
	at org.cryptomator.cryptofs@2.5.3/org.cryptomator.cryptofs.CryptoFileSystemProvider.newFileSystem(CryptoFileSystemProvider.java:86)
	at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source)
	at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source)
	at org.cryptomator.cryptofs@2.5.3/org.cryptomator.cryptofs.CryptoFileSystemProvider.newFileSystem(CryptoFileSystemProvider.java:126)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.common.vaults.Vault.createCryptoFileSystem(Vault.java:130)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.common.vaults.Vault.unlock(Vault.java:149)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.keyloading.KeyLoadingStrategy.use(KeyLoadingStrategy.java:79)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.unlock.UnlockWorkflow.attemptUnlock(UnlockWorkflow.java:72)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:62)
	at org.cryptomator.desktop@1.6.17/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:35)
	at javafx.graphics/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)
3

Now, this does not seem to spur any kind of interest …

:frowning:

4

Well,

Error Code TB89:QJIL:QJIL
java.nio.file.NoSuchFileException: /Volumes/XTRMQ/MountainDuck/HIDRIVE/users/tja.hidrive/CRYPTOMATOR/HD_MEDIA/vault.cryptomator

When cryptomator is not able to find the files, there’s nothing much that can be done by cryptomator.

You wite you are using mountain duck to mount your drive.
As far as I know, Cryptomator technology is included in MountainDuck. Is there a reason you are using cryptomator on top of Mountainduck?

Further more, as you wrote, you highdrive connection seems unstable. Also nothing cryptomator can do about.