Any news on this one?
Thanks.
Sorry I thought it was simply a matter of replacing the 6.2 SDK packages with new ones. But it turned out there were some incompatible changes that broke my build script and it was not straightforward to fix. I’ll continue to work on it and hope to get it done by the end of next week.
Thank you @gchen! Looking forward to that as well. For now holding back with upgrade to DSM7, but it would be great to have Duplicacy packages for DSM7 as well to be able to use the latest release of DSM.
Just upgraded to DSM 7.0 and looking to get my Duplicacy on 
How’s this one coming, Gilbert? 
I built the packages for DSM 7.0 but unfortunately DSM 7.0 doesn’t allow third party packages to be installed. There used to be an option in DSM 6.2 to set the trust level to any publisher, but that option is gone in 7.0.
It does allow installation of third party packages, but they removed the trust level option in package manager. It now just warns you with every third party package install, but the install is allowed. Synology is getting all uppity and trying to look like enterprise-grade stuff so they warn with all non-Synology packages in DSM 7. Even Plex’s package that you download from their site (the recommended way to install/update Plex on Synology) gives the warning - but it certainly does install. I’ll try and let you know how it goes. I think Synology and most package publishers have begun listing MD5 or SHA hashes to validate package integrity instead of signing with the keyfile like it was done before. 
The key seems like a better idea on the surface.
It looks like there must be something wrong with the package… It says “Invalid file format”. The DSM 7.0 package from Plex (also third party) works just fine. I opened the package as a tarball (that is all it is afterall). The contents of the Duplicacy for 7.0 package and the Plex for 7.0 package look a good bit different and the Plex package works.
Thanks for the info. I always thought “Invalid file format” was caused by DSM 7.0 blocking packages from non-official publishers and even tried to manually modify /etc/synoinfo.conf to change the trust level.
Now I looked at this again and found out from the log that this error message was caused by a missing key os_min_ver which wasn’t required in DSM 6.2. So this looks fixable and I’ll try to upload updated packages later today.
Yay! It works Thank you!
As far as migrating settings over from an existing duplicacy_web installation, can I just move all the files and folders into where the package stores the files and then start the service? Also, in the future, will upgrading the Duplicacy Web DSM package remove all of my settings or will it preserve it/migrate it to the new version of duplicacy_web? Also, is there any tool to export/migrate duplicacy_web settings/repos between installations?
Repositories/schedules configuration is in duplicacy.json. Application settings are in settings.json. If you use access token files — then those files also will need to be saved and restored to the same path as before — path to them is encoded in duplicacy.json. This is something that need to be fixed eventually — instead of saving path to a token file — content of the token file must be saved.
Personally — I don’t back it up. It’s trivial to setup from scratch. All I save is storage access credentials in my password manager and backup encryption password.
Hmmm… pre and post scripts don’t seem to be running under the “duplicacy” user that the package creates, or at all. Any ideas? Permissions have been checked and the created duplicacy user has full permissions to the scripts and the entire directory structure above it.
Where did you place the scripts?
In the /volume1/@appstore/duplicacy/.duplicacy-web/repositories/localhost/0/.duplicacy/scripts folder
Yes, that’s the correct location, unless you changed the Temporary directory location in the settings. Please verify that:
- filename is
pre-backup - execute attribute is set
chmod +x pre-backup - if you specify interpreter in your script – make sure it points to something that exists (e.g. e.g. bash on DSM7 may be at /bin/bash or elsewhere – verify)
- Add to your script something obvious, like
echo hi > /tmp/hito make sure that works, before you debug more complex logic there.
The temporary directory is the default of “/tmp/duplicacy/repositories”. The file structure in that location is missing the scripts folder. How does the temporary directory work in duplicacy-web? Does it just copy the stuff from the repositories folder in .duplicacy-web folder to the tmp location then execute from /tmp… or does it execute from the .duplicacy-web/… location? I see from the log that it seems to be executing from the /tmp… location.
I went and manually copied the scripts folders to the appropriate repositories in the /tmp location and chown/chmod’d as necessary. That doesn’t seem right… shouldn’t it do that automatically? I did stop and restart the service a few times to see if it would copy on startup but no such thing happened. Only on modifying the settings or what? I wish this were documented…
Duplicacy web does not support scripts. Copying them to the folder duplicacy cli is executing from is a hack, so nothing automatic. That location is temporary and can be deleted; duplicacy-web initializes duplicacy repo there to perform the actions. It is persistent though until you delete it, so your scrip folder will persist. Unless of course your OS purges /tmp folder on boot, in which case it’s better to change that location to somewhere more persistent.
The easiest would be to start backup and open log. This will tell you the exact path to the temporary repository where it starts the cli from. You need to put you script under /that/path/to/temp/repo/.duplicacy/scripts
1 Like