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^
-encrypt^
-key xxxxxxxx.pem^
-erasure-coding 5:2^
-repository xxxxxxxxxxx^
new-storj-name^
snapshot-id^
storj://12EayRxxxxxxxxxxxxxxxxxxxxxxxxxxxx@us1.storj.io:7777/bucket-name
preferences files look like this:
"name": "xxxxxxxxxxxxxxxx",
"id": "xxxxxxxxxxxxxxxxxxx",
"repository": "xxxxxxxxxxxxxxxxxxxxxx",
"storage": "storj://12Eaxxxxxxxxxxxxxxxxps3S@us1.storj.io:7777/bucket-name",
"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.
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:
wasabi://us-east-1@s3.wasabisys.com/bucket/path
wasabi://us-east-2@s3.us-east-2.wasabisys.com/bucket/path
wasabi://us-west-1@s3.us-west-1.wasabisys.com/bucket/path
wasabi://eu-central-1@s3.eu-central-1.wasabisys.com/bucket/path
And
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.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.