Indexed Cryptomator volumes and CRASHING the whole Mac

Now, after I got my Mac Mini M1, I finally also got DEVONthink …

One of the first things I tried, was to index my mounted Cryptomator volume (which resides on OneDrive), which worked fine.

The second thing I tried, was adding a new file to one of those indexed folders.

I expected this to create either a new file that only exist within DT, inbetween the indexed files - or (what I has hoping for) the new file getting created in the actual Cryptomator volume.

This would have been perfect, allowing me to use DT as gateway to an encrypted volume on OneDrive, also circumventing the sad fact that OneDrive is not supported.

But …

But what happened was, that not only DEVONthink crashed, but the whole Mac!
It automatically rebooted …

Suspecting a one-time problem, I repeated the same and got the same crash.

Right now, i hesitate to do further tests.

What I originally wanted to test is this:

  1. Create a new file with DT within indexed folders
  2. Create a new file with Finder within the original Cryptomator folder
  3. Modify a file with DT within indexed folders
  4. Modify a file with Finder within the original Cryptomator folder

I can add more detail:

I also tried to modify a file from within DT …

And the Mac crashed again:

panic(cpu 0 caller 0xfffffe001b89019c): "Invalid mutex 0xfffffe23343ace30"
Debugger message: panic
Memory ID: 0xff
OS release type: User
OS version: 20C69
Kernel version: Darwin Kernel Version 20.2.0: Wed Dec  2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASE_ARM64_T8101
Fileset Kernelcache UUID: 3E6AA74DF723BCB886499A5AAB34FA34
Kernel UUID: 48F71DB3-6C91-3E62-9576-3A1DCEF2B536
iBoot version: iBoot-6723.61.3
secure boot?: YES
Paniclog version: 13
KernelCache slide: 0x0000000013b24000
KernelCache base:  0xfffffe001ab28000
Kernel slide:      0x0000000014664000
Kernel text base:  0xfffffe001b668000
Kernel text exec base:  0xfffffe001b730000
mach_absolute_time: 0x1580babcf5
Epoch Time:        sec       usec
  Boot    : 0x6008299d 0x000c2c5e
  Sleep   : 0x00000000 0x00000000
  Wake    : 0x00000000 0x00000000
  Calendar: 0x6008389e 0x000916f7

CORE 0 recently retired instr at 0xfffffe001b899798
CORE 1 recently retired instr at 0xfffffe001b89ac5c
CORE 2 recently retired instr at 0xfffffe001b89ac5c
CORE 3 recently retired instr at 0xfffffe001b89ac5c
CORE 4 recently retired instr at 0xfffffe001b89ac60
CORE 5 recently retired instr at 0xfffffe001b89ac60
CORE 6 recently retired instr at 0xfffffe001b89ac60
CORE 7 recently retired instr at 0xfffffe001b89ac60
Panicked task 0xfffffe167fc84c70: 3788 pages, 7 threads: pid 1104: TextEdit
Panicked thread: 0xfffffe166e22dfb8, backtrace: 0xfffffe308a5d3160, tid: 26871
		  lr: 0xfffffe001b77df8c  fp: 0xfffffe308a5d31d0
		  lr: 0xfffffe001b77dd58  fp: 0xfffffe308a5d3240
		  lr: 0xfffffe001b89ff5c  fp: 0xfffffe308a5d3260
		  lr: 0xfffffe001b891914  fp: 0xfffffe308a5d3310
		  lr: 0xfffffe001b7377e8  fp: 0xfffffe308a5d3320
		  lr: 0xfffffe001b77d9e8  fp: 0xfffffe308a5d36b0
		  lr: 0xfffffe001b77d9e8  fp: 0xfffffe308a5d3720
		  lr: 0xfffffe001bf183f8  fp: 0xfffffe308a5d3740
		  lr: 0xfffffe001b89019c  fp: 0xfffffe308a5d3760
		  lr: 0xfffffe001e5ef0f4  fp: 0xfffffe308a5d3830
		  lr: 0xfffffe001b9f76d0  fp: 0xfffffe308a5d3b60
		  lr: 0xfffffe001b9dd5cc  fp: 0xfffffe308a5d3db0
		  lr: 0xfffffe001bd7a5a8  fp: 0xfffffe308a5d3e40
		  lr: 0xfffffe001b8915f8  fp: 0xfffffe308a5d3ef0
		  lr: 0xfffffe001b7377e8  fp: 0xfffffe308a5d3f00
      Kernel Extensions in backtrace:[A70AF71E-4633-3BB8-B9A4-4A8F106AB7D1]@0xfffffe001e5ec000->0xfffffe001e5f3fff

