My Experience with "Lock Failed" Issues

Help Desktop App
1

I’d like to throw my hat into the ring on the ‘Lock Failed’ issues that seem a lot more prevalent since the deprecation of Dokany and now being set to ‘Automatic’ for volume type.

I’ve done some of my own homework on versions ranging from 1.7.5 to now 1.9.0 (on Windows 11 Pro/Version 22H2/OS build 22621.1778) and can join in the conclusion of images definitely being the source issue or where to aim at. Where I differ is that it doesn’t seem to be the actual opening of images or specific extensions that are the problem so much as thumbnails.

At first I thought Cryptomator had an issue with WebP, so I set those aside and brought in some standard JPGs. That worked. Then on a whim did some inner properties checking and used that ‘Folder pictures’ on the Customize tab and clicked & applied restore to default. I don’t know what exactly that does and it could be hit or miss on applying, but all the sudden the WebP images being in the Vault didn’t cause any problems.

Sometimes putting said problematic items that had a thumbnail into a New Folder in the vault would allow it to safely lock again and I just did my last test on switching to ‘Details’ view and while initially it had a problem on ‘Large Thumbnails’, cutting off the thumbnail functionality sorted it out.

This final test was spurred on by the most recently updated Github issue involving ‘Lock Failed’ problems. Except that, for me, switching directly to local still mostly didn’t matter.

I am a big fan of Cryptomator but this ‘Lock Failed’ issue is going to make my sporting attitude toward competition — I also use ProtonDrive — become a lot more narrow. It’s not healthy to suggest to your consumers that an encrypted local storage & cloud-assisting back up service should be treated with a pinch of hesitation and cynicism.

Because I also can’t stress enough how important it is to have stable & functioning software.

–
Day Later Update before I even got to finish posting this:

On a whim, I decided to search for the possibility of batch loading thumbnails — something i’ve hoped for on Windows anyway for years now — and came across a 3rd party program called WinThumbsPreloader

(A more up to date forked version of the original)

I started testing it on a single folder and then locking, then a few more, then a large batch, before finally getting all the items and folders I wanted done and now the Vault locks with no issue. I’ve also tested it on other Vaults I was having similar issues with and mass preloading thumbnails seems to have dealt with most of the symptoms. Solving the issue without this is another matter.

1 Like
2

I use 1.6.17 and I just moved two images and one .odt (libreoffice doc) into a vault and I got this error. I used to get this a lot with .exe files but now I always .7zip them to avoid this issue. I didn’t expect it with image files on a freshly formatted system.

This issue with the failed lock seems to be happening since at least 2021 (regardless of what might be causing it) and is probably the most commonly reported issue I think:

In case it helps anyone, I got past this failed lock by selecting all folders/files in the vault and right-clicked → properties. When the stats finished loading (i.e. number of files and total size), I could lock the vault again. If anyone else could confirm this worked for them that would be great.

1 Like
3

I’m still sorted for now with my method but thanks for providing another potential work around until this is fixed. Moving tons of data back and forth to figure out which might be the problem child ain’t exactly the most enjoyable computing task to be spending time on for a layman (SSD or not).

4

I have no lock issues EXCEPT when trying to lock a vault with pictures/photos (jpg, tiff, etc.). Only then do I receive the infamous “cannot lock” warning. When I try locking a vault containing only documents, that vault successfully locks every time. So, as an experiment, I copied one jpg picture into the properly functioning document vault. However, when I tried locking it, I had to employ the force lock route. As part of the experiment, I then deleted the jpg file. Presto, the vault locked with no problem. This experiment plays out every time exactly this way. The cannot-lock-vault problem thus seems connected to pictures/photos. I don’t have the knowledge to try to figure out why or fix the issue. Hopefully, though, this “bug” can be dealt with because it’s a great app and I would use it exclusively. Thus far, this is the only issue I’ve encountered.

5

Interesting. Could you please confirm whether your locking issue is solved by right clicking the specific file that causes a failed lock and selecting properties? If this works it might point towards the cause or to a possible solution.

6

I did end up having to employ your @Rcmtr ‘properties’ suggestion at least once so far but between it and my thumbnail preloading, i’ve still been set. It’s still not ideal and shouldn’t be a requirement, so I hoped it gets looked into within the next few releases of the software if any of the devs see this.

@DrM DrM I didn’t share anything that I don’t personally use or that is harmful so I recommend at least trying it out and see if both might help you. Though do be warned that its multithreading process is intensive… don’t just go for an entire drive unless your system can handle it. It definitely knows how to wake up my SSD and Ryzen 5 Processor.
If you do: regular preloading for a folder with no subfolder, recursively for entire drives or folders with a sub-folder or many sub-folders (or choosing multiple folders)

