Haha, that’s a good example, have you already located the config which you need to sync between vaults?
So as the help says
- Symlinking things under the
.obsidian/directory in order to share them between vaults has a high chance of corrupting your settings, unless you really really know what you’re doing. If you decide to go this way, at least have backups.
I just need someone who really really knows the configs! 
Done anyone know such guy? 
A list of all things/configs (inside .obsidian) that are safe to symlink between vaults would be much appreciated.
It blew my mind that I spent all this time setting up obsidian only to discover that it only works for the particular project I had open when I was setting it up. These are general application settings that have nothing to do with the project and have no business being scoped to the project. I can’t imagine why anyone would ever want to scope things like keyboard shortcuts and gui themes for one individual project. I expect an text editor to have the same basic behavior regardless of what text file I am editing. Look at literally any other test editor. Now I need to memorize a different set of keybinds for every single project? What kind of insanity is this? Can we please give users a reasonably consistent experience so they can have a realistic opportunity to learn how to use the application?
Forget about per-project configuration. It’s not important. Just move all the configuration to be globally scoped. That’s the simplest approach that the small dev team should be able to handle easily. Per-project configuration is a “nice to have” that can be added on top of global configuration, but it’s pretty limited in utility. I doubt the vast majority of users would be interested in it. So let’s not worry about the complexity from managing separate configuration sources for now. Just make it exclusively global. Should be trivial for established users to migrate settings from a project folder to a global folder.
7 Likes
Not everyone’s vaults are scoped to project level.
2 Likes
I have a simple command-line tool I wrote in Python a while ago to help manage the settings files in the .obsidian folder: Obsidian Settings Manager (OSM).
OSM can:
- list all your Obsidian vaults (I have more than three dozen, lol)
- copy settings from one primary vault to the other vaults
- execute a command against all vaults (e.g.,
git status)
I never made a big deal of announcing it, because the right way to do this is in an Obsidian plugin, rather than an external script.
But it is public and open source, and perhaps still of use. I haven’t updated it or stress-tested it in 1.5 years, but it still generally works. I can’t provide much user support for it, but I am happy to receive bug reports / feature requests in the OSM repo’s issue tracker, and would be happy to review pull requests. (Or to see it rewritten as an Obsidian plugin!)
Check it out: https://github.com/peterkaminski/obsidian-settings-manager
Please read the warnings and disclaimers before using Obsidian Settings Manager.
5 Likes
I realize a lot of the ideas below have been posted above, but it makes for difficult reading for half of this to be “as [username] said”.
$HOME/.obsidian
This will be exactly the same as the current per-vault directory, however all plugins and themes which are installed from any vault will have the actual js/css/manifest stored here. There will also be a data.json here, which will use the same developer API as the current per-vault one, just via Plugin.saveGlobalData/Plugin.loadGlobalData instead of the existing ones (no breaking change is an added bonus).
Also no workspace.json or other vault-dependent fields.
$vault/.obsidian
This remains mostly unchanged. The main difference will be that the plugins directories contain only the data.json file. It would be nice for plugin devs to have access to a Plugin.loadMergedData rather than being required to do their own comparisons and object merges should they need to handle hierarchy, which would also reduce plugin bundle size and execution times.
Changing and loading settings
Could do a deep merge on the JSON with every change, could do that with some fancy caching to save execution time,
Probably best to load the global configs, then iterate the local ones and set those for this app session. This ties in with the point below about global-first settings.
Additionally, when a setting is changed, no matter if local or global, Obsidian can just do what it’s doing now and set it on the fly without additional processing.
For storing the settings then, a toggle at the top of the settings subwindow (and other subwindows within such as themes or plugins) can have a simple toggle at the top for switching between changing globally and changing locally.
I would argue this should default to global, and if you close the settings then open them again, it should reset to global. To edit settings locally should require opening settings, and clicking a toggle.
My reasoning for this is because every other piece of software I’ve come across has global-only settings. People are used to changing a setting and it applying for all uses of the app. It’s the same reason content scrolls vertically and double-tap is like; everyone knows how it works, so working in the same way reduces friction. If a user changes something locally, works for an hour, then decides to change a setting, they won’t necessarily recall that they’re in local mode, even with the activated toggle.
The toggle should be labelled of course, “global settings” when off, “vault settings” when on, and an on-hover/focus tooltip on that text briefly explaining what it’s for an a link to the relevant section in the docs.
This toggle’s status should be made available on Plugin.vaultSettingsMode so plugin developers can have a signal for when their plugin might want to use Plugin.saveData vs Plugin.saveGlobalData.
It’s been two and a half years since this feature request was opened.
If developer time is an issue, I’ll happily come in temp and implement this for you as quickly as possible (email me).
If it’s a design choice to continue to not have this feature, that’s frustrating for a lot of us.
5 Likes
I want to have several vaults, but I want the same settings, keyboard shortcuts, plug-ins, etc. in each. Furthermore, if I change a parameter in one vault, I want to have identical settings in the other vaults. In other words, I want all settings to be global.
With this in mind, I have found a fairly simple solution that does not require installing any plug-ins. I have applied my solution to Windows. There are certainly analogous mechanisms available in other operating systems.
On my computer, I have created a Notes folder on my D: drive. In this folder I create further vaults. I currently have two vaults: personal and professional. The paths to the individual vaults look like this:
d:\Notes\personald:\Notes\professional
I created and configured one of personal vault. A .obsidian sub folder has been created in the vault. I closed Obsidian and moved this folder (cut and paste) to the main Notes folder. From now on, this is my main vault settings folder:
d:\Notes\.obsidian
Next you must perform the following actions on the command line. Run the Command Prompt as administrator. Now make junction point of the main settings folder to individual vaults:
mklink /j d:\Notes\Personal\.obsidian d:\Notes\.obsidian
mklink /j d:\Notes\Professional\.obsidian d:\Notes\.obsidian
A brief explanation for those who do not use Windows and are not familiar with this mechanism: junction point allows seeing the folder indicated in the second parameter also as the folder indicated in the first parameter. These folders can be on the same or different drives.
I want to be able to collaborate with other people on repositories & keep most settings at the repo level, but I also want to use vim keybindings without forcing everybody else to.
Obsidian having custom settings per vault is a great feature allowing for flexibility. However, it also means that every time I create a new vault I have to go through & manually set all my settings back to the way I prefer. I imagine most people will have their own custom default that they’d prefer to start new vaults with other than the “factory” default that Obsidian ships with.
It would be great if there was a “Make Current Settings Default” option that could be triggered. All new vaults created thereafter would use the settings that were enabled when it was triggered.
Also to aid in troubleshooting it would probably make sense to also include a “Restore Factory Default” settings ability.
I suppose another option would be for all new vaults to use the current vault’s settings. Most people will likely only make small changes from their preferred settings for any new vaults. It’s easier to remember what you want to change from where you already are, than it is to to get to where you want from an unfamiliar state.
18 Likes
The way I have been dealing with this is copying the .obsidian folder and obsidian.css in to my new vault.
Or you could duplicate the entire vault, change the name and then remove all notes inside.
Not idea, but it works well for me
8 Likes
seconding this request!
1 Like
+1
this default settings may contains:
plugins, themes, configs.
3 Likes
I would also find this very useful.
1 Like
Copying the contents of the .obsidian folder worked for me. Good one!
+1
It’d be good if a $HOME/.obsidian/ were replicated in each new vault…
3 Likes
This would be tremendously useful. It would allow for using the “Open folder as vault” option to effectively open a temporary vault to work within a given thought context.
For me, this would effectively solve the problem I outlined at Context Overwhelm, Concentric Vaults, and Sensemaking - Thinking On Thinking In Notes - #2 by realactualprice.
5 Likes
i have barely started to use obsidian but this is already the first feature i want that i was surprised wasn’t already a thing. i even tried closing all vaults and selecting the “Settings…” menu, thinking i might be able to set global defaults that way, but that just shows me a javascript error dialog (on mac).
for now i will copy the .obsidian folder. thank you for that tip! i hope someday this extra bit of friction can be reduced.
1 Like
Gonna throw my vote in for this as well. Was rather surprised it wasn’t already a thing.
2 Likes
Use case or problem
I want to have my configurations/plugins/themes all standardized between my vaults, making it machine-wide.
Proposed solution
Let us put the .obsidian folder outside of the vault (preferably in the Obsidian installation folder) and point our vaults to it allow us to have a machine-wide configuration.
Current workaround (optional)
Using symbolic links. It’s not user friendly or safe.
9 Likes
My other workaround is to have a script that copies the folders periodically across vaults.
Also not user friendly, but a little safer than managing a symlink.
1 Like