Obsidian per-file permissions need a server that can say no

A permission is not a setting. It is a refusal. Something in the path between the file and the person has to be able to decline, and in a vault that is a folder on your own disk, read by an editor with no server and no accounts, there is nothing in that path at all. That is the whole reason this question is hard, and it is why the answers all look like more software than you expected.

Does Obsidian have per-file permissions?

No. There is no setting that makes one note readable by one person and invisible to another, and nothing in Obsidian Sync comes close. Obsidian's own collaboration help page states it plainly: "All collaborators receive the same permissions as the vault owner, with one exception: only the vault owner can invite collaborators." There is no viewer role, no per-folder scope, and no way to hold anything back.

So a shared vault is all of it. Your client folder, the salary note, the half-finished performance review, the API keys someone pasted into a scratch note in 2024. Everyone you invited has all of it, with edit and delete rights, on every device they own.

The oldest thread on this is from 13 September 2021, Multiple users with per file access permissions. Someone with a growing team asked for exactly this, worked through Nextcloud, Dropbox with a Python script, git submodules and SVN, got no answer from Obsidian, and said they were switching to Notion. Five years later the thread is still the top result for the question, which tells you how little moved.

Why can't a plugin just add permissions?

Some can, and this is where most advice goes wrong in both directions. A plugin cannot enforce anything by hiding files in your interface, because the files are already on your disk. If the bytes reached the folder, the permission failed before the plugin was asked. Hiding a note from the file explorer stops a glance, not a person, and certainly not a grep.

What a plugin can do is stop being only a plugin. The ones that actually work add a server, and the permission lives there, deciding what to send before anything is sent:

• VaultGuard Sync does vault, folder and file-level grants "enforced server-side", with role inheritance and a default-deny model. It is a Sustainable Use License, which is source-available rather than open source, free if you run it on your own AWS, and €12 per user per month managed. Its own documentation is honest about the cost: "Sync runs while Obsidian is active", and it "is not live collaborative editing or a background service".
• Vault Rooms has one device on your LAN host a small relay, and gives each room an access list per path pattern. The design detail worth copying is that a member "never receives content, or even filenames, for paths they cannot read". The catch is in the architecture: someone's machine is the server, and it has to be on.
• Relay includes "Role-based access control (private folders)" from its Starter tier at $6 per user per month, with free and $5-a-month tiers below that which do not include it.

The pattern is the point. Every working answer puts a server between the person and the file. Nobody has found a way around that, because there isn't one. The choice was never "permissions or no permissions". It is which server holds your team's notes, who runs it, and what the licence says.

What does a real per-file permission look like?

It looks like a question the server answers on every request, not a flag stored next to the file.

Baalda, which is the app this site is for, resolves access per document against its ancestor folder chain, every time. A folder grant flows down to what is inside it, a deny beats a grant, and the answer is one of three modes:

• Can edit, the open mode
• Can view, read-only
• No access, private

Access is written per resource and per audience. The audience is either everyone in the vault or a named list of people; the resource is a folder, a file, or the whole vault. Over MCP it is one call, which is the clearest way to see the shape:

{
  "tool": "manage_access",
  "resources": [{ "resourceType": "folder", "resourceId": "<folder id>" }],
  "audience": { "type": "users", "userIds": ["<their user id>"] },
  "mode": "private"
}

Read it as a sentence: this folder, this person, nothing. The call takes up to 1000 resources at once and is restricted to the vault owner and admins, so a member cannot widen their own access.

The files underneath are still plain markdown on your own disk, and two people can type in the same paragraph without clobbering each other, because edits merge at the keystroke rather than the file. That part is a separate problem from permissions, and we wrote it up in multiplayer Obsidian.

What happens to those permissions when an AI reads the vault?

This is the half nobody covers, and in 2026 it is the half that decides whether the permission survives.

Say you did the work. One folder is private, two are read-only, the rest is open. Then someone connects an assistant to the vault with a filesystem MCP server pointed at the folder. The Model Context Protocol project's own Local Server Security guide describes what that process gets: it "inherits your environment variables, can read anything your account can read", and the guide spells out what that covers: SSH keys, cloud credentials, browser profiles, your home directory. On the directory limits people assume are a boundary, it is blunter still: "Configuration-level allowlists are cooperative boundaries", respected by a well-behaved server and by nothing else.

So the permission you set is now advisory. The assistant reads the folder, because the folder is on the disk, because sync put it there.

The fix is not a better allowlist. It is that the assistant has to go through the same refusal the person does. In Baalda the MCP endpoint is a route on the server that holds the notes, and the gate is literally shared code: the comment at the top of permissions/http-gates.ts says the HTTP routes use "the SAME per-doc/per-folder ACL the MCP layer already enforces". A token is scoped to one user within one vault, so handing an assistant a token grants it exactly that person's reach and not one note more. list_notes returns "notes you can access in a vault" along with your permission on each, which means a private folder is not filtered out of a response that contained it. It was never in the response.

That is the test to apply to any of these products: not "can I set a permission", but "does the assistant hit the same check as the human". If the answer is that the AI reads the synced folder, you have file hiding, not permissions. More on the endpoint itself in MCP for notes.

Where this does not help

Three honest limits, because the pages ranking above this one do not state any.

Baalda is a different application, not an Obsidian plugin. Your markdown comes across as-is and leaves the same way, since it is the same markdown, but it is a new app for everyone to open. If your real constraint is that the team will not leave Obsidian, then Relay or VaultGuard Sync is your answer and we would rather say so than pretend otherwise.

No permission system retracts what someone already read. Revoking access stops the next request. It does not reach into a memory, a screenshot, or a copy somebody exported last month. VaultGuard says the same thing about its own revocation, and it is true of every product on this page, including ours.

Per-file permissions are a cost, not a free win. Every grant is a thing to maintain, and a vault where half the folders are private is a vault where search quietly returns less than people expect and nobody knows why. If your team is four people who trust each other, Obsidian Sync's all-or-nothing model is not a flaw, it is one less system to run. The case for this only starts when there is genuinely something that some of the team should not see.

The rest of the differences are on the Baalda and Obsidian comparison, and the wider argument for a vault a team shares is in what is a team second brain.