Invalid or expired Web-UI license after reboot (Backups were working fine earlier today, and my license is valid well into 2022)

I set up a new backup today, on a new storage. After running the backup for a few hours, it crashed and I had to force quit my whole Mac. (Not sure if one thing is connected to the other, but that is my back story)

  • reboot
  • re-open Duplicacy WebUI…
  • press [Play] on my backup…

Get the error message:

** Invalid or expired license **

Top of the page says I indeed have the “Personal” edition. I even tried going to *https://duplicacy.com/licenses*, grabbed the license code, then copy/paste into Duplicacy. This did not work. Error message:

*"Failed to download the license: License error: Activation code has already been assigned to host [my host name]. Please log in to your Duplicacy customer page to change the host"*

I went into my Mac > Settings > Sharing and double checked my host name. Host name is 100% correct. (I even copy/pasted to be sure)

Suffice to say, my backups won’t run, and my Duplicacy license is in a kind of Schrödinger’s cat: where it is both activated, (hence “Personal” edition at the top of the page) and not activated.

At this point I’m not sure how to proceed. Any advice greatly appreciated.

So, I figured out a workaround. I changed my host name, then logged into my Duplicacy.com license page, then copy/pasted the new host name. I rebooted and then copy/pasted the activation key and it worked.

This is the second time in 2 weeks that this has happened, and it seems to correlate with rebooting – it happened the last time I rebooted, too. While I got it working “for now”, continuously changing my host name after every reboot and then re-activating my WebUI license is an untenable solution.

For posterity, and the benefit of the Duplicacy community, I’d like to get to the bottom of this, and I’m willing to troubleshoot. Any ideas?

Login to your duplicacy account and confirm that the host name next to the license is what you expect.

On a Mac, open terminal and compare output from scutil --get LocalHostName and hostname. In the “Sharing” you set the former, Duplicacy IIRC uses the latter.

I have instances when the hostname was becoming a GUID due to misconfigured router. Reboot your gateway, reconnect the Mac to the network, and compare those names again.

1 Like

Login to your duplicacy account and confirm that the host name next to the license is what you expect.

Check. Yep, it is.

On a Mac, open terminal and compare output from scutil --get LocalHostName and hostname . In the “Sharing” you set the former, Duplicacy IIRC uses the latter.

When I run scutil --get HostName, it currently returns “not set”, while LocalHostName returns the expected name.

I’ll note again, as of my last post, the license is functioning correctly. (Changing my host name both in Sharing, and on the Duplicacy license page, THEN rebooting fixed it – for now.)

I would like to reboot again to see if the license activation persists, or if I’ll need to go through this rigamarole again. I now have a very lengthy backup in progress, so I will have to wait for it to finish before I can confirm.

In any case, this begs the question: why would rebooting affect my license activation? I haven’t made any changes to my router, OS network settings, nor have I updated my OS.

If I needed an incentive to finally learn the free CLI, this would be it…

Check those hostnames when it does not.

Because, allegedly, on reboot your machine talked to DHCP server again, which this time returned a coherent result. It’s almost always a problem with DHCP: macOS gets a lease, tells the server its hostname, then asks for a hostname. DHCP server returns something that is taken as hostname. It shall be the same hostname macOS reported, but sometimes it isn’t. I’ve seen this issue a number of times with Ubiquiti gateways. I could not pinpoint what causes the issue – it just happens occasionally, and my Mac gets a hostname in the form of a huge GUID.

1 Like

This is good info, thank you.

I’ve got to wonder – is this a bug, or a fundamental design flaw? I use other paid utilities from small developers, and can’t say as I’ve ever seen an activation process so exotic. This kind of user experience is pretty intolerable, and completely undermines trust in the software. Thank goodness there’s a forum, and thank goodness you in particular are so committed to helping the Duplicacy community.

That said, I’ll reboot when I finish this backup to see if I can troubleshoot it further.

1 Like

It would be interesting to know the reasoning behind making a hostname, a rather volatile value, that can be assignable by external services, a factor in license management. I’d think machine-id (which is factored into the license already anyway) would have been sufficient?

This actually creates quite a bit of hardship for users who want to run the duplicacy on clusters – be that VM or containers; node hostnames are rarely static.

1 Like

