Can you please try saspus/duplicacy-web:test-multiarch? If this works, I’ll update :mini image with this.
1 Like
This seems to work perfectly 
1 Like
yay!!! Thank you so much for testing! I’ll update the :mini image shortly (I need to figure out how to use docker auto builder with multiple architectures …)
1 Like
I’ve updated the :mini manually. It’s now the same as test-multiarch. I’ll remove test-multiarch tomorrow.
1 Like
Wow! Thank you for your help! That was really fast :).
Hello again
I’ve just upgraded my Raspberry Pi 4 to the 64-Bit version of Raspbian. Now it seems that there is no available docker image for aarch64 architecture.
Is it possible to include such an image in your wonderful docker container?
Absolutely!
What does uname -m return on that platform?
1 Like
Ohh, wonderful news!
It returns aarch64
Can you please test these two tags?
saspus/duplicacy-web:latest_testsaspus/duplicacy-web:mini
I don’t have arm64 hardware to test on… if :latest_test works – I’ll push it to :latest.
1 Like
I’ve just tried both and they work wonderfully!
Thanks a lot for your work and effort!
1 Like
No problem, thank you for verifying !
I’ve nuked the latest_test and pushed the same image to latest.
Hi Saspus. I have Eric’s docker image (which has been great) but the settings in Schedule GUI do not persist when the container must be recreated and the web gui has not been updated for many months. Is it possible to move to your container without starting from scratch? I have the cache and config folders mounted as volumes and mapped to my hard drive. Any help would be appreciated. Thanks
I’d think so. Entire duplicacy configuration consists of settings.json, duplicacy.json and machine-id.
I would create the new instance, start it, stop, and merge changes from the old container in those three files: probably copy duplicacy.json and machine-if in their entirety and merge changes in settings.json if any — there are some paths configured in my container.
Or maybe better yet — report bug in the other container so it can get fixed and continue using it since it was working for you.
Thanks Saspus. I reported the bug, as did others earlzy last year. Eric is not actively maintaining the docker image which is why I am thinking of moving. I think I will try and create a test image. I have the files you mention. I will give it a go and report back.
Hi Saspus. Doing some testing. Have 2 problems. First is that the machine ID I used originally with Eric’s container does not match the machine ID generated with the hostname docker label. For Eric’s container there was a machine-ID environment variable. Second, I have a permissions issue.
duplicacysaspus | duplicacy_web runing as user root:root(0:0)
duplicacysaspus | Logging tail of the log from this moment on
duplicacysaspus | Starting duplicacy_web
duplicacysaspus | /usr/local/bin/launch.sh: line 27: /config/bin/duplicacy_web_linux_x64_1.4.1: Permission denied
duplicacysaspus | /usr/local/bin/launch.sh: line 27: exec: /config/bin/duplicacy_web_linux_x64_1.4.1: cannot execute: Permission denied
I tried to set the permissions to 775 which is identical to the permissions on the folders in Eric’s host volumes. I want to stay as root user because Eric’s files are owned by root:root so if I copy across and merge the files I want the same ownership. Any idea? thanks.
In terms of merging files, I also have a licenses.json file and a filters file. Should I merge those also into the config directory of the new container?
Update: I managed to change the machine id manually in the machine ID file. I also merged the filters directory and the licenses file, together with cache. I also merged the settings file and the duplicacy.json file. All works on loading the container except I still have the permissions error noted above. Any one with an idea why? Thanks
Update2 - I tried changing the user and group from root:root to another UID I used for my Nextcloud docker image. I also did a chown of the mounted volumes to chown to the same User and Group. Still the same permission denied error on line 27 of launch.sh - I note the container reports a different user and group (duplicacy:duplicacy) than the UID and GID I actually used in the docker compose file. Which I find strange also…if I leave it blank it runs as root:root but still permissions issue
Update 3: I noticed that I do not have UMASK set as an environment variable as some users do of this container using docker compose. Problem, I have no idea what the correct UMASK code should be…can anyone tell me what it should be, as this maybe the problem.