Bind-Mount rettet Symlink-Problem

Ausgangslage

Ich bin dieser Tage doch wieder von Zettlr zu Obsidian gewechselt, wollte es aber besser konfigurieren als vorher. Konkret wollte ich nur noch einen Vault für meine gesamten Daten.

Meine Daten speisen sich aus drei verschiedenen Nextclouds. Leider lässt es der Nextcloud-Sync-Client - übrigens völlig zurecht(!) - nicht zu, dass mehrere Clouds in denselben Ordner (zum Beispiel ~/Dokumente) synchronisiert werden. Aber wie werden alle Daten dann an einem zentralen Ordner abrufbar?

Symlinks kennt man als Linux-User, und so hatte ich auf diese Weise zwei der drei Nextclouds mit dem Hauptordner (welcher auch mit einer Nextcloud synchronisiert wird) datentechnisch verbunden. Bedauerlicherweise mochte das aber weder Obsidian, noch der Sync-Client ... Fehlermeldungen - Mist!

Aber natürlich gibt es mit Linux eine Lösung ...

Was ist eigentlich ein symbolischer Link?

Stell dir vor, du hast einen Raum mit Dingen drin (das ist dein echter Ordner, z. B. ~/Nextcloud2). Ein symbolischer Link (Symlink) ist jetzt so etwas wie ein Zettel mit einer Adresse darauf, den du außerhalb des Raums an eine Stelle legst, wo sich auch deine anderen Dinge befinden (~/Dokumente). Auf dem Zettel steht sinngemäß: "Das, was du suchst, liegt eigentlich da drüben im anderen Raum."

Ein Symlink ist selbst also eine eigene kleine Datei, die nur einen Textpfad zu einem anderen Ort enthält – eine Art Wegweiser. Das Betriebssystem folgt diesem Wegweiser jedes Mal automatisch, wenn ein Programm auf den Link zugreift. Wichtig: Der Symlink ist im Dateisystem sichtbar als eigenständiges Objekt. Viele Programme können den Unterschied zwischen "echtem Ordner" und "Symlink zu einem Ordner" erkennen.

Wenn ein Programm diesen Zettel liest, wird es automatisch zum angegebenen Raum weitergeschickt. Das funktioniert meistens gut – aber der Zettel ist eben nur ein Zettel, kein echter Inhalt. Manche Programme verhalten sich dann leider anders - manche folgen ihm nicht, manche zeigen ihn anders an, manche brechen bei zirkulären Verlinkungen ab. Das waren auch meine Problemlagen.

Was ist ein Bind-Mount?

Ein Bind-Mount ist etwas ganz anderes: Es ist kein Zettel, sondern so, als würdest du dem Raum einfach eine zweite Tür an einer anderen Stelle im Raum geben. Es gibt weiterhin nur einen Raum mit einem Inhalt – aber du kannst diesen jetzt über zwei verschiedene Türen betreten.

Für jedes Programm, das durch die zweite Tür (~/Dokumente/Nexcloud2) hineinschaut, sieht der Raum genauso aus, wie der Blick durch die primäre Tür (~/Nextcloud2) – und nicht wie ein Zettel, der erst noch woanders hin verweist. Das Programm merkt also gar nicht, dass es eigentlich über eine andere Tür hineinschaut.

Ein Bind-Mount funktioniert also komplett anders, als ein Symlink. Er hängt (im Sinne von "mounten") denselben physischen Datenbereich zusätzlich an einer zweiten Stelle im Verzeichnisbaum ein – auf Kernel-Ebene, nicht auf Dateisystem-Ebene. Es gibt danach keine "Verweis-Datei" irgendwo; der Zielordner (~/Dokumente/Nextcloud2) sieht für jedes Programm exakt so aus wie ein ganz gewöhnlicher, echter Ordner mit echtem Inhalt, weil er im Kernel tatsächlich derselbe ist wie der Quellordner (~/Nextcloud2). Es gibt keinen Pfad-Textstring, dem gefolgt werden muss; beide Pfade zeigen direkt auf dieselben Datenblöcke.

Warum ist das (für mein Szenario) besser als ein Symlink?

• Kein Risiko von Verwirrung: Weil es für jedes Programm wie ein ganz normaler Ordner aussieht, gibt es keine Sonderbehandlung, keine Warnungen, kein Risiko, dass ein Programm sich beim "Zettel lesen" vertut und etwas kaputt macht.
• Keine Zettel, die sich gegenseitig auf sich selbst verweisen können: Bei Symlinks kann es (aus Versehen) passieren, dass ein Zettel auf einen anderen Zettel zeigt, der wieder zurück auf den ersten zeigt – eine Endlosschleife. Bei einem Bind-Mount ist das strukturell gar nicht möglich, weil es kein "Verweisen" gibt, nur eine zweite Tür zur selben Kiste.
• Kompatibel zu Sync- (und Backup-) Programmen: Manche Backup- oder Synchronisations-Programme laufen dem Zettel hinterher und sichern den Inhalt dadurch versehentlich doppelt oder geraten durcheinander. Beim Bind-Mount passiert das nicht, weil es für solche Programme einfach wie ein stinknormaler Ordner aussieht.

Herstellen eines Bind-Mounts

Aufpassen muss man lediglich, dass man den Bind-Mount dauerhaft einrichtet.

In meiner NixOS-Konfiguration war das ein Eintrag in in der configuration.nix.

Der Eintrag zeigt wirklich sehr schön die Funktionsweise eines Bind-Mounts:

  fileSystems = lib.mkIf (config.networking.hostName == "HOSTNAME") {
    "/home/USERNAME/Dokumente/Nextcloud2" = {
      device  = "/home/USERNAME/Nextcloud2";
      fsType  = "none";
      options = [ "bind" ];
    };

Übersetzung:

Führe eine Änderung im Filesystem des Rechners mit dem Namen HOSTNAME durch:
  In den Ordner /home/USERNAME/Dokumente/Nextcloud2 soll
    der Ordner /home/USERNAME/Nextcloud2 wie ein Laufwerk
    ohne spezielles Dateisystem
    ge(bind-)mountet werden.

Danach ein Rebuild (ggf. via Git /Codeberg auch noch committen).

Unter Debian, Arch, etc. würdest du dasselbe Ergebnis manuell über /etc/fstab erreichen, z.B.:

/home/USERNAME/Nextcloud2  /home/USERNAME/Dokumente/Nextcloud2  none  bind  0  0

Danach einmal sudo mount -a ausführen (oder neu starten), und die zweite Tür steht.

Schreibt gerne in die Kommentare wo ihr Bind-Mounts einsetzt.