Am I doing this "the hard way?"

I’m expanding my use of Storj to include backup data that are isolated from one another by access grant and project passphrase.

I found a way that works, but it seems so convoluted I’m wondering if there’s an easier way. Am I doing this in an unnecessarily difficult way?

  1. In Satellite, create an API key
  2. With uplink CLI, create an access grant with satellite URL+API key+passphrase
  3. With uplink CLI, restrict the access grant by prefix, e.g., sj://mybucket/
  4. Configure backup app with restricted access grant

In the past I had accomplished the same result by directly creating an access grant in the hosted Satellite UI for specific buckets and specifying a new passphrase. This worked for one of my sites, then I could not (for the life of me) reproduce my own success.

For the second site, the access grant I created in the Satellite UI always lacked write privilege, whereas it was granted write privilege for the first site.

The only explanation I can think of is that the default restrictions for access grants in Satellite may have changed recently, like in the last month?

Thanks for a powerful storage platform. I’m loving it more and more.

Hello @qrkourier,
Welcome back!

Now in the UI you cannot generate an access grant limited to the bucket without specifying what are exact permissions would you like to grant.
So, if you would create a usual access grant, the “Full permissions” is the default option. So, to make it limited to a bucket, you need to enable “Advanced” in the Wizard, the next screen would request permissions (Write, List, Read, Delete) and you should explicitly select them, only then you would be able to select also a bucket.
Is it possible, that you missed to select a Write permission somehow?

However, the default access permissions for the uplink share command is read-only, that’s true. You need to provide what are permissions should be there, i.e.

uplink share --readonly=false --disallow-reads --disallow-deletes --not-after=+1h --register sj://my-bucket/my-prefix/

I misinterpreted this Satellite component to mean “all permissions granted” which is what I wanted for the bucket-scoped grant. I never interacted with the component because the “all permissions” button appears to be selected.

Now it’s clear why the access grants I created through the new Satellite UI were properly bucket scoped with no privileges (no actions allowed).

You recommended uplink share. I seem to accomplished the same result with uplink access create without being aware of uplink share. I take it uplink share is more convenient because it will create a subordinate grant for the currently-selected access grant, whereas uplink access create requires a new Satellite URL and API key, effectively rooting the new grant below a different grant in the hierarchy. It seems both will result in access grants I can’t see in Satellite, so I’ll prefer to create new grants in Satellite so that I can remember and keep track of them.

Thank you!

I see, perhaps we need to disable the Next button if you didn’t select any permissions in that Wizard.

Yes, you are correct.
You may also provide an existing access with the --access option, i.e.

uplink share --access us1-demo --readonly=false --disallow-reads --disallow-deletes --not-after=+1h --register sj://my-bucket/my-prefix/

Here the value us1-demo is for the access with the name “us1-demo”, you may also provide it in the serialized form, too:

uplink share --access 1Ka6CQmqHXESq.... --readonly=false --disallow-reads --disallow-deletes --not-after=+1h --register sj://my-bucket/my-prefix/

When you create the access grant using the satellite address, the API key and the encryption phrase you may specify to save this access grant as a named access with the option --import-as.

uplink access create --import-as my-new

After that you may use either uplink access restrict --access my-new --prefix sj://my-bucket/my-prefix/ or uplink share --access my-new sj://my-bucket/my-prefix/

Yes, they are stored locally.