I tried to use FUSE-T 1.0.13 on a Apple MacBook Pro with M1 processor and Cryptomator 1.7.0 (dmg-4333). The operating system is macOS Ventura 13.2.1. Using one vault seemed to work. I noticed files in the FUSE-T mounted vault were belonging not to me but to a uid like 65543 and the group also was set to a gid in that range instead of staff. That made git complain about weird ownership of files in the git repository.
When I opened a second vault, I/O to files in the first vault was frozen. When I closed the second vault, I/O to files in the first vault resumed. That seemed to be too experimental to me so now I am back at macFUSE 4.4.2.
Thank you for your feedback! As the setting suggests, it’s indeed experimental for a reason. Unfortunately, we didn’t get such feedback during the extended beta period but it’s never too late to fix things. 
We’ll look into it!
1 Like
On the download page for Cryptomator the recommendation for Intel Macs is macFUSE but FUSE-T for Apple Silicon macs. The latter might be too early to recommend.
Quick update: A fix in FUSE-T is on the way and you should be able to unlock multiple vaults very soon.
Regarding UID/GID, we’ll still looking into it.
To be honest, we have to recommend SOMETHING for Apple Silicon Macs. WebDAV doesn’t work properly and macFUSE is hard to install. There is no other obvious choice. But if you went through the hoops to install macFUSE, then just keep using it.
I had the same issue with two or more vaults but wasn’t quick enough to report it here. With the newest FUSE-T 1.0.14 which was released a couple of hours ago, opening more than one vault at a time now worked for me. 
@hoehenunterschied Would you be willing to try it again with Cryptomator 1.7.2 regarding UID/GID? Should be resolved now.
I am at macOS Monterey and use macFUSE 4.4.1, so far without problems.
Also, I am still at Cryptomator 1.6.17
Would I need to switch to FUSE-t when I upgrade to macOS Ventura?
macFUSE is not recommended for Cryptomator 1.7.x?
I am ONLY interested in stability 
You can keep using macFUSE and it actually has a higher priority (when using the “Automatic” setting) because it has been stable for quite some time. FUSE-T is still marked as experimental but in the last couple of weeks, its stability has increased tremendously. Installation/update is easy enough.
Then why do we recommend FUSE-T on Apple Silicon Macs? Because of the awful installation of macFUSE, which requires you to reboot and decrease a security setting in recovery mode. Many people hate that and wanted an alternative.
But if you’re happy with macFUSE, then keep using it.
1 Like
macOS Ventura 13.2.1
Apple M1 Pro Chip, MacBook Pro
Cryptomator 1.7.2 (dmg-4356)
FUSE-T 1.0.14
The Cryptomator vaults I use have a special structure. A GnuPG signature for each file in the vault is written to the directory .signatures in the top level of the vault’s directory tree. All files and directories I am talking about are understood as being in the unencrypted vault as presented by Cryptomator after opening the vault.
Creating, checking and updating signatures is manual and done with scripts. Other scripts compare the content of two vaults, show the differences (two methods used, diff --recursive --brief and rsync --checksum. Both methods read the full content of all files) and replicate the content of my master vault to the backup vaults.
Currently my vault contains 30.000 files, half of them being signatures. Using macFUSE 4.4.2 I checked the integrity of my vault. Then I switched to FUSE-T 1.0.14, closed Cryptomator, opened it again and did the same check on the same vault again. This time 21 signatures were reported as not matching. Another check immediately afterwards reported 45 files. The 21 files from the first run were not reported on the second run. Also some random manual checks of reported files did prove the signatures correct. Next I switched back to macFUSE and checked the vault again. No files reported bad signatures.
The times for checking macFUSE and FUSE-T mounted vaults are comparable. But checking two FUSE-T mounted vaults in parallel increased the time to 1h, up from less than 15 minutes with only one vault mounted. The owner and group membership for files in the vault has been corrected in this version of FUSE-T.
The vaults in the tests above were on the local filesystem of the MacBook Pro. Another test I made was with a copy of the vault on a USB-C memory stick. No problems when macFUSE mounted. With FUSE-T, two times the messages
nfs server localhost:/StickMasterCopy: not responding
nfs server localhost:/StickMasterCopy: alive again
appeared, but all files checked correctly.
My conclusion: FUSE-T looks promising. That might surprise after reporting how reading 30.000 files goes wrong in at least 21 cases. But to be fair macFUSE had the same problem a couple of years ago. The macFUSE developers worked on it and these problems are gone. I do expect the same from the FUSE-T developers and the poosibility to not depend on a kernel module is worth the effort.
1 Like
I also tested FUSE-T 1.0.15a with similar results.
1 Like
That let’s me stay at macFUSE and the latest 1.6.x Cryptomator
Thanks!
Also, will stay at Monterey for some time longer
@hoehenunterschied Would you be willing to make your tests again with Cryptomator 1.7.3? We fixed a criticial bug and I’d like to know if your observations were due to that bug or if there’s something in FUSE-T that we have to analyze/report.
I wasn’t able to replicate your test scenario so it’s hard for me to test that.