Obsidian Vault straight from Dropbox (`rclone mount`) - alias or systemd service

I keep my Obsidian vault in Dropbox, but without the Dropbox client. Instead of syncing tens of gigabytes to the laptop's disk, I mount the cloud folder as a directory and open it in Obsidian. This is done by rclone mount via FUSE — one command, no sync daemon, no local copy.

This post describes two approaches: an alias (simpler, manual) and a user systemd service (mounts automatically, recovers after crashes).

How it works

Dropbox (cloud)
   └── folder /Obsidian  (at account root)
         │
         │  rclone: remote "Obsidian", type dropbox, OAuth token
         │  rclone mount  →  FUSE (fuse3 / fusermount3)
         ▼
   ~/Obsidian            ← mount point (fuse.rclone file system)
         │
         ▼
   Obsidian opens this directory as a vault

A few consequences of this architecture worth knowing before deploying:

• There is no local copy. Files are read from and written to the cloud live over the network. After unmounting, ~/Obsidian is an empty directory and Obsidian won't see any notes.
• The Dropbox client plays no part. It doesn't need to be installed.
• No network means no vault. This is the main disadvantage compared to traditional sync — you can't work offline.
• Large files and attachments will be slower. Every open is a round-trip to Dropbox.
• The vault can be shared with other devices through the same Dropbox folder, but then conflict files appear (more on this in the problems section).

The key flag is --vfs-cache-mode writes. With it, rclone buffers writes locally (in ~/.cache/rclone/vfs/) and only then sends them to the cloud. Without it, Obsidian will crash — it opens files for writing and modifies them randomly, which the default mode doesn't support.

What to install

rclone and fuse

sudo apt install -y rclone, fuse3

Fuse on 26.04 is practically always already present. The needed binaries (fusermount3, fusermount) come bundled with fuse3.

Obsidian — use .deb, not AppImage

# download the current .deb from https://obsidian.md/download , then (note the "./"):
sudo apt install ./obsidian_*_amd64.deb

apt install ./file.deb instead of dpkg -i — apt will pull in dependencies automatically (including libxss1), rather than leaving the package half-configured and requiring a rescue sudo apt -f install.

Pitfall: Obsidian AppImage on 26.04

Don't use it, for two independent reasons:

1. The Obsidian AppImage is built for FUSE 2, but 26.04 ships FUSE 3 — it may not launch at all.
2. Since Ubuntu 24.04, kernel.apparmor_restrict_unprivileged_userns=1 is enforced, which breaks the Electron sandbox in AppImages (error: The SUID sandbox helper binary was found, but is not configured correctly).

Workarounds found online (--no-sandbox, sysctl …userns=0, chmod 4755 chrome-sandbox) weaken the security of the entire system. The .deb version is free of both problems — it ships its own AppArmor profile, which the system loads automatically on installation, and needs no hacks.

What you don't need: the Dropbox client, nautilus-dropbox (a GNOME extension, useless on Plasma), bindfs, sshfs, davfs2, or any crypt layer in rclone.

Configuring rclone

The entire configuration is a single remote in ~/.config/rclone/rclone.conf:

[Obsidian]
type = dropbox
token = <long JSON with OAuth token>

Choose the remote name deliberately — it's case-sensitive and will be referenced by both the alias and the service. Mine is Obsidian (capital letter).

From scratch

rclone config

Answers in the wizard:

Empty client_id/client_secret means you're using rclone's built-in, shared app ID. Pro: you don't need to set up anything in the Dropbox App Console. Con: the shared app ID can be rate-limited by Dropbox under heavy traffic — this comes back in the Baloo section.

Run the authorization in your user's graphical session, not via sudo — otherwise the token will end up in /root/.config/rclone/rclone.conf.

What the OAuth callback looks like

Rclone starts a local server at http://127.0.0.1:53682/ and tries to open it in the default browser via xdg-open. If the window doesn't open automatically (this can happen with Firefox from snap, which has restricted access to /tmp and localhost), don't panic — rclone will print the URL to the console. Copy it and paste it into the browser manually; the authorization will work the same way. If the callback is rejected, try the authorization in a non-snap browser or in headless mode (rclone authorize "dropbox" on another machine).

Without a GUI at all — the wizard will suggest the headless path itself.

Migrating from an old machine

My case was migrating from an old laptop to a new one, so I could take the quick option, which skips OAuth:

mkdir -p ~/.config/rclone
# copy rclone.conf from the old machine (scp / encrypted drive), then:
chmod 600 ~/.config/rclone/rclone.conf

⚠️ The token field is an OAuth credential granting full access to your Dropbox account. Treat it like a password: don't email it, don't paste it into chats, tickets, or repositories, don't commit it to git. Transfer via scp over SSH or on an encrypted drive, and after copying set chmod 600.

If after migration rclone reports token expired, invalid_grant, or HTTP 401 — refresh the authorization without losing the rest of the configuration:

rclone config reconnect Obsidian:

Verify the remote exists at all:

rclone listremotes        # expected: Obsidian:
rclone about Obsidian:    # should show Total / Used / Free

Method 1: alias in ~/.bash_aliases

The version I used for quite a long time. It has the advantage that the directory isn't mounted when you don't need it.
The entire "magic" is a single line:

alias mnt_obsidian="nohup rclone mount Obsidian:Obsidian ~/Obsidian/ --vfs-cache-mode writes &"

Add it to ~/.bash_aliases and reload the shell. Breakdown:

• nohup … & — runs rclone in the background and detaches it from the terminal so the mount survives closing the window. A side effect is a junk file ~/nohup.out in the home directory.
• Obsidian:Obsidian — remote Obsidian, subfolder Obsidian within it. The first part is the remote name, the second is the cloud path. To mount the entire account root, just use Obsidian:.
• ~/Obsidian/ — mount point.

Unmounting:

fusermount3 -u ~/Obsidian

Pros: two minutes of work, no system files, you only mount when you actually want to.

Cons: after every reboot you need to type the command manually. If the process dies (suspend, lost network), nobody will restart it.

Method 2: user systemd service

On the new laptop I switched to this and my only regret is not doing it sooner, since I use Obsidian frequently. The mount comes up on its own after login and restarts itself after crashes.

The ready-made unit file is in a snippet on Bitbucket as rclone-obsidian.service. Save it as ~/.config/systemd/user/rclone-obsidian.service — this is a user unit, not a system one. I discuss all the important directives below, so you don't need to read it blindly.

Activation:

systemctl --user daemon-reload
systemctl --user enable --now rclone-obsidian.service
systemctl --user status rclone-obsidian.service

The last command will immediately tell you whether it's working. In the correct state you'll see Active: active (running), and in the Status: line the current VFS cache state straight from rclone — including the number of files waiting to be sent to Dropbox.

Live log view:

journalctl --user -u rclone-obsidian.service -f

What matters here

Type=notify. Rclone supports sd-notify, so it tells systemd "I'm ready" only after actually mounting. This ensures services dependent on the vault don't start too early and see an empty directory. This also works with rclone 1.60.1 from apt.

%h instead of ~. Systemd doesn't expand tilde. %h is a specifier that substitutes the user's home directory — it makes the same unit file portable across machines and accounts.

Absolute path to the binary. Systemd doesn't use PATH the way a shell does. The choice of rclone installation method directly affects ExecStart:

Check yours with command -v rclone and use that exact value. Same for fusermount3 — on 26.04 /bin is a symlink to /usr/bin, so both paths work, but verify with command -v fusermount3.

Restart=on-failure + RestartSec=10. This is exactly what's missing from the alias approach: when rclone dies due to a lost network connection, systemd will bring it back up after ten seconds.

ExecStop with fusermount3 -u. Without this, stopping the service would leave a dead mount entry in the kernel, and ls ~/Obsidian would greet you with Transport endpoint is not connected.

Mounting without logging into a graphical session

By default, user services start on login and die on logout. If the mount should live independently of the session (e.g., to be available via SSH after a reboot), enable linger:

sudo loginctl enable-linger $USER

I didn't enable this myself — I only need the vault when I'm sitting at a logged-in desktop.

Alias and service — don't combine them

When the service is enabled, the alias becomes unnecessary and starts causing harm: trying mnt_obsidian on an already-mounted directory will fail with an error about a non-empty mountpoint.

Which approach to choose

The alias makes sense if you open the vault occasionally and prefer conscious control. For daily work, the service is clearly better.

KDE: disable mount indexing in Baloo

This is the most important difference between GNOME and KDE in this entire setup and the first thing to do after mounting.

Plasma runs the Baloo file indexer in the background, which by default indexes all of $HOME. Since ~/Obsidian sits inside $HOME, Baloo will treat it like a regular local directory and start crawling the entire vault over the network — reading every file to index its contents. The effects:

• constant, unnecessary transfer from Dropbox (with a vault measured in tens of GB, that's a lot of data),
• bloating VFS cache in ~/.cache/rclone/,
• sluggish mount and baloo_file_extractor processes eating CPU,
• in extreme cases, rate-limiting from Dropbox's side (easier to hit since rclone's app ID is shared).

On GNOME this problem didn't occur in this form, so it's easy to run into it precisely when migrating.

# Plasma 6 → balooctl6 (on Plasma 5 the binary is called balooctl)
balooctl6 config add excludeFolders ~/Obsidian
balooctl6 disable && balooctl6 enable      # reload configuration

# verify:
balooctl6 config list excludeFolders
balooctl6 status

Correct output:

excludeFolders:
    /home/sarniak/Obsidian/

If neither balooctl6 nor balooctl exists — Baloo isn't installed and this doesn't apply to you. Alternatively via GUI: System Settings → Search → File Search → add ~/Obsidian and set it to "Not indexed". You can also disable file indexing entirely (balooctl6 disable) if you don't use search in KRunner and Dolphin.

Connecting the vault in Obsidian

Launch Obsidian after mounting and in the welcome screen choose "Open folder as vault" → ~/Obsidian.

The order matters doubly: mount before starting Obsidian, and exclude from Baloo before the first extended vault session — otherwise the indexer will start downloading everything in the background before you even notice the problem.

Plugins, themes, and settings don't need to be transferred. They live in ~/Obsidian/.obsidian/, which is inside the vault, which is in Dropbox — they'll arrive on their own when the remote is mounted.

Verification

I've collected all checks in the obsidian-mount-check.sh script in the same Bitbucket snippet. Run it after mounting:

./obsidian-mount-check.sh

The script doesn't change anything, doesn't need sudo, and exits with code zero only when all ten checks pass: rclone presence, remote existence, Dropbox response (which also catches expired tokens), mount directory, kernel mount entry, live rclone process, non-empty vault contents, systemd unit state, and two checks specific to KDE and Debian — vault exclusion from Baloo and whether Obsidian comes from .deb rather than AppImage. On other systems, those last two report "not applicable" instead of raising an error.

If you'd rather check manually, the essence is four things: fuse.rclone type for the vault directory, sensible size in df, a live rclone mount process, and visible notes after ls. If all four check out — it works.

Common problems

Slow performance, stuttering on large files

Partly inherent to the architecture — files travel over the network, and --vfs-cache-mode writes only caches writes. On KDE, first check Baloo and Dolphin (below), because they're usually the culprit, not the rclone flags themselves. If it's not that, consider:

• --vfs-cache-mode full — caches reads too; reopening files is much faster, but uses space in ~/.cache/rclone/,
• --dir-cache-time 24h — less frequent directory listing queries,
• --poll-interval 15s — how quickly the mount notices changes made from another device.

KDE: constant transfer and baloo_file_extractor on CPU

Baloo is indexing the mount — go back to the Baloo section. Diagnostics:

balooctl6 status
ps -ef | grep [b]aloo
balooctl6 config list excludeFolders

Limitations (deliberate trade-offs)

• No network means no vault. This is the fundamental difference from the Dropbox client or Obsidian Sync, which keep a local copy. If you need your notes on a train, this setup isn't for you.
• Data in the cloud is stored unencrypted. You can change this by adding a crypt type remote, but then you lose the ability to read notes through the Dropbox web interface and from devices without rclone.
• The OAuth token in rclone.conf means full access to the account. File permissions of 600 are the minimum; the token can be invalidated by changing your Dropbox password or revoking app access, so keep rclone config reconnect handy.
• Rclone's shared app ID can be rate-limited. Under heavy traffic, it's worth creating your own app in the Dropbox App Console and entering the client_id/client_secret.
• Rclone from apt is old. On Ubuntu 26.04 it's still 1.60.1. The newer upstream has many fixes specifically in mount/VFS.

Summary

The entire mechanism is a single rclone mount command and one remote in the rclone configuration. An alias in ~/.bash_aliases is enough to get started and is essentially free, but after every reboot it reminds you of its existence. A user systemd service is one more file and one enable — in return, the mount appears on its own, restarts itself after crashes, and logs to the journal where you can check what went wrong.

If you're doing this on KDE, do two things right away, because otherwise you'll waste half a day on them: exclude the vault from Baloo indexing and install Obsidian from .deb, not AppImage.