Normal locking blocks for "no reason". Options offered – force lock, retry, cancel – leads to Cryptomator hanging.

[davidleejy]

Please agree to the following

• [X] I have searched existing issues for duplicates
• [X] I agree to follow this project's Code of Conduct

Summary

As per title.

What software is involved?

• Operating System: macOS Sonoma 14.2.1 (23C71)
• Chip: Apple M3 Pro
• Cryptomator: 1.17-0 (dmg-5144)

Volume Type

Uncertain. I don't think I installed FUSE.

Steps to Reproduce

flowchart

restart["Restart machine"]
loginOS["Log in. No app windows are opened."]
unlockC["Unlock vault using Cryptomator GUI. <br>Click 'Reveal drive'. <br>Finder window displaying unlocked vault opens."]
restart --> loginOS --> unlockC
preview["Open one photo in Mac OS' Preview.app. <br>Close Preview. <br>Close Finder window displaying the unlocked vault."]
unlockC --> preview
lockC["Click 'lock vault' in Cryptomator GUI."]
preview --> lockC
lockblockeddialog[**Locking is blocked dialog**]
lockC --> lockblockeddialog
optretry["Select Retry option"]; optcancel["Select Cancel option"]; optforcelock["Select Force Lock option"]
revealdriveC["Select reveal drive"]
hang["Cryptomator hangs. Need to restart machine."]
lockblockeddialog --> optretry --> hang
lockblockeddialog --> optcancel --> revealdriveC --> hang
lockblockeddialog --> optforcelock --> hang

%% another scenario:
dontpreview[No interactions with files in the unlocked vault. <br>No clicks on files. <br>Close the Finder window displaying the unlocked vault immediately.]
lockC2["Click 'lock vault' in Cryptomator GUI."]
lockblockeddialog2[**Locking is blocked dialog**]
optforcelock2["Select Force Lock option. <br>Force locking succeeds. <br>Cryptomator does not hang."]
unlockC --> dontpreview --> lockC2 --> lockblockeddialog2 --> optforcelock2

Locking is blocked dialog: "Locking "my-vault-name" was blocked by pending operations or open files. You can force lock this vault, however interrupting I/O may result in the loss of unsaved data." Options offered to user: Force Lock, Retry, Cancel.

Expected Behavior

Normal locking should function smoothly esp. in the simple situation described in the "Steps to Reproduce" section.

Actual Behavior

Normal locking blocks with the dialogue:

"Locking "my-vault-name" was blocked by pending operations or open files. You can force lock this vault, however interrupting I/O may result in the loss of unsaved data." Options offered to user: Force Lock, Retry, Cancel.

Reproducibility

Always

[infeo]

@davidleejy Please update to the latest version of Cryptomator and try to reproduce the issue again.

[nickasd]

I'm having this issue as well with Cryptomator 1.12.0. Unlocking a vault, duplicating a file in it and trying to lock the vault again already results in the "Locking is blocked" dialog. The last time I tried I clicked Retry and then it worked. The time before, I'm not sure what exactly I did, but I ended up clicking on "Force lock", which first caused the Finder to hang, and eventually the whole macOS didn't respond anymore, forcing me to do a force shut down.

[nickasd]

By the way, is there a way to check if I have MacFUSE or FUSE-T installed, and what version? I cannot remember if I installed any of the two, it was last year.

