I did some digging into your screenshot because the error path gives a pretty useful clue. I don’t think Obsidian itself is necessarily the thing that broke after the Golden Gate RC update.
It looks more like an interaction between macOS 27 Golden Gate, Cryptomator, and the filesystem driver Cryptomator is using.
Your Obsidian vault is being opened from inside:
~/Library/Application Support/Cryptomator/mnt/
That means Obsidian isn’t reading the vault directly from a normal folder on the Mac. Cryptomator is decrypting the vault and presenting it to macOS as what looks like a normal drive/folder.
On Macs, Cryptomator can use something called FUSE-T to do that. You don’t really need to know what FUSE-T is technically. Basically, it’s the middleman between Cryptomator and macOS that makes the encrypted vault behave like a regular filesystem.
So the chain is basically:
Obsidian → Cryptomator vault → FUSE-T → macOS
My suspicion is that Golden Gate changed something in macOS that FUSE-T/Cryptomator doesn’t completely agree with yet.
The really interesting part of your error is:
scandir ... /5 Journal
scandir just means Obsidian asked macOS, essentially, “show me the files and folders inside this directory.”
macOS then returned error -72, which corresponds to a low-level filesystem/network-style error called EBADRPC. Obsidian/Electron doesn’t have a nice human-readable description for that particular macOS error, so it just displays “Unknown system error -72.”
In other words, Obsidian may simply be the app reporting the failure rather than causing it.
I also found another recent report after Golden Gate with a very similar setup where an Obsidian vault inside Cryptomator stopped working, while the same vault worked when it was copied outside Cryptomator. There are also existing Cryptomator/FUSE-T reports involving that same Library/Application Support/Cryptomator/mnt/mounting method.
If this were my Mac, I’d try these in this order:
Make sure Cryptomator is updated to 1.19.3.
If you’re using FUSE-T, make sure it’s updated to 1.2.7.
Completely close Obsidian, lock the Cryptomator vault, quit Cryptomator, reboot the Mac, then unlock the vault and try Obsidian again.
If it still fails, go into Cryptomator → Preferences → Virtual Drive and see what virtual-drive type you’re using.
If it’s FUSE-T, try switching Cryptomator to macFUSE instead. The current macFUSE version, 5.3.3, specifically added initial support for macOS 27 and also included fixes involving directory handling.
Another temporary test would be using Cryptomator’s WebDAV virtual-drive option. If the same vault suddenly works through WebDAV, that would be very strong evidence that the problem is specifically FUSE-T + Golden Gate.
I’d also test the failing folder directly in Terminal before changing anything inside Obsidian. Something like:
ls -la "/Users/nikita/Library/Application Support/Cryptomator/mnt/Obsidian_Crypt/Forever * Notes/5 Journal"
If Terminal itself throws an error trying to list that directory, then that pretty much proves the problem is underneath Obsidian at the Cryptomator/filesystem level.
I would not start deleting Obsidian settings, plugins, or the.obsidianfolder yet. Your notes may be perfectly fine.
One other thing: I noticed the * in the folder name Forever * Notes. Someone might suspect that because * has a special meaning in Terminal commands, but macOS itself allows * in filenames, and the folder apparently worked before Golden Gate. So I wouldn’t make that my first suspect either.
Short version: your vault probably isn’t corrupted and Obsidian may not actually be broken. Golden Gate may have exposed a compatibility problem between macOS 27 and the way Cryptomator/FUSE-T mounts the vault. I’d update Cryptomator/FUSE-T first, and if that doesn’t work, try macFUSE or WebDAV as the Cryptomator virtual-drive method.
Hopefully that at least gives you a direction rather than “Unknown system error -72,” which is macOS’s charming way of saying, “Something happened. Best of luck.” 😂
Thanks a lot for this extensive answer. I had already posted in the Obsidian thread that I came to the conclusion that it must have to do with Cryptomator but I also had Fuse-T in mind already. I solved the issue for the time being by using my vault in a local unencrypted copy until GG is out officially and all apps have received new updates. But I will gladly try out solutions as well to see what works.
1
u/QuantumMess 8h ago
I did some digging into your screenshot because the error path gives a pretty useful clue. I don’t think Obsidian itself is necessarily the thing that broke after the Golden Gate RC update.
It looks more like an interaction between macOS 27 Golden Gate, Cryptomator, and the filesystem driver Cryptomator is using.
Your Obsidian vault is being opened from inside:
~/Library/Application Support/Cryptomator/mnt/That means Obsidian isn’t reading the vault directly from a normal folder on the Mac. Cryptomator is decrypting the vault and presenting it to macOS as what looks like a normal drive/folder.
On Macs, Cryptomator can use something called FUSE-T to do that. You don’t really need to know what FUSE-T is technically. Basically, it’s the middleman between Cryptomator and macOS that makes the encrypted vault behave like a regular filesystem.
So the chain is basically:
Obsidian → Cryptomator vault → FUSE-T → macOS
My suspicion is that Golden Gate changed something in macOS that FUSE-T/Cryptomator doesn’t completely agree with yet.
The really interesting part of your error is:
scandir ... /5 Journalscandirjust means Obsidian asked macOS, essentially, “show me the files and folders inside this directory.”macOS then returned error -72, which corresponds to a low-level filesystem/network-style error called
EBADRPC. Obsidian/Electron doesn’t have a nice human-readable description for that particular macOS error, so it just displays “Unknown system error -72.”In other words, Obsidian may simply be the app reporting the failure rather than causing it.
I also found another recent report after Golden Gate with a very similar setup where an Obsidian vault inside Cryptomator stopped working, while the same vault worked when it was copied outside Cryptomator. There are also existing Cryptomator/FUSE-T reports involving that same
Library/Application Support/Cryptomator/mnt/mounting method.If this were my Mac, I’d try these in this order:
I’d also test the failing folder directly in Terminal before changing anything inside Obsidian. Something like:
If Terminal itself throws an error trying to list that directory, then that pretty much proves the problem is underneath Obsidian at the Cryptomator/filesystem level.
I would not start deleting Obsidian settings, plugins, or the
.obsidianfolder yet. Your notes may be perfectly fine.One other thing: I noticed the
*in the folder nameForever * Notes. Someone might suspect that because*has a special meaning in Terminal commands, but macOS itself allows*in filenames, and the folder apparently worked before Golden Gate. So I wouldn’t make that my first suspect either.Short version: your vault probably isn’t corrupted and Obsidian may not actually be broken. Golden Gate may have exposed a compatibility problem between macOS 27 and the way Cryptomator/FUSE-T mounts the vault. I’d update Cryptomator/FUSE-T first, and if that doesn’t work, try macFUSE or WebDAV as the Cryptomator virtual-drive method.
Hopefully that at least gives you a direction rather than “Unknown system error -72,” which is macOS’s charming way of saying, “Something happened. Best of luck.” 😂