I have been a SNO for ~2.5 years now, and last week id ecided to migrate all my backups from Google Drive to Storj, because I really feel I like the project and now that I know how it works, it feels the most secure and distributed object storage - at least that I know.
In my home NAS I’m using TrueNAS, and after applying the last updates I saw there is an option to add Storj (iX) as a cloud sync provider, so I decided to give it a try.
I used my Storj DCS account, created a S3 access grant (as TrueNAS was asking for Access Key and Acess Secret) and put it in TrueNAS. It says credentials are valid but… no bucket was shown.
I have asked in TrueNAS forums (link) and I got a response telling me that it works for accounts created in http://ix.storj.io only.
What’s the difference between my account (created as a normal account) and the ones created through that form?
Why is not the same accounts?
If anyone else is in the same situation, I fixed it by adding the Storj account on TrueNAS as an S3 account, using the awesome gateway service (thanks for that!)
Hi @odarriba
Whilst I don’t know for sure the only obvious difference for accounts created with http://ix.storj.io/ compared to the regular EU1 or US1 would be the first link marks your account as a partner account with ix, so they would receive a revenue split with Storj on any bills you pay. Unless there is something secret going on behind the scenes functionally the accounts should work the same.
IMHO TrueNAS is displaying only the buckets, which has a specific attribution metadata (like created/used by IX). Classic Storj accounts doesn’t have these metadata on buckets. But as I read in the forum it will be fixed soon (TrueNAS can create new bucket with the required metadata, even if “classic” Storj account is used)
That make sense (although I dont understand why, aside from billing split due to partnership). Also, I cannot find a way toc reate a bucket from TrueNAS, so I suppose I will stay with the S3 integration.
Is there any plan to use direct uplink uploads directly from their software? Or just using the S3 gateway?
FWIW, on TrueNAS Core 13.2, Cloud Sync task sees the bucket(s), but they are grayed out: (I’ve created fresh S3 credentials, but in my existing storj account, for the new bucket “meow” with full access to that bucket):
Am I supposed to create a new Storj account, with a different email address, via ix.storj.com? Because if I pick Log In from that page, as opposed to creating new account, the partnership seems to be lost. (If preserving partnership param in the URL is important in the first place).
There does not seem to be a way to create a new bucket with the right metadata either, on TrueNAS core.
You cannot see buckets created using a Storj DCS account that you did not create from inside the IX-Systems software through their signup link. TrueNAS is displaying only buckets which have a specific attribution metadata (indicating they were created/used by IX ) while regular Storj accounts do not have these metadata for the IX buckets by default.
However, if you file a support ticket and share with us what is the name of the project and bucket which you want to be able to access from TrueNAS/IX-Systems, we will be able to have our prod owner add an attribution tag to that bucket so that it will become visible for you.
I see, thank you, that was my understanding too. I, however, expected to actually not see the buckets in the list, as opposed to see them, but being unable to select and use them.
I don’t think there is a way to create buckets from TrueNAS Core 13.0 U3 as of today, the U3 update just added support for storj in the cloud credentials list: [NAS-117827] - iXsystems Jira
I’m nog going to bother support with this, I can use rclone explicitly. Just wanted to try out an announced built-in support.
You should be able to create buckets from TrueNAS Core if you signed up for a Storj DCS account through the signup link - more details for interested parties here.
I logged in to my account at us1.storj.io and created a new bucket. I had to create a passphrase for the bucket, however TrueNAS is using the passphrase associated with S3 credentials, so that new bucket passphrase is kind of useless.
Sync succeeded, and I could see the bucket content via the web using the other passphrase.
To see objects in these buckets you need to use the encryption phrase used when you created an s3 credentials, otherwise your buckets will look like empty.
Please note, the encryption phrase is not tied with the bucket, it’s used to encrypt/decrypt objects in any bucket.
Thank you, yes, I understand that; each bucket can have multiple objects encrypted in various ways and only decrypt-able with the provided key ones will be enumerated and presented. I was just pointing out that the whole process of “getting TrueNAS core to sync to storj bucket” could have been more streamlined, without blaming anything in particular: had TrueNAS provided a way to create a bucket I would not have needed to go throw the process of creating one in the web ui, that in turn required me to generate another key, that is useless in this scenario.
Actually, the wording the bucket creation does in fact imply that the encryption key is tied to the bucket:
Perhaps bucket creation flow should not enforce selection of the key?
Edit: actually, i realize I should have selected the second option and entered the
key from s3 credential generation stage. It’s obvious in the hindsight.
Regarding TrueNAS I’m agree, that allowing to create a bucket right from the UI would be better, we will pass this feedback to their team.
The encryption phrase is requested when you create a bucket or enter to the bucket because it will open this bucket and allow you to upload/download files right away.
I do not know how to make this process better. One way would be to request the encryption phrase when you try to upload, but this will not work, when you open a bucket with existing objects.
Please suggest the correct wording, which could help to understand that encryption phrase is used to encrypt/decrypt objects in this bucket.
Maybe the better solution would be to remove that step (asking for passphrase) when creating the bucket altogether?
When opening a existing bucket, the password is requested anyway, and therefore asking for it during bucket creation is a convenience feature, that combines creation a bucket (forever) and opening it (for this session).
It would be fine if creating a bucket just ended with asking its name. Then if the user wants to upload to it via web right away - they could use that other existing “open bucket” flow to open it, and provide passphrase there.
There, on “open bucket” flow, however, I would also improve wording
Right now after clicking on a bucket we get prompt: “To open a bucket and view your files, please enter the encryption passphrase you saved upon creating this bucket”.
Sometimes it’s plain wrong - to see my TrueNAS uploaded files for example I have to ignore this advice and provid passphrase I used when creating s3 credentials, not bucket.
I don’t have to follow this suggestion anyway, and can provide any arbitrary new passphrase. It will be accepted just the same, and while I would not be able to see objects uploaded with different passphrase I would be able to upload new objects with this new passphrase. This information is actually presented on another pop up, albeit too late, after I disregard request and enter “wrong” passphrase:
“Do you know a bucket can have multiple passphrases?
Which is also misleading. It’s not bucket that can have multiple passphrases, it’s objects in they bucket
So, in summary, I would do two things:
remove passphrase request from bucket creation flow. it only needs to ask new bucket’s name.
wording on opening bucket flow should incorporate message from that later popup and inform the user that any passphrase is acceptable but only objects uploaded with that passphrase will be visible.
Maybe something like:
To open a bucket and view your files, please enter the encryption passphrase used for those files.
Did you know? Bucket can contain objects encrypted with different passphrases. If you don’t see the objects you’re looking for, try opening the bucket again with a different passphrase
Then the other popup would not be needed as user will have all necessary information prior to entering the passphrase
I even ended up having a call with @liviaholanda regarding this to provide feedback. It seems UX design didn’t talk enough to the engineers to make the descriptions actually match how the product works and it’s leading to this confusion that keeps popping up. I hope some changes are already in the works behind the scenes based on earlier feedback. But yeah, this confirms once again that changes are needed.