[github-actions[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[davidleejy]

@davidleejy Please update to the latest version of Cryptomator and try to reproduce the issue again.

Hi @infeo,

Thanks for writing back and apologies for the delayed follow up.

Uninstalled and installed Cryptomator version 1.12.3 (dmg-5219). Installed FUSE. Sadly, this issue persists.

Operating System: macOS Sonoma 14.2.1 (23C71) Chip: Apple M3 Pro

[davidleejy]

I would like to inform the community that, in my experience, Cryptomator (recent version 1.12.3) is near un-usable on macOS Sonoma 14.2.1 (23C71) on the Apple M3 Pro chip. (Yes, I have FUSE installed.)

I tried to use Cryptomator to do a basic unlock, copy eight small (< 1 MB) photographs into the decrypted directory, before locking. To my surprise, the simple operation of copying the eight photographs caused Finder to hang (Finder is Mac OS default file explorer application). After force quitting Finder, I could not re-open Finder as it kept quitting seconds after starting. I left my machine in this state for about twelve hours, turned in for the night with the hope that the running processes behind the scenes, if any, would progress to a better state when I returned.

Unfortunately, after twelve hours, things remained in limbo.

To rectify matters, I had to restart my machine twice.

The first restart was a non-starter – my machine booted into a blank screen – and if I could be frank, this experience felt like a personal wake-up call to begin shopping around for Cryptomator alternatives. I shuddered at the thought of possibly needing to take drastic action like reinstalling the OS in the event that the filesystems got messed up.

The second restart, fortunately, restored matters to normality ("normal" as far as I could tell).

I don't know if the cryptomator vault I was interacting with has suffered any degree of corruption through this bumpy process, and would be grateful if someone could advise me how to ascertain this. It is not necessarily as straightforward as simply unlocking and locking the vault as this has led to issues in the past (see earlier comments in this thread).

While my ride with Cryptomator hasn't been ideal, I am glad that Cryptomator, its maintainers, and developers have built an open-source solution for cloud storage privacy and security.

Thank you for reading my experience, and have a great week ahead 😄

[simphide]

I would like to inform the community that, in my experience, Cryptomator (recent version 1.12.3) is near un-usable on macOS Sonoma 14.2.1 (23C71) on the Apple M3 Pro chip. (Yes, I have FUSE installed.)

I tried to use Cryptomator to do a basic unlock, copy eight small (< 1 MB) photographs into the decrypted directory, before locking. To my surprise, the simple operation of copying the eight photographs caused Finder to hang (Finder is Mac OS default file explorer application). After force quitting Finder, I could not re-open Finder as it kept quitting seconds after starting. I left my machine in this state for about twelve hours, turned in for the night with the hope that the running processes behind the scenes, if any, would progress to a better state when I returned.

Unfortunately, after twelve hours, things remained in limbo.

To rectify matters, I had to restart my machine twice.

The first restart was a non-starter – my machine booted into a blank screen – and if I could be frank, this experience felt like a personal wake-up call to begin shopping around for Cryptomator alternatives. I shuddered at the thought of possibly needing to take drastic action like reinstalling the OS in the event that the filesystems got messed up.

The second restart, fortunately, restored matters to normality ("normal" as far as I could tell).

I don't know if the cryptomator vault I was interacting with has suffered any degree of corruption through this bumpy process, and would be grateful if someone could advise me how to ascertain this. It is not necessarily as straightforward as simply unlocking and locking the vault as this has led to issues in the past (see earlier comments in this thread).

While my ride with Cryptomator hasn't been ideal, I am glad that Cryptomator, its maintainers, and developers have built an open-source solution for cloud storage privacy and security.

Thank you for reading my experience, and have a great week ahead 😄

I have exactly the same Issue and I also have a MacBook with an M3 Pro. Is it possible that this is a problem related to the M3 Pro Chip?

[infeo]

@simphide Since you are using WebDAV as the volume type, you experience a different issue.

[simphide]

@davidleejy Please update to the latest version of Cryptomator and try to reproduce the issue again.

Hi @infeo,

Thanks for writing back and apologies for the delayed follow up.

Uninstalled and installed Cryptomator version 1.12.3 (dmg-5219). Installed FUSE. Sadly, this issue persists.

Operating System: macOS Sonoma 14.2.1 (23C71)

Chip: Apple M3 Pro

@infeo he just installed FUSE to try to see if the issue persists - initially he used also WebDAV, or?

[infeo]

@simphide My bad, i read the `Volume Type" section wrong.

[davidleejy]

I don't believe I had used WebDAV at any time. I'm currently using MacFUSE which Cryptomator recommends for Apple Silicon chips 😄 .

Since I'm writing this comment, I thought it might be a good idea to share my Cryptomator experience since my last comment about a month ago on 2 May 2024. In the two times I had tried to use Cryptomator since, both times I encountered locking issues after I had triggered a copying of files into an unlocked vault. Finder would keep spinning on the file copying operation and would not terminate gracefully. The files, however few and small, could not be successfully copied into the unlocked vault when this happened. Both times I had to restart my machine after "force killing" the Finder application via Activity Monitor.

After a restart, the files could be copied, and the vault locking after the file-copying operation proceeded without a hitch.

This perplexed me and made me wonder if this bug had something to do with me airdropping my files from my iPhone after unlocking my Cryptomator vault. So, I spent a futile half an hour trying different sequences of airdropping files, and copying these files into my vault. I made sure to restart my machine so that it's a "clean slate" (well, probably as clean as most ordinary users can get) before attempting a sequence of vault unlocking, airdropping files onto my mac, and copying.

Regardless of the order of the sequence of events, performing file copying in to a vault after a fresh restart appears to be very stable – I could not run into a vault locking issue whether or not the files being copied had just been airdropped.

While my experiments are far from narrowing down the cause of the locking issue, I feel that the act of airdropping files onto my Mac is unlikely to be correlated with this vault locking issue.

@simphide Hmm.. I wonder if what you suggest might be true as there isn't a lot of activity in this thread which could be due to most users not running on an M3, a very new Apple silicon chip as at the time of this discussion. But really, I haven't got a clue to back up this hypothesis due to an unfamiliarity with how Cryptomator works behind the scenes.

[simphide]

I don't believe I had used WebDAV at any time. I'm currently using MacFUSE which Cryptomator recommends for Apple Silicon chips 😄 .

Since I'm writing this comment, I thought it might be a good idea to share my Cryptomator experience since my last comment about a month ago on 2 May 2024. In the two times I had tried to use Cryptomator since, both times I encountered locking issues after I had triggered a copying of files into an unlocked vault. Finder would keep spinning on the file copying operation and would not terminate gracefully. The files, however few and small, could not be successfully copied into the unlocked vault when this happened. Both times I had to restart my machine after "force killing" the Finder application via Activity Monitor.

After a restart, the files could be copied, and the vault locking after the file-copying operation proceeded without a hitch.

This perplexed me and made me wonder if this bug had something to do with me airdropping my files from my iPhone after unlocking my Cryptomator vault. So, I spent a futile half an hour trying different sequences of airdropping files, and copying these files into my vault. I made sure to restart my machine so that it's a "clean slate" (well, probably as clean as most ordinary users can get) before attempting a sequence of vault unlocking, airdropping files onto my mac, and copying.

Regardless of the order of the sequence of events, performing file copying in to a vault after a fresh restart appears to be very stable – I could not run into a vault locking issue whether or not the files being copied had just been airdropped.

While my experiments are far from narrowing down the cause of the locking issue, I feel that the act of airdropping files onto my Mac is unlikely to be correlated with this vault locking issue.

@simphide Hmm.. I wonder if what you suggest might be true as there isn't a lot of activity in this thread which could be due to most users not running on an M3, a very new Apple silicon chip as at the time of this discussion. But really, I haven't got a clue to back up this hypothesis due to an unfamiliarity with how Cryptomator works behind the scenes.

WebDav is the default option if you do not have Fuse installed.

I also usually airdrop my files that I copy into one of the cryptomator vaults, but the issue also occurs for documents that I have transfered via other methods to my Mac.

Does anybody know any other M3 Pro user who might be able to validate that this is chip related?

[davidleejy]

WebDav is the default option if you do not have Fuse installed.

I also usually airdrop my files that I copy into one of the cryptomator vaults, but the issue also occurs for documents that I have transfered via other methods to my Mac.

Does anybody know any other M3 Pro user who might be able to validate that this is chip related?

Users with Apple M1 and M2 chips are also welcome to comment if they're running into the same issue 🙂

[davidleejy]

@simphide

I believe I have narrowed down one cause of this bug and detail my findings here: https://github.com/cryptomator/cryptomator/issues/3401#issuecomment-2171269909.

In a nutshell, I observe that the sizes of the files being copied into a Cryptomator vault matter – large file sizes are more likely to hang Finder. Copying several small files (e.g. many 500KB .jpg files) is less likely to hang finder than copying one single large file (e.g. 8GB video file).

For anyone who is interested in testing this hypothesis out, the mkfile terminal command is your friend – mkfile is an easy way to create files of desired sizes. E.g. to create a single 8GB file, run mkfile -n 8g temp-file. The Finder application should be used to copy files (I haven't tried copying files into a vault without using Finder.)

[davidleejy]

Penning my observations and bug replication steps in the above comment inspired an attempt at a workaround by eschewing the Finder application during the file copying process.

First, I tried cp. cp was a success despite it printing this warning for every file copied:

cp: /path/to/large_files/temp-file: could not copy extended attributes to /Users/user123/Library/Application Support/Cryptomator/mnt/test-vault2/temp-file: Permission denied

Despite this,cp successfully copies files – verifiable by comparing checksum hashes (e.g., md5) of the original and copied files.

Googling the phrase "Cryptomator could not copy extended attributes" leads to discussions that suggest that the warning raised by cp is due to Cryptomator not supporting one or more attributes that Mac OS bestows on files. In these discussions, commenters suggest trying rsync. While I strongly prefer rsync over cp for transferring multiple varied files across different filesystems (e.g., in creating a remote file back-up) , unfortunately, rsync did not work in this instance.

After trying rsync with various options, the rsync options that got closest to working were -aP (i.e., rsync -aP source destination). An attempt at separately copying two 4GB files into a Cryptomator vault results in succeess for the first file (no errors raised), while the second copying operation hangs rsync. At this stage, Cryptomator cannot lock nor force-lock the vault. Killing rsync in its hung state does not resolve Cryptomator's vault locking problem. A machine restart had to be performed to get things back to normality.