I just got back from vacation, went through the usual Windows updates, and tried to launch Obsidian, but it’s not working as expected.
Apparently, there are no command-line options? At least, I haven’t found any. Someone suggested restricted/Safe Mode, but I can’t enable it (see below). I can only get to the startup “mode” where I can select vaults.
How can I access my vault again, or narrow down the cause of the error?
What I’m trying to do
Open my Working Vault.
Things I have tried
First, as recommended, I renamed the Vault/.obsidian/community-plugins.json file - my Vault won’t start.
Then I created a new “Test” Vault that contains only an empty .obsidian directory, with no other MD documents. But that doesn’t work either - I’m back in the startup “mode” where I can only select vaults.
After that, I reinstalled Obsidian and restarted my PC - all to no avail.
I’ve now tried it on another PC (Windows 10 this time) at home and am having the same problem there. But I did notice something: In both cases, the vault is located on a network drive. My other vault, which is stored locally on the HDD, loads as usual, though.
Has something changed in this regard in the new version?
Security measures, probably.
Obsidian sort of treats your vault as a new, strange entity; it asks many questions now, e.g. when running URIs links, it presents a confirmation dialog that you need to okay.
Thank you. It doesn’t even ask. After the message saying that the extensions are loading, another one appears about opening/loading the vault, and then I’m back at the start screen - no confirmation dialog.
The bug report is complete, I just have a couple of more clues that may be useful (or not). Not trying to bounce this in any way.
I have this same issue, and it is on a network drive from another PC, not a Synology share. I reproduced the same fixes (deleting files, etc). I thought maybe it was a bad UNC path, so I mapped the shared drive as a local drive letter, and it still exhibits this problem. It can only make or open new files on a local drive. Same version 1.13.4 and exact same behavior. MacOS version seems to be working without an issue for me on same share but does ask for requisite permissions.