1 Like
7

Greetings, @goodec & @Rcmtr. On two separate occassions, I copied both an .exe & photos (jpg) to Cryptomater vault. Tried exiting the vault & lock. Failure to lock. Opened vault and right-clicked on photo. Clicked on properties then OK. Exited vault & tried locking. Vault locked. Process was repeated with the .exe file. Same results. I also copied several jpg files to vault. Highlighted them all then right-clicked and selected properties then OK. Exited the vault & tried locking. Failure to lock.

This error is repeatable with every attempt to copy jpg or exe files into a vault. For the vault to lock, properties of every individual file must be viewed. I’m not creating a vault for a whole disk or SSD. Just individual directories. This failure to lock issue is the primary issue, at least for me. It does concern me that if I force lock photo or executable file vaults, I could lose them.

2 Likes
8

Thank you for the detailed feedback @DrM. Just to add something in case it helps, the first time I discovered that the right-click → properties trick worked it was by trying it on the main folder that contained the entire vault with thousands of files. This could potentially mean that if selecting multiple individual files does not work the same as it does with single files, then selecting their parent folder might work the same as selecting an individual file.

9

Yeah, when I did it I shift clicked to the last file to include all files in the properties summation.

10

@Rcmtr. Thanks for the suggestions. Unfortunately, though I tried right-clicking on the parent folder then properties, that didn’t do the trick. Still fail to lock message. I also tried @goodec suggestion. That didn’t work for me either. Perhaps the next step is to create another vault, import a photo directory and right-click the parent directory prior to opening any of the imported files.

1 Like
11

That’s the thing… for my particular hypothesis, it’s not opening any specific file type that is the issue. It’s either the generating thumbnail process that is the problem — for any files, since I also had to remove broken exes with broken thumbnails from my online vaults during testing — or it hangs after it’s finished, and neither Cryptomator nor Windows (11) can recognize it and come to an agreement. My only conclusion with @Rcmtr suggestion working is perhaps it shakes something out of clogging or wakes up a related process.

For the record? I’ve redone all of my vaults as well following 1.9.0 (Hence my less than enthusiastic ending that i’d I tweaked to my OP before the update portion)
I felt it necessary but I didn’t know how much of a difference it would make in terms of taking care of any issues that were caused by new v. old from when I last installed… 1.6 something lol

I have another long-standing issue with Cryptomator and Google Drive that I intend to post about as well, but this really has to be resolved first since if I can’t lock anything now without worrying if it will work more than 70% of the time? That’s a bitter proposition that I don’t care to have. Might as well just try to learn how to create a native password-protected encrypted virtual disk within Windows, but I’d really, REALLY prefer to avoid that migraine as that’s what Cryptomator is supposed to be for both local AND cloud.

1 Like
12

I can confirm the behavior described here. So far I have not been able to determine that a file was damaged by the forced closing. Normally I don’t notice the behavior either, because I don’t close the vault individually, it happens automatically when Windows shuts down, but the message doesn’t appear, maybe the blocking processes are closed before Cryptomator or Cryptomator is unable to display the hint when Windows shut down.

13

Bumping so this doesn’t get lost.

14

I still stand by that opening specific extensions isn’t the core of the problem, but, this is another piece of the puzzle, so… it should be kept in mind at least.

Oh, and until Mfarooq addresses it? Just stick with WinThumbPreloader 1.0.6 in the releases. The latest (while having a slew of great upgrades), also set off Windows Defender when I tried downloading it. Likely a false positive but I don’t like messing with that stuff until proper statements are made.

15

I just tested again: The problem occurs on my system when I open jpg with the photo viewer supplied with windows, when I use gimp, paint, libreoffice etc. the vault can then be closed without any problems! Is it maybe because of this photo viewer?

16

Won’t know until more experienced eyes look further into this. Lately i’ve had to employ the properties workaround more, much to my annoyance. It’s definitely some kind of detail oriented issue.

False positive. No more problems with the latest Defender update and MalwareBytes cleared it.

17

Greetings. It’s been several months and another update, but still no fix for the failure-to-lock issue. In summary, for me, this occurs only after opening a image file. As long as I do not open an image, I can close Explorer and lock the vault. What have you heard about this issue since our June communication? Thanks!

1 Like
18

We adressed the issue in Cryptomator 1.11.0, which will be released very soon.

Edit: Cryptomator 1.11.0 is now released and can be downloaded from the offical Cryptomator web page https://cryptomator.org/

2 Likes
19

Forgot to mention that I have been using 1.11.0 since its release, waited to gave it a proper run, and I consider this solved. Much, much appreciated :+1::+1:

1 Like