A shared vault has no concurrent editing
A local file notes application locks nothing on a shared network drive: a public report documents a settings folder that gets overwritten between users on this kind of mount, and the same mechanism makes plausible, without the source itself documenting it, the silent loss of a note edit.
A local file notes application, the kind that files each memory in a separate markdown file as the first lesson of this module described, locks no file when it opens it. It relies on an operating system feature that watches a folder for changes to know that another machine has just written to the same note, and to offer a merge. A user on the application's help forum describes exactly this problem on a shared network drive, a drive letter pointing to a remote folder rather than the machine's own disk: her tabs and settings folder get overwritten by a colleague's on the same mount, without warning.
What the report documents, and what it does not
The thread precisely describes the settings folder, shortcuts, open tabs, appearance: each machine writes its own version at startup and wipes out the previous machine's version on an emulated network drive. Extending this same mechanism to a note's content remains a reasonable extrapolation, not a fact this thread documents: no line in it mentions a note paragraph being replaced, a lost file lock, or folder watching failing when applied to content rather than settings. The risk described below therefore still needs to be verified independently before it is treated as established.
Scénario plausible, non documenté par la source :
Avant les deux sessions : note-adherents.md, 3 lignes
Session 1, poste du bureau, 9h00 : ouverture, ajout d'une ligne, enregistrement, 4 lignes
Session 2, poste portable, 9h20, ouvert avant l'enregistrement de la session 1 :
ajout d'une autre ligne, enregistrement, 4 lignes, la ligne de la session 1 a disparu, aucun message
The fix is human, not technical
The thread reports no technical solution coming from the application itself: the workaround its author describes is to ask colleagues to close the application before saving. For a note, the same logic translates into a simpler rule to hold: decide, before writing, who is the sole author of a shared note while everyone else consults it without changing it. A note that rarely changes can be shared without any particular rule; a note that several people fill in on the same day, meeting minutes or a membership list being updated, needs a named author.
Two ways to share a notes folder
Each person works on their own local copy, synchronised by a tool that merges changes and flags a conflict when two versions genuinely diverge.
No local copy and no merge mechanism: the settings folder already gets overwritten without a documented message, and an edit made while another machine has the same note open could disappear the same way at the next save, a plausible but undocumented risk in the source.
An association secretary opens the membership note in her notes application, on the office computer connected to the association's shared folder through a network drive, and corrects a member's address at nine o'clock. She reopens the same note twenty minutes later on her personal laptop, connected to the same network drive, adds a new member at the bottom of the file, then saves.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: It establishes that the same note was opened and edited from two separate sessions, twenty minutes apart, on a folder mounted as a network drive, one in the morning at the office and the other from the laptop.
What this does not establish: It does not establish whether the address correction made at the office still appears in the file after the second save, nor whether the two changes coexist in the final note.
The three most common miscalibrations
- Too broad This situation shows that a network drive systematically wipes out any note edited twice on the same day.
- Too narrow This situation only concerns the new member added from the laptop, the address correction made that morning does not count.
- Beside the point This situation shows that a shared folder on a network drive makes remote work easier for the whole association.
- A network drive is a folder mounted on a remote server and reachable from several machines at once, it is not a local copy synchronised by a version tool.
- A public report documents the application's settings folder, tabs and preferences, overwritten without warning when several machines share the same network drive.
- Extending this same flaw to a note's content remains a reasonable extrapolation and not a fact this source documents, since it only talks about tabs and settings.
- Naming a single author for each shared note costs less than reconstructing a change that vanished without warning.
Check today whether the folder holding your shared notes is mounted as a network drive rather than synchronised by a version tool: if it is, choose a single author for the next note several people will touch, and write their name at the top of that note before starting.
These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.
- Check on your own machine whether the folder holding your shared notes is a network drive, a drive letter pointing to a server, or a local folder synchronised by a version tool: the risk described in this lesson only applies to the first case.
Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.
- Obsidian help forum, multi-user cooperation over a shared network vault consultée le 2026-09-02
- Obsidian help, vault types, official guide with no warning about network drives consultée le 2026-09-02