last started kext at 3592959561:	3.0.1 (addr 0xfffffe001b664000, size 16384)
last stopped kext at 5190091113:	1.0 (addr 0xfffffe001b4d4000, size 16384)
loaded kexts:	3.0.1	3.0	20.036.15	8.0.2f9	1	11.5	4.0.3	11.0.0	1	1	5.0.0	1677.60.23	1.9	1	1	1	1	1.0.0	556.60.1	1	40	1.0.0	1.0.0d1	1	437.96	437.96	1.0.1	1	1	172.20.14	375	401.63.3	4.6.0	140.0	1	1.58	1	1	1	1	1.0.0d1	1.0.0d1	1	1.0.0d1	1	1.0.0d1	1	1	1.0.0d2	1	1.0.0d1	1.0.1	1	1	1	2.0.0	310	1	1.0	222	1.2.0	900.12	900.11	1.1.0	14.32	8.0.2f9	8.0.2f9	1	1	1	1	1.2	1	1.0.1	1	5.0.0	4.1.1	1.0.4	8.1.4	8.1.4	1.0.1	1.0.0	1	1.9	3	1	2.1.0	1	1.0.0	1.0.0	172.20.14	172.20.14	3.4.4	437.96	437.96	80.34	1.0.0	1.0.1	3.0	510.72	20.21.1	4.51.0	1	343.0.0	1	1	343.0.0	1.0.1	1.0	1.0	2.0.0	1	1.2	1	1.2	1.2	1	1	1	1	1.0.0	1.0.0	1	7.2.8	1	9.3.2	1	1	1	1	1	1.0.0	1200.12.2b1	1.0.0	1.0.4	1.0.2	1	1	900.11	493.0.0	585	8.0.2f9	8.0.2f9	68.5.0	1	1.0	2	511.60.2	184.40.6	2.9	436.40.6	436.40.6	1.0	28.30	1.0	1.0	1	1.2	1.2	1.0	3.1.9	1.0.0	1.0.0	1.0	1.0.0	1.0	1	1.0.1b8	3.4	11	1.0.1	1.0.2	1	2	2.0.0	1.0	1.0.0	1.0.0	1	1.0	1.17	1	265.0.0	289.3	1	4	300.0	1.0.0d1	1.0.5	1	3.0.0	1.0.1	1.0.2	2.1	1.0.0	47	1	11.1	1

** Stackshot Succeeded ** Bytes Traced 289453 (Uncompressed 712320) **
Panicked task 0xfffffe167fc84c70: 3788 pages, 7 threads: pid 1104: TextEdit

The kernel panic was caused by TextEdit but I doubt that TextEdit is actually the culprit. It’s more likely that it’s a bug of macOS (especially its WebDAV support according to the log) or Cryptomator.

I forwarded all 3 crash logs to Apple.
May send the last one to Cryptomator, too.

And no, TextEdit cannot cause a kernel crash :slight_smile:
WebDav kernel extension, if I read this correctly.

I would test it first without dropbox (using a Cryptomator volume with local files). If it still happens try a OneDrive folder without Cryptomator. This way you will know which application is causing this.

I have never had kernel panics when indexing files from OneDrive in the past (or other file-services for that matter), but haven’t use OneDrive for a long time now. OneDrive may still be based on WebDav, so it may be WebDav related.

Why does a webdav filesystem kext even come into play here? OneDrive doesn’t offer webdav access, afaik. … Ah, just a little googling around: There were in November last known problems with Cryptomator and Big Sur. They should be solved by Cryptomator 1.5.11, which should be used with a recent incantation of FUSE (4.0.4 is mentioned). It seems that you do not have this setup, since the webdav filesystem should only be the fallback if FUSE is not available.
There’s also a thread

