Empty storage password is ignored

Support
#1

My storage password is empty, but it is not recognized/used by duplicacy:

[   
    {   
        "name": "default",
        "id": "ubuntu-backup",
        "repository": "",
        "storage": "b2://test",
        "encrypted": true,
        "no_backup": false,
        "no_restore": false,
        "no_save_password": false,
        "nobackup_file": "",
        "keys": {
            "password" : "",
            "b2_id": "09809809809",
            "b2_key": "spspdsaopdasopdk"
        }
    }
]

It still asks for password:

$ /usr/local/bin/duplicacy -v backup -stats
Storage set to b2://test
Enter storage password:

When I try to set an empty password value:

@ubuntu:~$ duplicacy set -key password -value ""
The options for storage b2://test have not been modified

My question is:

  • It is possible to use/save empty password so it is not asking for any password when I run backup command?
  • It is possible to change storage password?
#2

Yes. See here:

3 Likes
#3

Cool, thank you. :slight_smile:

#4

For anyone: Feel free to use the :heart: button on the posts that you found useful.

For the OP of any support topic: you can mark the post that solved your issue by ticking the image box under the post. That of course may include your own post :slight_smile:

#5

Is there any answer to the first half of the OP’s question?

Rebuilding a corrupted VM right now and I basically lost my “.duplicacy” folder with my preferences/config. I know I used to have the storage password saved, because it wouldn’t prompt me during backups. But after re-init from the storage, every duplicacy command prompts me for the storage password, and apparently it’s blank, because it only proceeds if I simply hit Enter.

So back to the OP’s first part of the question: How do we save a blank storage password (or stop duplicacy from prompting for a storage password when it’s empty)?

Windows x64, v2.3.0

#6

If the storage password is blank, then it means the storage is not encrypted, so just set “encrypted” to false in the preferences file.

#7

Ah, I should have surmised that.

This stems from a VM that got corrupted and I was trying to restore; I had forgotten to copy my init info somewhere so I could easily recreate the repository to then restore.

But if an init always uses the info in the existing storage - when the storage already exists - why did it use the -e in my init when the storage clearly is not encrypted? I would think it should have either warned me that the existing storage is not encrypted, but my init specified it. Or at least it should NOT have written “encrypted” = true to the repository config.