Mounting Remote File System With Rclone and Systemd Fails Because Unison?

Support and Help
,
1

tldr;

I tried using unison to sync local directories very recently but that didn’t work well for me since it was just too resource intensive. Finally I hatched a plan that I hoped might work but when I went to implement it I ran into errors (seemingly related to unison) and I don’t know where it’s coming from. I removed all its files - and it itself (unison) and reloaded the systemctl daemon, probably rebooted. Now when I try to start a service file to ran an rclone mount it fails. I recognize part of the path (the first part) as being a directory I used unison with before I removed it. I really need to clean this crap out of here so I can get a fresh start.

Output From systemctl --user status mega-storage-root-mount

~$ systemctl --user status mega-storage-root-mount
● mega-storage-root-mount.service - Rclone Mount for Mega Root Filesystem
     Loaded: loaded (/home/jake/.config/systemd/user/mega-storage-root-mount.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-02-24 23:49:38 PST; 18s ago
   Main PID: 11376 (rclone)
      Tasks: 17 (limit: 18812)
     Memory: 203.5M (peak: 205.1M)
        CPU: 864ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/mega-storage-root-mount.service
             └─11376 rclone mount MEGA:/ /home/jake/MEGA --allow-other --vfs-cache-mode writes

Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-plantuml/manifest.json: vfs cache: failed to r>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-plantuml/styles.css: vfs cache: failed to relo>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/data.json: vfs cache: failed to>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/main.js: vfs cache: failed to r>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/manifest.json: vfs cache: faile>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/styles.css: vfs cache: failed t>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/data.json: vfs cache: failed to r>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/main.js: vfs cache: failed to rel>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/manifest.json: vfs cache: failed >
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/styles.css: vfs cache: failed to >

What I’m trying to implement

I was looking for a solution to work with a remote filesystem (MEGA cloud storage) so I can work locally or through the web interface and things will stay in sync. After looking into a few different possibilities it occurred to me that mounting a remote file system (or directory in that file system) allows you to work on it locally or through the web interface and everything stays up to sync. So my brilliant idea was to let any directories I want to work with live in the remote filesystem and then mount them - that way I should be able to work with it the way I want. With that approach I though I could just use rclone to do everything and be set. I was trying to try my plan out when I saw the errors seemingly related to unison (which I used before this).

The Rclone Option
The Rclone Option1538×1700 112 KB

The Implementation

You can see the implementation notes I’m following here

  • I was able to verify the rclone config and the connection to the remote using rclone mount MEGA:/ /home/jake/MEGA --allow-other --vfs-cache-mode writes
  • I created the first service file with the following contents
[Unit]
Description=Rclone Mount for Mega Root Filesystem
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=rclone mount MEGA:/ /home/jake/MEGA \
--allow-other \
--vfs-cache-mode writes

ExecStop=/bin/fusermount -u /home/jake/MEGA
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target
  • Reloaded the systemctl daemon, enabled the service, started the service, checked the status of the service - with the following commands
systemctl --user daemon-reload
systemctl --user enable mega-storage-root-mount
systemctl --user start mega-storage-root-mount
systemctl --user status mega-storage-root-mount

And that’s when I ran into the errors shown at that top of this post.

Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-plantuml/manifest.json: vfs cache: failed to r>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-plantuml/styles.css: vfs cache: failed to relo>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/data.json: vfs cache: failed to>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/main.js: vfs cache: failed to r>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/manifest.json: vfs cache: faile>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/obsidian-to-anki-plugin/styles.css: vfs cache: failed t>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/data.json: vfs cache: failed to r>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/main.js: vfs cache: failed to rel>
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/manifest.json: vfs cache: failed >
Feb 24 23:49:48 nixbox rclone[11376]: ERROR : Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins/table-editor-obsidian/styles.css: vfs cache: failed to >

None of these files in the paths shown in the errors seem to exist. If I try to ls -al Obsidian/Personal/.unison..obsidian.b5a85a9aa1b525dc3c403390730b42d2.unison.tmp/plugins for example it will output no such file or directory. But yet its part of an error message effecting my service from running properly. What did I miss? Where is this coming from? And - especially - what should be done to solve the problem?

2

Because I’ve installed unison once I can now no longer use my system in other normal way that I could have before?

3

Been using unison for a few years.
While the 1st sync is intensive, subsequent ones aren’t,
except for new very large files (eg 10-20Gb file sizes).

The only thing you need to delete after uninstalling is ~/.unison.
doesnt leave anything else lying around.

Least resource intensive is rsync: but it only gives you a 1-way “sync”.
I use rsync to the cloud, unison to other machines.

1 Like
4

I suggest to check if there were any symbolic links left over after your attempts with unison. Symbolic links are like “hot” links, they look like a file in a place, but actually it is a link to a file somewhere else. One way that you can check them, is at a terminal cd to the folder that could have the symbolic link and issue:

ls -l
2 Likes
5

As suggested here before, the first time it synchronizes unison logically takes some time. Later it just does an incremental check, that is it only takes time synchronizing things that changed.

But I think it is important to clarify what exactly you want to achieve. In my opinion, there are three things that could be wanted:

  1. Working in mounted volumes. So you actually see the same volume in all systems but the actual data is in just one system. In this situation whatever you do in any system is automatically synchronized in all systems, but there is no actual synchronization taking place. If the volumes are in different networks a persistent and permanent connection is needed, like NFS or others.

  2. You synchronize with tools like unison (I don’t know rclone). In this case the data is duplicated (or triplicated, etc.) in the different systems. The synchronization is not automatic, at least for unison, you have to run the synchronization tool. I do this with my work desktop computer, my home desktop computer and my laptop. I use unison. My synchronization point is a server I have at home. Every night a unison process is run in my work computer. Whenever I start working in my laptop, or my home desktop or my laptop, I run unison in them to get what I did at work. When I finish working in them I have to remember to run unison to get synchronized with the synchronization point. This could be improved, so that I don’t forget, like running automatically unison when I shutdown the home desktop or the laptop.

  3. Having a backup of what you do in any system. This is not the case discussed here, I guess, but it is important to take into account that the synchronization is not a backup. I mean, if you erase data in any system it will get erased in all systems, unless you are having a backup in one of them.

3 Likes
6

I’ve been kinda exploring / trying different options. I was trying for something like 2 (I tried to convey it in this thread here but maybe not so well). Everything I have tried so far has had something that made it unviable. Sometimes mega just doesn’t work the way I expected it to or not have a certain feature. Most recently I have been trying to set up a combo of 1 and 3 (mounting specific directories from in the remote filesystem root and creating a backup. We did figure out the problem I was having with rclone but trying to sync all these things and stuff the way I was doing was a little complex for me.

Oh and I did figure out the problem with Unison. What was happening is there were some kind of systemd or other configuration files that were in the remote but not locally and kept syncing it back and causing the errors. I had to find the offending files in the remote and delete them is all.

Ohhh YEAhhh! And last night I did try the mounting remote directories approach and it worked but really REALLY simple small things (like running git status in a repository on the file system) took so long it just wasn’t feasible. Finally I’ve been relegated to living with a complete backup of my home directory to the remote - and that’s it - that’s all I get. This way at least if something happens I have that.

All the way from this radical and amazing idea that I could work seamlessly in these different systems to I’m lucky I got a backup. I don’t think it’s mega’s fault just… idk, sucks.

I have almost 3//4 tb on this machine - it was taking literally days with the laptop rapped out to the max and can’t do much else.

7

My original original first thought idea involved using sysmlinks. I thought I could simply mount the remote files system (the while thing) locally and the use symlinks to pull in sibling directories (sibling to the mount directory) into the mount directory - the remote file system. I thought that would allow me to realize seamless changes in any direction or whether I worked in the sibling directory itself or that directory in the remote file system. It started to look like it just didn’t work that way (the way I thought it did) so I scrapped that plan. Was I mistaken and that can be done?

8

Oh wow… there it is! All that stuff right there in ~/.unison. I got the thing to stop doing stuff but I didn’t realize that was there and it’s the most obvious thing. Thanks man.

9

I think a backup is always a must, your hardware or your software may fail and affect your data, so it is very important to be covered, unless you don’t care about your data.

10

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.