on github concerning crashes with Cryptomator and WebDAV on Mac Silicon.

So maybe, just maybe, the problem is not DT.

1 Like

No, it is quite clear that this is from Cryptomator, as this seems to use WebDav to offer the unencrypted content which then get’s accessed by DT.

But it is surely not Cryptomator alone or itself, as I can use the volume quite normally without any problem!

It is something between DT and the WebDav Volume of Cryptomator and this run into some problem with the WebDav kernel extensions as it seems.

So the bug is most probably in macOS, but it is triggered somehow by DT accessing the Volume from Cryptomator.

And this is, why I was posting it here.

Ah, very interesing!

As i suspected, the bug in the kernel extension get’s somehow triggered by DT accessing the Cryptomator volume.

I did not have similar problems with Cryptomator itself or by using it’s volume.

I had this problem when creating or modifying a file, not as mentioned in the link.
But your link is still interesting, thanks.

I still fear, that only Apple can fix this.

I did a new test:

Changing a file in Cryptomator, without going over DT, also did crash the Mac!

I did not experience this so far, but then it may be because i used this on Windows ther last time I did change a file!

So, my assumption that Cryptomator itself and alone does work, was wrong! I think i had mistaken this with my last use from my Windows PC.

So, only either Cryptomator or Apple are to be blamed and DT is innocent.

Very good :slight_smile:
Thanks again for the link.

Ah ok, did not know Cryptomator uses Webdav. I use Boxcryptor, I do not have these issues with it.
Cryptomator seems to also work with Fuse, maybe that would solve the problem with Webdav? I’m not familiar enough with Cryptomator and the documentation only mentions Fuse but does not give any guidance.

1 Like

OneDrive still seems to work with WebDav, but this probably will not be used for syncing.

Let me know if you manage to get WebDAV to work with OneDrive on your Mac :wink: Seriously: WinSCP is a Windows program, and is a … let’s say not very good site. The so called description starts with

Visit the One Drive Developer center and Create New App

and it ends there, because I have no “One Drive Developer center” where I could create a new app. Even after locating it on the web, the whole exercise is far too convoluted (or would be, if it worked. Which I doubt). is badly made and just wants to market their WebDAV server in Colombia.

I agree, the sources are not the best. :slight_smile: I dit not search very hard because I think it is not that important. But yes, file access to OneDrive (and SharePoint) is based on WebDav. It is also the way you can for example access files directly from Explorer in Windows. I’m not following all recent developments in how MS Office reads and saves data to their online services, but my guess is it still uses webdav for that. I also would not be surprised if there is some Microsoft Sauce in the Webdav stuff on Windows ;).

If and how it would work on MacOS I do not know, but I’m willing to try. If it works I would not rely on it for using it with DT…

I’m not using Windows, but I very much doubt that they use WebDAV internally for their commercial products like sharepoint. From their own website:

Bei der Zuordnung eines Netzlaufwerks wird WebDAV verwendet, eine ältere Technologie, die langsamer und weniger zuverlässig ist als das Synchronisieren von SharePoint-Dateien mit dem neuen OneDrive-synchronisierungsclient.

WebDAV is ok’ish if you want to have a Finder/Explorer view or for CalDAV/CardDAV (small amounts of data), but there are certainly more performant alternatives, e.g. NFS.

WebDAV is not as slow as people might assume after using it in the Finder, e.g. cleaning a WebDAV sync store in DEVONthink is usually a fast operation. Doing the same in the Finder can last for minutes or even hours (depending on the server and the sync store).


There is also a difference in the MS365 and Personal OneDrive. So I’m not sure where WebDav is in the picture. It is still being used if you open the Explorer view in Windows from a SharePoint document library… but we are getting off-topic :slight_smile:

I agree, I use a WebDav server for syncing my databases and this is very fast.

1 Like

Someone from the Cryptomator community contacted Apple about that bug.

But DT seems to prefer WebDav.
And Cryptomator seems to use it to provide the mountable Volume with the un-encrypted content.

But what I noticed is, that by default, Cryptomator creates “Docany” not “WebDav” storage, which confuses me.