Following up on the --lan-origin fix one more request in the same spirit of exposing more of what Replicaro + rclone already offer under the hood.
Right now Replicaro surfaces rclone-backed remotes only for the big 3 (Dropbox, Google Drive, OneDrive). rclone itself supports a much wider set of backends, and two I’d genuinely use are WebDAV and FTP. Plenty of free and commercial storage/hosting providers expose WebDAV access rather than an S3-compatible API. There’s a real chunk of existing storage out there that’s reachable that way. FTP is something I use in my home network, since my router can act as a NAS when I connect some storage to it, giving me FTP access.
A lightweight way to cover this without building dedicated UI for every backend: let Replicaro read an existing rclone.conf (e.g. via a mounted file/path) and list whatever remotes are defined in it as selectable vault targets. The user sets up the remote themselves with rclone config (rclone’s own CLI already handles WebDAV/FTP auth and backend-specific options), and Replicaro just consumes the result. That keeps the maintenance burden on your side close to zero, the actual backend logic stays in rclone, where it’s already implemented and kept up to date. While advanced users get access to anything rclone supports, not just the three you’ve built dedicated flows for.
Happy to test this if it’s something you’d consider for 1.0.x.
I thought about this while designing Replicaro. I ultimately did not go with supporting all Rclone remotes because I do not want to release support for a cloud drive/remote that hasnt been fully tested. Rclone has so many that I couldn’t possible test them all. Let me think about this – perhaps I could add an “advanced” destination where Replicaro is pointed at the rclone.conf and just uses that.
Let me think about this – perhaps I could add an “advanced” destination where Replicaro is pointed at the rclone.conf and just uses that.
Would be perfect for [advanced] users like me: Im already using rclone and have got my favourite 5 remotes configured.
The bigger Replicaro will become in the future, the more users will request all kind of cloud services as vaults anyway (mega.io and MagentaCLOUD and infomaniak kDrive and InfiniCLOUD etc etc)
Rclone.conf can be anywhere on your computer or in docker except for in Replicaro’s data folders (where Replicaro keeps cache, binaries, etc.). Replicaro just needs read/write access to rclone.conf in case Replicaro’s rclone refreshes login tokens. Otherwise, Replicaro doesn’t touch your rclone.conf
This is not what I meant. I have my own rclone.conf with 5 remotes in it. I would like to volume mount this into the Replicaro container, so Replicaro knows my remotes and I can just use them. Where inside the container does this volume mount need to point at?
Besides that, I have successfully created a new WebDAV vault with Replicaro. But I can not create a backup job / add source data. I have done a volume mount for my /home directory:
-v $HOME:/var/lib/replicaro/home
But Replicaro cannot open that folder „permission denied“ because the docker container is running as user ID 10001 and that user does not have access to that directory. I would prefer if Replicaro was root or UID 1000 please.
That said: Id be happy to continue testing. Cheers, Jan
For rclone.conf: there is no fixed path — mount the folder holding your rclone.conf anywhere outside /var/lib/replicaro, writable, e.g. -v $HOME/docker/volumes/rclone:/data/rclone, give UID 10001 read/write on it, then enter /data/rclone/rclone.conf when creating an “Any Rclone Remote” vault.
For the other issue, please don’t mount over /var/lib/replicaro/home. That’s Replicaro’s own home inside its state volume. Use e.g. -v $HOME:/data/home:ro, and grant UID 10001 read access (setfacl -R -m u:10001:rX …) or mount only the folders you want backed up. Running as a different UID is something I’m looking at for next release.
Thanks for all your help in smoothing the rough edges!!!
v1.0.5 will now run the docker container as root with options to run as a different UID if the user wants to. it should be released either tonight or tomorrow, regression testing is taking a bit longer than expected
v1.0.5 is out. Replicaro now runs as root in the docker container by default with a --no-root option for people who don’t want root. See dockerhub, and let me know if you run into issues.
running the docker container as root is fine. running it as my main user UID 1000 is not that great. too many permission errors when backing up my data (and files owned by other users).
mounting my rclone.conf in the docker container also works fine.
I have now set up 2 vaults (WebDAV and FTP) and 2 backup jobs (one Kopia, one Restic), will run them daily and report about strange behaviour.
exclude rules: I would like to place a file .nobackup (or cachedir etc) in a folder, and I would like the whole folder and all its subfolders not be in the backup. This does not work yet? Only the file .nobackup is excluded, but the folder and its subfolders are in the backup?
„Any Rclone Remote vaults must use Restic as the engine. Kopia no longer actively maintains rclone support.“ is it really like this? I would very much like to use my rclone remotes with the Kopia engine in Replicaro.
If it’s still possible but “experimental” from the Kopia side, Id be happy if you enabled it for Replicaro. (Using my own rclone.conf is advanced user mode already …)
That said, I like Replicaro. I was happy to see that yellow Pac-Man backing up my files for the first time today
(1) So then it sounds like default running as root is the right call? If so, I’ll leave it as root and let whoever wants it as non-root to explicitly set that using --no-root.
(2) great!
(3) awesome, I am looking forward to your future feedback
(4) the current exclusion list in Replicaro works as you describe; it excludes files or folders based on patterns rather than excluding a whole folder and its contents if a .nobackup or similar is present. i will add support for a .nobackup or similar file in 1.0.6. in the meanwhile, you can add pattern excludes in Replicaro, or the following will also work right now:
Kopia jobs: put a valid CACHEDIR.TAG in the folder, or a .kopiaignore file containing *. Both work now with no settings change.
Restic jobs: put a valid CACHEDIR.TAG in the folder and add --exclude-caches to the job’s Advanced CLI options.
(make sure the cachdir.tag file starts with Signature: 8a477f597d28d172789f06886806bc55)
(5) I am unlikely to add rclone support for kopia because that feature is no longer maintained by kopia (see repository connect rclone | Kopia ). i would recommend anyone using rclone with kopia to migrate away - either use a different kopia vault or migrate to restic. if your backups are important to you, do not continue to use a feature that is not maintained any longer. i talked with jarek, and he said they dont plan on removing rclone support but they also are not maintaining it. i am happy to add rclone support for kopia if kopia starts maintaining it again
I’m really glad you like Replicaro. Please keep the valuable feedback coming.
I created 2 backup jobs on cron schedule ***** but since the docker container runs on UTC, It doesnt execute the backup jobs at my desired time (UTC +2)
Could we please have -e TZ=Europe/Berlin to create a container with different time zone information?
$ docker exec replicaro printenv TZ
Europe/Berlin
$ docker exec replicaro date
Wed Oct 14 04:35:34 UTC 2026 (local time was 06:35 CEST)
$ docker exec replicaro ls /usr/share/zoneinfo/Europe/Berlin
ls: /usr/share/zoneinfo/Europe/Berlin: No such file or directory
So the variable arrives in the container, but the image seems to contain no tz database (/usr/share/zoneinfo is missing). Maybe the tzdata package is not installed in the image, so Europe/Berlin cannot be resolved and everything falls back to UTC.
date and the missing /usr/share/zoneinfo is expected. Replicaro has its own zone database, so only Replicaro’s job schedules follow TZ. Shell, hooks and Restic/Kopia snapshot times stay at UTC.
I do see how that is confusing, so I will look into improving this in v1.0.7. For now, however, your jobs should running at Berlin time.
To confirm TZ loaded, check the startup log for timestamps. Those should be in Berlin time, with no “could not load the time zone” line.
There is one caveat, which I will also look into fixing in v1.0.7. A job’s first run after upgrading to 1.0.6 keeps the next job run’s time at UTC. Every run after that is in the set TZ time, which is Berlin in your case. To update that job’s run time immediately, change the job to a different schedule, save, then switch it back, and save again.
Let me know if you see the jobs running on Berlin time or not.
excellent, will do some testing then on Sunday
