Cryptomator Crashes with fuse-t 1.0.29

[markbyrn]

I'm using Cryptomator 1.10.1 with Fuse-t 1.0.29. It's completely unstable now and Cryptomator crashes or locks up when copying file into the vault or even when opening a folder that contains a lot of files. It's happening on two different Macs running MacOS Sonoma. The only workaround is to use WebDAV instead of fuse-t.

Tried a complete uninstall and reinstall of both Crytpotmator and fuse-t. For fuse-t uninstall, i used brew remove -f fuse-t. Didn't fix the issue.

Not sure if it's an issue with Sonoma, Cryptomator, or fuse-t but Cryptomator works if not using fuse-t.

[macos-fuse-t]

Can you send your vault or create one that crashes?
Most likely it's a Cryptomator bug but I'll try to debug it from fuse-t side.

[markbyrn]

Can you send your vault or create one that crashes? Most likely it's a Cryptomator bug but I'll try to debug it from fuse-t side.

I created a test vault and quickly duplicated the problem. See your email which I sent from my Tutanota account.

[markbyrn]

I also sent a crash log.

[chrisspiegl]

@markbyrn do you have any update on this? Given that all communication stopped on Nov 1, I guess you continued to discuss this via email? I am hoping for an idea since I appear to have the same issue on my M1 Max machine.

[macos-fuse-t]

This issue is caused by a crash in the Cryptomator main app. I reported it directly to the team but didn't get any updates as of now.

[chrisspiegl]

Thank you for the update. It's an annoying bug since it almost makes Cryptomator unusable. But I appreciate the effort that you found it and reported it to the source. Do they have a GitHub Issues page where I can track this as well?

[macos-fuse-t]

Try the latest release of fuse-t with smb backend instead of nfs. It might resolve some of the issues.
https://github.com/macos-fuse-t/fuse-t/releases/tag/1.0.35

[chrisspiegl]

I'll test it and report back.

[chrisspiegl]

I installed fuse-t-macos-installer-1.0.35.pkg (Pkg) via brew
Cryptomator is v1.11.1

Error persists, and the finder appears to crash when navigating in a Cryptomator Drive.
Possibly adding: my Cryptomator source folder is stored in Google Drive.

[macos-fuse-t]

Did you changed backend to smb in the fuse-t.ini file?

[chrisspiegl]

Update: no longer needed. I found the requested info on the release page of https://github.com/macos-fuse-t/fuse-t/releases/tag/1.0.35

Previous Comment:

@macos-fuse-t thanks for this heads up, I thought that it was automatically changed and do not know where the fuse-t.ini file is? I tried looking into the Wiki on this page and the fuse-t.org website but did not find anything about it.

Could you point me to where the info about the fuse-t.ini needs to go / or a help page about it?

[macos-fuse-t]

See here:
https://github.com/macos-fuse-t/fuse-t/releases
You need to be an admin user to do that

[chrisspiegl]

I have tried, and here are my results with Cryptomator:

fuse-t.ini

[Default]
debug=true
;nfc=false
;readonly=false
;namedattr=true
;attrcache=true
;nobrowse=false
;rwsize=0
;noatime=false
;nomtime=false
;location=fuse-t
backend=smb

Relaunch Cryptomator

Open Container, and then an error message appears (which does not if I ; comment out the backend smb setting.

Error Code 09TB:8LNC:2O02
org.cryptomator.integrations.mount.MountFailedException: org.cryptomator.jfuse.api.FuseMountFailedException: fuse_loop() returned prematurely with non-zero exit code -1
	at [email protected]/org.cryptomator.frontend.fuse.mount.FuseTMountProvider$FuseTMountBuilder.mount(FuseTMountProvider.java:129)
	at [email protected]/org.cryptomator.common.mount.Mounter.mount(Mounter.java:138)
	at [email protected]/org.cryptomator.common.vaults.Vault.unlock(Vault.java:150)
	at [email protected]/org.cryptomator.ui.keyloading.KeyLoadingStrategy.use(KeyLoadingStrategy.java:79)
	at [email protected]/org.cryptomator.ui.unlock.UnlockWorkflow.attemptUnlock(UnlockWorkflow.java:70)
	at [email protected]/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:60)
	at [email protected]/org.cryptomator.ui.unlock.UnlockWorkflow.call(UnlockWorkflow.java:31)
	at [email protected]/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
	at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(Unknown Source)
	at java.base/java.util.concurrent.CompletableFuture$Completion.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)
Caused by: org.cryptomator.jfuse.api.FuseMountFailedException: fuse_loop() returned prematurely with non-zero exit code -1
	at [email protected]/org.cryptomator.jfuse.api.Fuse.mount(Fuse.java:130)
	at [email protected]/org.cryptomator.frontend.fuse.mount.FuseTMountProvider$FuseTMountBuilder.mount(FuseTMountProvider.java:126)
	... 13 more

[macos-fuse-t]

Could you send fuse-t.logs found in
~/Library/Application\ Support/fuse-t/logs/nfsv4-go.log

[chrisspiegl]

Sure, I sent the file via email since I don't fully see if there is any personal data in it.

[chrisspiegl]

With the above set fuse-t.ini based on info here: https://github.com/macos-fuse-t/fuse-t/releases/tag/1.0.35
Renamed the Container to have no space in the name of the Cryptomator container.
With the Cryptomator container stored in Google Drive.
And running the following versions: fuse-t-macos-installer-1.0.35.pkg (Pkg) via brew and Cryptomator at v1.11.1

I found this works now. Depending on my Internet Speed and Caching of the Container, I find that it ends up showing a bunch of the "macOS beach ball" in the Finder. That appears to be mostly because of the download happening behind the scenes. Before, Finder.app would crash and completely become unresponsive.

It does not appear to be fully ironed out at this point, but it is more stable and usable.

[macos-fuse-t]

So what's there still to fix?

[chrisspiegl]

I just sent another email and log. It appears to still be an issue. I am guessing it is related to the fact that when the Vault is stored in Google Drive the download takes a while sometimes. Which should not lead to a lockup but currently does and thus the Finder.app ends up unresponsive with a beach ball.

[macos-fuse-t]

Hmm, so to reproduce you just create a vault on a google drive and copy files there? how large are the files?
I definitely want to check this, but no promises it can be fixed though. Most probably it's the way network file systems work on macos

[chrisspiegl]

I am going to try this out. But it may take a week for some results, as I am swamped at the moment. I'll test if I can reproduce it with a new vault in the same GDrive.

[Uj947nXmRqV2nRaWshKtHzTvckUUpD]

Last year cryptomator was crashing randomly on MacOS (Ventura). I didn't track to know exactly which update fixed it, but what i can tell is that it seems that these problems are not present anymore recently. My issue on cryptomator repo: cryptomator/cryptomator#3085

[rmdvector]

I'm having the same problem on a M3 macbook pro. used the latest version as installed by Brew. Solved the problem by going through the flaming hoops Apple imposes to get macfuse to install and load: two reboots, enter my password 6 times, click through multiple dire warnings that I'm opening my OS to infiltration by any number of unsigned viruses. Just to mount a damned encrypted volume.
I hope this issue is eventually resolved.

[angloromanticism]

I am confronted with this now; I never got Fuse-T to work well on Mac with Cryptomator, but macFuse worked great.
Updating to Sequoia means MacFuse no longer works, and so Fuse-T is the only option: using it crashes Finder --and has made hard resets necessary-- when accessing a Google Drive. Opening or saving freezes cryptomator and Finder.

[jltdhome]

Having the same issue. It appears to be related to files downloading from the cloud in the background. The issue is not present when loading an encrypted vault from an external drive.