Relying on the hostname may be a design flaw, but I don’t think there is a better alternative. The machine-id is even more volatile than the hostname, and cannot be easily found by non-technical users.

Mostly likely it is mac users who ran into this issue. Usually a mac may obtain different hostnames depending on the network it is connecting to. But I think this is more of a configuration issue.

I disagree. machine id identifies the OS install. Hostname can be changed on a whim.

According to https://wiki.debian.org/MachineId:

It’s intended as an opaque, non-human-meaningful, persistent unique identifier for a machine (or more precisely an OS installation), used as a lookup key in state/configuration storage in the same sorts of places you might be tempted to use a hostname.

Emphasis added :slight_smile:

it’s tied to OS install, and therefore is already more persistent than hostname; for containers it being a file can be persisted outside, forever.

Users should not be expected to know any of that, including hostnames, much less look for them. Instead, the app should handle this for them: provide a space to input the license code the user purchased, their email, and press “Activate”. The app shall send it along with machine-id to the licensing service, without the user needing to do anything else, including the need to open the browser and copy-paste hostnames. (App knows it – why force the user to do it manually?). If machine-id changes – it’s a new machine for all intents and purposes and users can repeat the process; this will invalidate the old one.

Machine ID here does not even have to be actual /etc/machine-id from dbus and the likes. It can be a random number in a file that duplicacy generates in a specific place on first run (e.g., via dbus-uuidgen --ensure <path/to.file>, or analogous process). You can add a cryptographic signature to ensure that it’s genuine – but it won’t really matter, the purpose of it is to roughly disambiguate between multiple user’s machines. It’s way better than hostname, too. (I can imagine having servers boulder.ns1.example.com, boulder.ns2.example.com, etc. All of them are the same hostname from duplicacy’s perspective).

Mmmm… Are Mac users not worthy of a good UX with duplicacy? I’d say on the contrary, they (us! :)) are way more demanding and intolerant. Which is a good thing.

This is the objective reality duplicacy needs to deal with to make it work for mac users.

This is the objective reality duplicacy needs to deal with to make it work for mac users.

I agree with everything you said here, saspus.

Taking a step back: what is the intended goal of all this authentication complexity? What problem does it really solve? Piracy prevention? Keeping the freeloaders out?

At what cost?

If one drew a line for all the various license verification schemes available to a software developer, with “100% honor system” on one end of the spectrum, and whatever Adobe is using to validate Photoshop these days, on the other end… where does the current Duplicacy implementation fall?

Does it really maximize revenue?

Is piracy really a threat to the business model of niche backup software, used exclusively by sophisticated tech enthusiasts? (Many of whom, while capable of using a CLI, are happy to pay the developer anyway because of the belief that good software should be rewarded?)

One could make the argument that the current verification implementation is counter-productive. Instead of increasing revenue, I’m convinced issues like these drive away current and future customers. Given the technical sophistication already required for regular use I can’t, in good faith, recommend Duplicacy to friends or family in its current state – even recommending it to SWE friends gives me great pause. And now layer on this issue of the software effectively harassing legitimate users; locking them out cold for no fault of their own, only to seek refuge on a web forum.

I own software from other small developers, too, and the verification is always easy peasy. I’m not sure what Beyond Compare uses, but when I reinstalled MacOS it was a * cinch * to get it working again: 1. download and run the .exe, 2. get prompted for a key, 3. go to my email from years ago with the key, 3. copy/paste/DONE. And it has never asked for it again.

Maybe you could consider a much lower-tech approach. Who cares if a few folks slip through the cracks, at least you’re not alienating the paying customer base. (Folks who, in theory, will act as referrals for future paying customers.)

I hope I’m not coming off as too harsh, just trying to give constructive feedback. I think we all love the core product, want to see it improve, and want the developer to be rewarded for it.

1 Like

I just realized that the confusion was largely caused by the error message returning only the hostname that the license has been assigned to, not the hostname that the license is being activated on. This is a simple fix (and has just been fixed since it involves only server-side changes).

Now the error message looks like:

Failed to download the license: License error: Activation code has already been assigned to a different host and can't be activated on mac-mini-2021. Please log in to your Duplicacy customer page to change the hostname associated with the license.

So just take whatever the error message says and put it in the dialog to change the host name.

I also figured out that the correct way to show the host name (as seen by Duplicacy or any go programs) is to run sysctl kern.hostname and take the first component. For example on my mac:

$ sysctl kern.hostname
kern.hostname: mac-mini-2021.BUFFALO

Why not activate this license for this new host automatically, and invalidate the existing one? Why force the user to log in and copy and paste stuff manually when the app already has all the information?

Hostname is not a secret, if you worry about security.

Agree Duplicacy should try to make licence authentication as seamless as possible.

I dislike the fact both Duplicacy and Vertical Backup stop working on the expiry date - despite having renewed the licence online beforehand. The activation code has to be manually entered each time.

However, I also think it’s unreasonable to expect Duplicacy’s Web UI to handle new authentications directly with your online account - the one protected with an email address and password, where all the activation keys are stored. The app in fact, doesn’t know that, and I rather it didn’t… that can stay safer in my password manager.

It’s not uncommon to paste API keys, for instance, from place to place, so IMO a better compromise would be for the Web UI to show the machine ID (if that’s the best token) for easy copy pasting to the customer section online.

I also own a Beyond Compare licence and part of the reason I do, and paid to upgrade from a previous version, is how generous their trial period is. (The 30 days doesn’t tick down if you don’t use it for any of those days, and then they add in a further grace period, and then uninstalling and reinstalling resets the counter. :slight_smile:)

With that said, it’s also trivially easy to activate multiple copies with just one licence (I don’t, don’t need to), so I don’t think it’s unreasonable for Duplicacy to want to protect against that abuse. IMO there’s no need to throw the baby out with the bathwater, so long as these niggles - which are solvable - are fixed…

1 Like

Ha! I bought Panic’s Transmit license partly for exactly the same reason – trail days only count when you use it, so after about a year when my trial finally expired I bought it :), even though on each major macOS update it seems to reset the counter as well.

The main thing to solve here is to prevent [unattended] installations from failing just because the hostname changed.

1 Like

What if the license code is leaked? Then everyone who knows the code can use the license.

But that actually brings up a good idea. I can rework the activation dialog to require the user to log into duplicacy.com and then select the license to activate. No more copy and paste, and you have the option to overwrite the hostname.

1 Like

Yes!

This is how Duplicacy should be, IMO. Anything more than a simple deterrent is overkill.

The last time I checked, Beyond Compare (Scooter Software) is a thriving small business in Wisconsin, with a 25 year history (!) selling just one tiny (but extremely useful) file comparison utility. They’ve been profitable every year for two decades! The livelihood of 9 people depends on the long-term success of the product! They even have pretty cool digs! (video)

Now then: if they don’t see the need for draconian anti-piracy measures, why should a fledgling backup utility?

Ok, fair point, but please don’t use hostname as a secret: it’s not very secret in the first place and is prone to changes. Machine ID on the other hand is a perfect token for this. Repeating the quote from the earlier comment: “[machine ID is intended to be] used as a lookup key in state/configuration storage in the same sorts of places you might be tempted to use a hostname”. That’s precisely this use case.

Hostname still can/should be used during activation process to help the user match the license with the machine they are activating, but ultimately machine ID shall be used, and hostname should be treated simply as user-facing caption, that can change any time for any reason.

I guess this get the best of both worlds:

  • Leaking license is harmless, to steal a license also need to steal machine ID (which is just a text file from users’ computer)
  • Changing hostname is harmless – enabling user to run duplicacy in compute clusters

It still does not stop a determined pirate who can buy one license and then copy-paste machine ID and license ID, but this is a cat and mouse chase. You can detect that server side by other metadata collected from the client, if you think this is worth the troubles, but then we are entering telemetry, privacy, and all that jazz. Unless you already have plans to implement telemetry (which IMO is uber useful!) asking users for consent to track the use just to prevent piracy won’t be worth it.

As others mentioned, I highly doubt there would be a lot of piracy to justify all that trouble. I don’t know, but it certainly feels this way.

I have this issue with unraid. where it would say trial. I have tried updating the licence key in the licence and the machine id and not made a difference. i do see an option to transfer but im not sure if i have to put in the machine id or just put in a computer id.

If you have a license code, you can click the link next to the host name on the Backup page, and then enter your license code. If it doesn’t allow you to activate due to a mismatched host name, you can log in to https://duplicacy.com and change the assigned host name by clicking the link under the Host column.

thank you got it sorted.