A dumb way to mirror your nextcloud directories

Pardon the techie post. They happen from time to time.

This week I ran into a problem I wanted to solve with (and in) Nextcloud: directory mirroring between two different Nextcloud services.

Background

Nextcloud stores your files locally for your sync directories. You modify a file locally and the client you use for Nextcloud dutifully syncs it. Two problems if you want the data to be split across two instances for a cheap offsite mirror.

  1. The Nextcloud default client will not allow you to synchronize the same directory to two clouds, nor will it allow any subdirectories. If you want to sync $cloud-a/foo into cloud-b by adding cloud-a's subdirectory as an additional sync directory for cloud-b, the client will refuse.
  2. The client also refuses to follow hard links.

Since I'm not interested in running a continuous rsync or whatnot only to have duplicate files taking up disk space we are left with one thing...

the dumb solution

Bind mounts. What's more, since the offsite (cloud-b) copy is only for backup and access in case cloud_a goes down, it doesn't need to be written to. So in this scenerio we have:

In fstab we place something like this. Replace $PATHA and $PATHB with your source and target respectively:

$PATH_A/foo $PATH_B/foo none    bind,ro 0 0

When mounted your client will dutifly sync both as if they were native file systems. If anything gets modified by a client messing with cloud-b's foo mirror, they will not get synced back to cloud-a on this host unless you remount the directory as read/write1.

caveats

It's probably best to only do this with subdirectories in your synchronization tree. Nextcloud maintains sync metadata in the root directory in several hidden files. I haven't tested to see what happens when you do this and frankly I don't want to. If you're feeling adventurous let me know.

further notes and stunts

if you use cloud based encryption system such as gocryptfs, you can create your crypt directory in this manner. This allows you to have a somewhat reasonably2 encrypted copy of your data on a nextcloud server regardless of whether they have any of the encryption options turned on.

So you could do something like:

gocryptfs $cloud_a/foo $HOME/cloud_a_foo_clear

The second directory is the decrypted version of the filesystem. Both Nextcloud instances should only get encrypted data.

that's it

Use this as you like. I was mostly pleased that I could get around all these problems with the tried and true “add another layer of abstraction” solution. I have it on good authority that the bits eventually make it down to some physical layer and come back out consistently right.


  1. You can do this by changing bind,ro to bind,rw in your fstab or mount /path/b -o remount,rw on the command line.
  2. There's good arguments to some of the weaknesses of the gocryptfs format, namely that a supposed attacker could still gather structure of files and directories since the filesystem only obfuscates those by scrambling contents and names. You can tell this is not a post that's going to address the pros and cons of encryption and what tools to use by virtue of it being under 30 pages long. That'll be another blog post.

DrOS Logo
© 2021 Otto Skrzyk