Unable to open a some images

Help Desktop App
1

Yesterday I noticed I was unable to open a few images that I had placed inside a CryptomatorVault some time ago. When I try to open the image my image viewing program only shows a corrupted image placeholder, not the actual image.

I started investigating the problem. First I tried to calculate a checksum for the files (md5 and sha1), but that failed as well. I get an error message saying “Input/output error”.

I’m using pCloud as a storage provider. pCloud provides a convenient pCloudDrive-folder where the data on the servers is mounted in a local folder. So, I opened the vault directly form the pCloudDrive-folder and the images opened just fine. At this moment I suspected the problem was caused by a faulty synchronization done by pCloud’s application. So I ended up contacting pCloud’s support. I also synchronized the files to my other computer and the files opened fine there as well. This would support the idea of faulty synchronization. At the moment I’m still waiting a reply from pCloud’s support.

After this I went to back to my desktop computer (where the problem originated from) and started checking the logs. When I try to open the files I see multiple errors in cryptomator’s log files (long stacktrace replaced with dots).

12:17:44.550 [Thread-3046] ERROR o.c.f.fuse.ReadOnlyFileHandler - Error opening file.
java.io.IOException: Error opening file: /home/matti/Documents/pcloud/CryptomatorVault/d/7P/USQWPBAKILCYOB7VUIJRAU6MYJE4U2/76QJAGD2ZVORDJMXQQKKT7KZHXOO5ZZKYCWIMPOFZ45NB5SYQIXBZX7PYCHM6OMKPWNE4===
..... 
Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException
.....

I am able to calculate a checksum for the encrypted file mentioned in the logs. I turned on debug-mode for cryptomator, but the logs don’t seem give me much else to work with.

Now here’s where things got weird. I decided to mount the vault as read-only. At first things did not change. I was still unable to access the images. I locked the vault and unlocked it back in normal read-write -mode. Somehow this temporarily fixed the issue and I was now able to open the images. The problem wasn’t completely fixed though. When I locked the vault and unlocked it again the problem reappeared. Now contrary to what happened first I now seem to be able to access the images while in read-only -mode and sometimes in read-write mode, if open the vault right after it was opened in read-only mode. These contradict my earlier suspicion that this problem was caused by synchronization issues.

Both of my computers are running Ubuntu 18.10 and Cryptomator AppImage version 1.4.6. I’m mounting cryptomator vault as a FUSE volume. I’ve had some issues with dav and webdav, so I tend to use FUSE. I believe my webdav-problems are unrelated to this problem, and more related to my desktop environment (Plasma). I did manage to get webdav working fine using XFCE. When I did manage to mount the vault using webdav at least at one point I did encouter this same issue with the images. That would indicate the problem is not with FUSE.

I’d appreciate any ideas and views on this matter.

2

I’ve made some progress with this matter…

I backed up everything by using Cryptomator’s read-only mode, just to be sure. Then I did some checks using the sanitizer. Sanitizer gave me three errors like this one:

ERROR ContentMismatch file: m/4H/77/4H77J3ZKFV3BVM7JVEBSXPR5QTUEKTYE.lng expected: name with decryptable part actual:

I was unable to decrypt these three files using the sanitizer. But by looking at the structure each of these files are really small (130B, 130B and 162B). I don’t know whether that makes any difference. I have no idea whether a single encrypted file represents a single non-encrypted file.

As I was able to access the files in read-write mode by using pCloud’s pCloudDrive -folder I took the problematic images out of the vault. After doing this I no longer have any problems with mounting the vault in read-write mode. I ran the sanitizer again after doing this and the results are exactly the same as before. Therefore the errors reported by sanitizer are likely to be unrelated to this issue.

I did manage to get around the problem, but I’m still unsure why the situation happened in the first place. My confidence to Cryptomator took a big hit, and I will likely re-evaluate how I want encrypt my files in the future.

3

This AccessDeniedException is a clear indicator that there is a permission problem on the storage location of the vault. Can you check (recursively) if all encrypted files are accessible by the user who runs Cryptomator?

That is expected. The .lng files actually only contain the encrypted filenames of some files with really long names, the file contents are stored within the d directory.

Agree.