I’m using 2.0.4.5_beta_2018-11-28 on a Windows box. Just created my first backup from local to Mega.nz using the web interface. I can re-execute it without issues from the web interface. When trying to run the backup from the command line I get this error:
ErrorID: PassphraseChangeNotSupported
You have attempted to change a passphrase to an existing backup, which is not supported. Please configure a new clean backup if you want to change the passphrase.
Here’s my command line:
“C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe” backup “mega://Backup/Luluana?auth-username=***&auth-password=***” “C:…\” --backup-name="…" --dbpath=“C:\Users\luizr\AppData\Local\Duplicati\71657585808084836766.sqlite” --encryption-module=aes --compression-module=zip --dblock-size=50mb --passphrase="***" --retention-policy=“1W:1D,4W:1W,12M:1M” --disable-module=console-password-input
I got it by exporting the backup job. Double checked the passphrase.
This is my first use of Duplicati, what can be wrong?
Hello @luiz and welcome to the forum!
The only odd thing I can see, compared to one of my export-and-runs (which worked) is your passphrase got double quoted while mine didn’t. Possibly this means Duplicati found some special characters and so tried to make sure they would be processed correctly as an option value. The question is: did it succeed? Misreading the passphrase might make it think you’re trying to change it, and it will complain, as it should.
If you like you could test with a different sample backup with a passphrase that has no special characters.
You could also try the Commandline built into the web UI, which I think doesn’t re-parse input like cmd.exe.
Thanks ts. It worked, which makes me suspect it’s a bug as the password with special characters was generated by the button in the web interface. Nevertheless, I’m getting this error now when trying to execute my backup from the command line (from the web interface it works):
[C:\Users\luizr\Documents\Pessoal\Diversos]“C:\Program Files\Duplicati 2\Duplicati.CommandLine.exe” backup “mega://Backu
p/Luluana?auth-username=***&auth-password=***” “C:\Users\luizr\Documents\Luluana\” -
-backup-name=Luluana --dbpath=“C:\Users\luizr\AppData\Local\Duplicati\77817788789088808977.sqlite” --encryption-module=a
es --compression-module=zip --dblock-size=50mb --passphrase=*** --retention-policy=“1W:1D,4W:1W,12M:1M” --d
isable-module=console-password-input
Backup started at 14/04/2019 19:47:44
Checking remote backup …
Listing remote folder …
Listing remote folder …
Listing remote folder …
Listing remote folder …
Listing remote folder …
Fatal error => API response: BadArguments
CG.Web.MegaApiClient.ApiException: API response: BadArguments
at Duplicati.Library.Main.BackendManager.List()
at Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)
at Duplicati.Library.Main.Operation.BackupHandler.d__19.MoveNext()
— End of stack trace from previous location where exception was thrown —
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at CoCoL.ChannelExtensions.WaitForTaskOrThrow(Task task)
Any clues or should I open a new topic?
I’m pretty sure most special characters are OK, but any that don’t work with the quoting should either be removed from the generator, or the quoting should improve… The latter is more flexible as it gives users flexibility in their own passwords. Any idea what the troublesome character might be? You could remove suspected characters one-at-a-time, and see which fail on a new test backup, but it’d take awhile to test. Ultimately, getting anybody to fix this probably requires a test case and an issue so that it can be tracked.
Probably a new topic on the Mega issue would be worthwhile. The subject and issue seem very different. The five attempts at Listing is quite possibly five failures, with only the last one detailed. This comes from –debug-retry-errors=false by default, plus –number-of-retries=5 by default. You can change. Might not fix.
Error likely came from third-party MegaApiClient that Duplicati uses reporting a BadArgs error on its use. Their issues has Unicode is not supported #96 doing that, but it looks fixed in 1.6.3 which Duplicati uses. Still, it’d be worth asking if you might have Unicode (i.e. not ASCII) characters CLI may have mishandled. That seems like kind of a long shot. If it doesn’t help, maybe post new topic and hope someone can help. Maybe the BadArgs error is a genuine Duplicati bug in its use of that client, but I don’t know the area well. Whatever it is, though, I guess you test shows that the true CLI (i.e. paste to cmd.exe?) is what invites it.
Hi ts,
Thanks again for you very promot and elaborated response.
My previous passphrase was %h#T$&d49Bx@0Y+
I’m pretty sure there were no unicode characters in my new passphrase nor in my pasted CLI. As for the backup contents I cannot affirm.
I won’t pursue this for the moment as I have other priorities. I’ll try the command line backup provided by Mega itself.
Since this issue still exists, and I think I ran through most of what can go wrong, I’ll list my findings here:
We start with a backup configuration exported to command line from the web interface.
In your batch file:
-
For all options (or only those which makes problems) (an option is an argument prefixed with --) , if they contain no quotation marks, wrap them with quotation marks, and if they do have quotation marks, move the left quotation mark in front of the two dashes.
(Example: --passphrase=“my pw” would be replaced by “–passphrase=my pw”; --exclude=".trashes" would be replaced by "–exclude=.trashes").
[For example --passphrase=“my pw” would by cmd be read as multiple arguments, I think it was as [–passphrase,my,pw]] -
If anything you used contains Unicode characters (in my case e.g. the authID), in your batch script, make an empty first line, and copy in
chcp 65001
to change the encoding to UTF (also, of cause, make sure that when saving to the batch script, your editor uses UTF). -
If any option contains the symbol “, then it gets messy (Everyone quotes command line arguments the wrong way – Twisty Little Passages, All Alike).
Basically, we’ll have to search and replace all matches of the regex ([()%!^”<>&| ]) with ^\1 in the option
, though I haven’t tested it.
I found an interesting article about special characters in batch files, this may help.
My issue was with the passphrase containing a special character in my passphrase, like
–passphrase=“pass%word”. The solution was to double enter the %
–passphrase=“pass%%word”
The error signature was:
“ErrorID: PassphraseChangeNotSupported
You have attempted to change a passphrase to an existing backup, which is not supported. Please configure a new clean backup if you want to change the passphrase.”
@goestuber thanks for bringing attention to a possible solution.
I have create an issue here for tracking it: