Nevermind found it, it looks to be specified as
–hostname=duplicacy
So since it is present, I assume the license issue should not have happened?
Right, it should not have happened. Also check that the machine-id file or equivalent is present in the /config or similar folder. Maybe you can find some clues in duplicacy_web.log?
Ok i found this (machine-id file was present also)
2021/12/29 07:11:24 192.168.1.1:57162 POST /get_backup_status
2021/12/29 07:15:58 The license may have been issued to a different computer
2021/12/29 07:15:58 Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set
2021/12/29 07:15:58 Failed to decrypt the value from the keyring file: cipher: message authentication failed
2021/12/29 07:15:58 Failed to decrypt the testing data using the password from KeyChain/Keyring: crypto/aes: invalid key size 0
I’m not sure — but this looks like due to changed hostname
Your probably right but since its specified in the docker config i don’t know what else to do, i rebooted several times today for unrelated reasons and it did not change so maybe it will be infrequently.
Its a trial now but when i purchase hopefully if this happens once in a blue moon getting the license re-issued isnt too much of a hassle.
Same issue for me. I’m trying to give Duplicacy a try but I’m getting the dreaded ‘Invalid or expired license’ every 2-3 days. I’m also running @saspus docker image on unraid like @thedinz
If if delete license.json and restart the container everything works again for a couple of days. The only thing happening that might cause issue is sometime my internet goes down and the container is stopped daily for a config backup to a share.
Here’s what I can confirm based on my research on similar issues on this forum:
- The hostname is the same every time. It’s set using ‘–hostname=duplicacy-unraid’ and confirmed by running the hostname command in the CT CLI
- The machine-id is also the same. Confirmed by comparing the machine-id file from previous backups
- If I delete license.json and restart the CT, the new license file that is being created is the exacte same copy and contains the same value as the previous one I deleted yet now it works fine.
- The only thing I’m seeing in the logs is ‘Failed to request a license: activate’ when the container boots
Any idea what might cause this ?
Thanks
Could it be networking issues? I.e. networking is not yet up when the container starts? If you simply restart the container does it work then?
Could be. Unfortunately I’m not really sure how Duplicacy valides the license but when the error does happen, restarting the CT does not fix it. The only way is to delete license.json then restart it.
I tried to reproduce the issue by blocking internet access to the container and restarting it but to no avail.
If it’s really related to the network, shouldn’t Duplicacy check it’s license on every launch of a backup job instead of the boot of the CT ? Otherwise if my network is down when the container boots up then later the network comes back I would still be stuck with an invalid license. Not sure if that’s what happening but making a guess.
1 Like
It has not happened to me since but its been up this whole time, i suspect I will indeed have the issue again, and like @Quack66 mentioned all my settings appear to be correct including the hostname specification.
Could it not be possible that we found a bug?
1 Like
I can confirm that if the container stays on then the license will remain valid. After you get a paid license, Duplicacy will be able to automatically download a new license when the current one becomes invalid for whatever reason, using the same activation code. It can’t do this for trial licenses, because a trial license doesn’t have a unique activation code.
2 Likes
That’s good to know ! I just bought my license. I’ll report back if the issue persist. Thanks !
Adding on to this as well, I have am having this same issue. Seems to always occur on boot of my Duplicacy docker container. I’m specifying the hostname directly and confirmed through the logs that it is seeing the correct hostname. The only solution is for me to delete the licenses.json and machine-id files and then restart the container again and let it recreate those files. I’ve noted that the machine-id it creates each time is different, so I suspect that is probably the issue but am not sure of how to confirm off the top of my head without knowing how exactly it creates the data within the machine-id file.
Given that I’m still evaluating Duplicacy, I’m not wanting to purchase a license just yet, in case that is a solution, but I’m also worried that the issue would persist after the fact given that it seems like the host is being recognized as a different machine each time the container is started.
If there is any information I can provide or tests I can do to help diagnose this, feel free to let me know or send me a message. Thus far I’m very happy with the software and, pending letting my data backup and performing tests with pruning, checking, and restoring, I’m going to be purchasing a license.
Depending on what container are you using, it’s managed by dbus.
machine-id is supposed to be unique machine identifier. Don’t delete it, it shall be persisted in the config folder. If it is missing or corrupted it gets created with dbus-uuidgen which is pretty much random data for most intents and purposes.
Oddly, the only way that I can get the container (I am using yours, coincidentally) to actually function again is by deleting both the licenses.json and the machine-id. If I just delete the former, it will recreate it but continue to insist that I do not have a valid license. I looked into the code earlier and noted that it created the config/machine-id and then symlinked it to /var/lib/dbus/machine-id. I need to do some digging later and see if the value of /var/lib/dbus/machine-id is consistent across container reboots or if it is changing somehow, perhaps the symlink breaking.
I don’t know details but this is a very good observation and likely means it’s a duplicacy licensing issue.
When you delete machine ID and the new one is generated duplicacy thinks its running on an entirely new machine and does somethign differently: e.g. requests a completely new licenses as opposed to renewing the current one.
Btw are you seeing this issue with paid or trial license? The trial behaves differently according to gchen comments above
Trial license. As noted, just started evaluating Duplicacy and want to verify it will work for my use case prior to grabbing up a license. Past this one issue it’s worked great and incredibly quick, much more so than all the other various options.
In an update that will probably surprise absolutely nobody, I finished up my backup and restarted the container with the intent of testing the above scenarios and…it’s continuing to work perfectly fine 
If the problem persists I will update. I made a note of the machine id I had prior in case it changes.
I rebooted my machine today and the issue has occurred again. According to the trial popup, I still have 17 days remaining on my trial, however I cannot resume a backup that was ongoing due to it stating my license is invalid or expired.
- I’ve confirmed that
/var/lib/dbus/machine-idis still symlinked to/config/machine-id - I’ve confirmed that both the above still have the original creation/modification date from Jan 20
- I’ve confirmed that the
licenses.jsonstill has an original creation/modification date of Jan 20
One thing I will note is that, within duplicacy.json, computers lists the only entry with a name of localhost while the actual webui shows the hostname I am passing to the container. In fact, the passed in hostname for the container is not reflected in the duplicacy.json file anywhere. If I run the hostname command within the container I get the properly expected hostname. This makes me wonder, perhaps, if there is an issue where duplicacy is using an incorrect hostname or reference to localhost, then seeing that the requests are coming from the defined hostname, and thus thinking these are separate computers.
This would potentially be backed up by the fact that, looking on the dashboard, I see the previous actions I have manually performed being reflected as localhost-*, (localhost-1, localhost-2, …, localhost-8)
I’m going to keep this state for a bit to try and provide any other information I can upon request before doing the needed steps to continue with my backup testing.
Ironically, because (from what I read so far) trial license handling is different, addressing issues with it won’t affect your future use of the software with an actual license. It’s essentially trial of a wrong thing in this case — and needs to be fixed. (Even at the expense of requiring trial users to create an account. Otherwise users will give up seeing like even trial version does not work reliably)
In your case, not to fight windmills with trial licensing, it may be more productive to trial an actual code path that will be used if you decide license. If @gchen agrees you can buy a license with an option to get a refund in a month. Or maybe @gchen can generate you a paid license code with expiration date in a month in the future. Either options will give you one month trial or actual app behavior. Just my 2c.