Storj in web ui - requiring directory

I’m testing Storj storage with the web version. When trying to configure an existing storage (which I created with CLI), it doesn’t let me go ahead if I don’t inform a directory (the “continue” button remains gray), but the storage was created directly at the root of the bucket, without sub directories . Of course, if I enter any directory, it understands that I’m initializing a new storage.

Am I missing something?

An interesting question is how did you init the storage in CLI without specifying a prefix (“path”)? IIRC every backend requires a “path” and does not create the backup in the “root”.

Are you saying you have “config” right in your bucket with no prefix?

If so, it seems it’s a CLI bug that allowed you do so that and the solution would be mass-rename the files to add the “folder” prefix.

These storages in Storj were created as copies of storages I have in Wasabi, with commands like:

duplicacy add^
 -copy wasabi-storage-name^
 -key xxxxxxxx.pem^
 -erasure-coding 5:2^
 -repository xxxxxxxxxxx^

preferences files look like this:

"name": "xxxxxxxxxxxxxxxx",
"id": "xxxxxxxxxxxxxxxxxxx",
"repository": "xxxxxxxxxxxxxxxxxxxxxx",
"storage": "storj://",
"encrypted": true,
"no_backup": false,
"no_restore": false,
"no_save_password": false,
"nobackup_file": "",
"keys": {
    "password": "xxxxxxxxxxxxxxx",		
    "storj_key": "xxxxxxxxxxxxxx",
    "storj_passphrase": "xxxxxxxxxxxxxxxxxxxx"
"filters": "",
"exclude_by_attribute": false

and they work perfectly with CLI.

:thinking: All my bucket storages (B2, S3, Wasabi, Storj) never had subdirectories (I set up a bucket for each set of backups) and they always worked perfectly.

The manual says to specify a path under the bucket:

Storage URL: 


Storage URL: storj://satellite/bucket/path

CLI does not enforce it apparently but webui does.

So whether the bug is in CLI (not enforcing) or webui (not supporting) and documentation (not specifying path is optional) — up to @gchen

Storj is already erasure coded itself. Why are you erasure coding it on top?

I agree.

True, it’s just a practice that I’ve always had since the feature was released, I agree that in this case it’s unnecessary.

An empty storage path should be supported. The webui has an unnecessary check that disabled the continue button when a storage path is not entered. I’ll fix this.


I’m thinking of directly editing the preferences file to continue testing with web version. Thinking that there are those folders/files that are dynamically generated, in which folder should I edit the preferences so that the change is permanent?

Preferences are not persistent. You would need to edit the duplicacy.json.

Ah, that was the trick I wasn’t remembering, it’s been a long time since I made manual changes to the settings. Thanks!

hmmm, the problem is that I have an “encryption password”, so I can’t directly edit the credentials fields of the json, and I haven’t found an option to disable this “encryption password” in webui.

@gchen, is there any way that I can accomplish this “direct json edit method” while we doesn’t have a new webui version?

The storage url in ~/.duplicacy-web/duplicacy.json can be directly edited. So I think you can create a dummy storage with an arbitrary subdirectory, and then edit the storage url to remove the subdirectory.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.