Moritz Conjé
Das Rollenmodell aus den letzten Teilen dieser Serie beantwortet, wer im Second Brain mit welchen Rechten arbeitet. Offen blieb bislang eine ganz praktische Frage: Wo findet diese Arbeit eigentlich statt, wenn ich nicht am Schreibtisch-PC sitze? Das Second Brain lebt in einem Obsidian-Vault auf meinem Windows-Rechner – nützlich ist es aber nur, wenn ich auch von unterwegs damit arbeiten kann, mit echtem Zugriff auf den aktuellen Stand und nicht auf eine veraltete Kopie von gestern Abend.
Warum keine Kopie reicht
Die naheliegende Lösung wäre ein Sync-Mechanismus: Vault-Kopie auf ein zweites Gerät, Änderungen unterwegs, Abgleich beim nächsten WLAN-Kontakt. Für reines Lesen und gelegentliches Notieren würde das reichen. Für Arbeitssessions mit Claude Code aber nicht – hier sollen Änderungen sofort im echten Vault landen, ohne Merge-Konflikte zwischen zwei Ständen und ohne die Unsicherheit, ob die gerade sichtbare Version wirklich die aktuelle ist. Festgelegt habe ich mich deshalb nicht auf Sync, sondern auf einen Live-Mount: Ein separater Linux-Container greift über das Netzwerk direkt auf denselben Datenbestand zu, den auch Obsidian auf dem Windows-Rechner öffnet. Eine Änderung, egal von welcher Seite, ist sofort auf beiden Seiten sichtbar.
Die Basis: eine eigene LXC für Claude Remote
Technisch läuft das über eine eigene LXC (Proxmox-Container) namens claude-remote, unprivilegiert, Ubuntu 22.04, der im lokalen Netz erreichbar ist. Darauf läuft Claude Code über den nativen Installer. Der Zugriff läuft bei mir in der Praxis fast ausschließlich über die Android-App Termius: eigener SSH-Client mit hinterlegtem Key, damit lässt sich die LXC von unterwegs genauso ansteuern wie über ein Desktop-Terminal – die Claude-App mit ihrer eigenen Remote-Control-Funktion nutze ich mittlerweile kaum noch, SSH direkt reicht für den Alltag.
Der Netzwerk-Mount: Bind-Mount statt CIFS im Container
Der eigentliche Zugriff aufs Vault läuft über eine Windows-Freigabe auf dem TrueNAS-Server. Der naheliegende Weg, die Freigabe direkt im Container per CIFS zu mounten, funktioniert bei unprivilegierten LXCs allerdings nicht: Ihnen fehlen dafür die nötigen Kernel-Rechte. Der Ausweg liegt eine Ebene höher. Der Proxmox-Host selbst mountet die Freigabe (die Zugangsdaten liegen also nur dort, nicht im Container) und reicht anschließend gezielt nur die zwei tatsächlich benötigten Unterordner per Bind-Mount in den Container durch, nicht die gesamte NAS-Freigabe.
In der /etc/fstab des Hosts sieht das vereinfacht so aus:
//<nas-ip>/truenas-share/.../LLM-Wiki /mnt/llm-wiki cifs credentials=/root/.smbcredentials,_netdev,nofail 0 0Und die Durchreichung in den Container selbst:
pct set <container-id> -mp1 /mnt/llm-wiki,mp=/mnt/llm-wikiDamit sieht der Container ausschließlich /mnt/llm-wiki (und einen zweiten Ordner für sonstige Projekte), nicht den Rest der NAS-Freigabe. Ein Detail hat dabei unnötig Zeit gekostet: Der NAS-Unterpfad enthielt ein Leerzeichen im Ordnernamen, das in der fstab-Syntax als \040 escaped werden musste. Ohne diesen Handgriff bricht der Mount mit einer wenig hilfreichen „No such file or directory“-Meldung ab.
Erreichbarkeit von unterwegs: Tailscale statt Port-Forwarding
Im Heimnetz ist die LXC direkt per IP erreichbar. Für unterwegs braucht es mehr. Der bereits bestehende Reverse Proxy vor anderen Diensten im Homelab funktioniert hier nicht, weil er nur HTTP(S) auf Subdomains verteilt – SSH ist aber eine reine TCP-Verbindung, kein Web-Protokoll. Ich habe die LXC deshalb direkt ins bereits bestehende Tailscale-Netz aufgenommen, mit einer eigenen Adresse (clauderemote.tailXXXXXX.ts.net), erreichbar von jedem Gerät im selben Tailnet, unabhängig vom lokalen WLAN.
Ein Stolperstein dabei: Unprivilegierte Container haben standardmäßig kein /dev/net/tun-Gerät, das Tailscale zum Aufbau des virtuellen Netzwerk-Interfaces braucht. Die Freigabe muss – ähnlich wie beim NAS-Mount – vom Proxmox-Host aus erfolgen:
pct set <container-id> -dev0 /dev/net/tun,mode=0666
pct restart <container-id>Danach lässt sich der Zugriff von einem beliebigen Gerät mit aktivem Tailscale-Client testen, in meinem Fall erfolgreich sowohl vom Laptop als auch vom Handy aus verifiziert – kein lokales WLAN und kein separates VPN mehr nötig, um an die Arbeit im Second Brain heranzukommen.
Projektstruktur: ein Ordner, ein Chat, gemeinsamer Kontext
Zwei Dinge lassen sich hier leicht verwechseln: der Chatverlauf und das Vault selbst. Claude Code speichert jede Session-Historie getrennt vom eigentlichen Arbeitsordner, verknüpft nur mit dessen exaktem Pfad – nicht im Vault, sondern in einem eigenen, internen Verzeichnis. Das Vault dagegen enthält ausschließlich die tatsächlichen Ergebnisse: Notizen, Aufgaben, Artikel-Entwürfe, Beschreibungen. Weil aber jede relevante Erkenntnis aus einer Session am Ende ohnehin als Dokumentation im Vault landet, lässt sich der Kontext auch ganz ohne den rohen Chatverlauf schnell wieder erfassen – die eigentliche Substanz steckt in den Dateien, nicht im Gesprächsprotokoll dahinter.
Zusätzlich lädt Claude Code beim Start automatisch jede CLAUDE.md-Datei von der Vault-Wurzel bis zum aktuellen Ordner. Für die Arbeit am Second Brain reicht es deshalb, direkt im Wurzelverzeichnis des Vaults zu starten – der gesamte gemeinsame Kontext (Regeln, Infrastrukturwissen, bisherige Entscheidungen) wird dabei automatisch geladen, ohne einen zusätzlichen Schritt:
cd /mnt/llm-wiki/Homelab-LLM-Wiki
claudeEine Beispielsession
Konkret sieht ein typischer Arbeitseinstieg von unterwegs so aus: Tailscale-App auf dem Handy ist aktiv und im richtigen Tailnet angemeldet. Per SSH-Client (bei mir Termius) geht es auf claude-remote.tailXXXXXX.ts.net. Geht es um ein bereits laufendes Thema, hole ich mir per claude --resume "<Projektname>" genau diese Session zurück – unabhängig davon, wie lange die letzte Verbindung her ist. Für ein neues Thema wechsle ich stattdessen einfach in den gemounteten Vault-Ordner und starte frisch. Von dort aus läuft alles wie am Schreibtisch: Notizen lesen, Artikel-Entwürfe schreiben, Aufgaben im Second Brain anlegen oder verschieben. Jede Änderung landet direkt auf dem TrueNAS-Share – öffne ich anschließend Obsidian auf dem Windows-Rechner, ist sie dort ohne einen weiteren Schritt sichtbar, weil beide Seiten denselben Netzwerk-Speicher lesen, nicht zwei unabhängige Kopien.
Absicherung: Backup auf einen externen Server
Der Live-Mount hat eine Kehrseite: Es gibt keinen zweiten, leicht verzögerten Stand mehr, der einen fehlerhaften Schreibvorgang abfedert – jede Änderung landet sofort im einzigen echten Datenbestand. Deshalb läuft parallel ein täglicher TrueNAS-Cloud-Sync-Task, der das komplette Vault per WebDAV auf einen externen Server pusht – einen Nextcloud-Webspace außerhalb des eigenen Netzwerks, unabhängig von einem Ausfall der eigenen Hardware. Dieser Live-Abgleich läuft bereits produktiv; eine Erweiterung um ein echtes versioniertes Backup mit mehrwöchiger Datums-Historie ist angelegt, aber noch nicht zuverlässig im produktiven Einsatz.
Ergebnis
Der Zugriff aufs Second Brain ist damit nicht mehr an einen bestimmten Rechner gebunden. Getestet und bestätigt von zwei unterschiedlichen Endgeräten – Laptop und Handy –, jeweils mit demselben Ablauf: Tailscale verbinden, per SSH auf die LXC, direkt am echten Vault arbeiten. Kein Sync-Skript, kein Merge, keine Frage, welche Version gerade die aktuelle ist.
Ausblick
Für den nächsten Teil dieser Serie geht es wieder zurück auf die inhaltliche Ebene: wie über Web-Clipper, YouTube-Transkripte und Bücher überhaupt neues Wissen ins Second Brain hineinkommt.
