---
title: Obsidian REST Write Fix
area: infrastructure
tags: [infrastructure, automation, obsidian, assistant, health]
created: 2026-03-27
updated: 2026-03-27
status: active
related: [[Infrastructure/Architecture]], [[Infrastructure/Automation/n8n Workflows]]
---

# Obsidian REST Write Fix

## Summary

Fixed a shared-vault write failure affecting Obsidian Local REST API updates from the host side.

## Root cause

The shared vault at `will/will-shared-zap/` lives on a `virtiofs` mount and is written by two different users:

- host Obsidian / Local REST API user: `claw`
- VM assistant user: `openclaw`

That created asymmetric write access:

- VM-side writes worked in folders owned by `openclaw`
- host-side Obsidian REST writes worked in folders owned by `claw`
- collaborative folders like `Notes/`, `Plans/`, and `Infrastructure/` were mostly `openclaw`-owned, so host-side REST writes hung and timed out

## Evidence

Live behavior before fix:

- `PUT /vault/OpenClaw Checks/...` succeeded
- `PUT /vault/Notes/...` timed out
- `PUT /vault/Infrastructure/Automation/...` timed out
- reads continued to work

## Fix applied

Adjusted permissions on shared collaborative folders/files under:

- `Notes/`
- `Plans/`
- `Infrastructure/`

Pragmatic fix used: make the guest-visible collaborative paths writable by the host Obsidian side as well.

## Verification

Live checks after fix:

- `PUT /vault/Notes/test-postput.md` → `204`
- `PUT /vault/Infrastructure/Automation/api-tiny-write-test.md` → `204`
- full overwrite of `[[Infrastructure/Automation/n8n Workflows]]` succeeded → `204`
- read-back verification succeeded

## Follow-up

Current fix is practical, not elegant. A cleaner long-term setup would use a proper shared-group or host-side permission model instead of permissive fallback modes, but ACLs were not supported from the guest side on this `virtiofs` mount.

This permission issue may recur later if new shared folders or notes are created from only one side (`claw` on host or `openclaw` in the VM) without compatible write permissions. Now we know the failure pattern and the first thing to check: cross-user write access on the shared vault paths.
