Cryptomator Version 1.4.10 (1374), FUSE for macOS 3.9.0, macOS Mojave 10.14.6 Beta (18G29g)
Today I made a strange observation which is reproducible on my system even after a reboot.In short: Only 3 out of 4 Cryptomator vaults can be unlocked at the same time. Unlocking the 4th vault does not give any error message, but the unlocked content is not mounted to the target directory. Strangely, locking one of the three unlocked and accessible vaults gets the 4th vault mounted.
- open any 3 of 4 Cryptomator vaults.
vault1: unlocked, mounted, accessible
vault2: unlocked, mounted, accessible
vault3: unlocked, mounted, accessible
vault4: locked - open the 4th Cryptomator vault
vault1: unlocked, mounted, accessible
vault2: unlocked, mounted, accessible
vault3: unlocked, mounted, accessible
vault4: unlocked, but not mounted
The ‘mount’ command in Terminal.app shows Cryptomator@osxfuse0, Cryptomator@osxfuse1 and Cryptomator@osxfuse2. No entry for the fourth vault. - closing one of the vaults, for example vault2 results in this situation:
vault1: unlocked, mounted, accessible
vault2: locked
vault3: unlocked, mounted, accessible
vault4: unlocked, mounted, accessible
‘mount’ in Terminal shows three entries. The entry for vault2 has gone, an entry for vault4 has been added. The entries are named Cryptomator@osxfuse0, Cryptomator@osxfuse1 and Cryptomator@osxfuse2 as before. - Trying to open the closed vault2:
vault1: unlocked, mounted, accessible
vault2: unlocked, but not mounted
vault3: unlocked, mounted, accessible
vault4: unlocked, mounted, accessible
closing one of the vaults1,3,4 will get vault2 mounted.
I use one Cryptomator vault to work with, the other ones are kept in sync by a script which I run from time to time. The unencrypted content of the vault is synced, not the Cryptomator vault files and directories. The script works with ‘diff --recursive’ to show what differs between vaults and uses rsync to apply changes. Today I observed an I/O error on one file when the diff ran. Trying to read the file again worked, the file was not damaged. Never observed an I/O error on a file in an unlocked vault before.