Can you check the access grant with uplink access inspect <access2>. That will print out all restrictions that are set for this access grant.
It is possible to add 2 restrictions that basically contradict each other. The API key was already restricted to a specific bucket. Adding another bucket restriction could create an access grant that can’t be used for any bucket.
Now I don’t believe you have added contradicting bucket restrictions. What might have tricked you are the defaults. At least that is my common mistake.
That was it. Thank you!
If I understand correctly, the passphrase is used to derive the encryption key for the bucket. So the same passphrase must be used to create access grants or API keys for this bucket, correct?
In that case, I do not understand why Storj is giving the option to generate a new passphrase for an access grant to a existing bucket. It should inform that we must enter there the same passphrase that we used to create the bucket (?)
You can use different encryption keys. It is not required to use a single key for all files in a bucket. With a wrong key you just can’t decrypt the other files in that bucket. You could upload additional files.
One use case for that would be to build trust domains. Let’s say I want to give my wife a folder for her important files but don’t want to give her access to my files. Well, my wife is a bad example here. She knows where to find my encryption key. Anyway, I hope this example still explains it.
I don’t think it’s “default” passphrase, as in it is in no way special, and in vast number of cases, discardable. You are going to create an access grant anyway to access the storage, and that’s where you are going to specify passphrase.
The UI today combines creating a bucket and “opening” it for web access with a specified passphrase. I think these two need to separated and the UI should not be asking for a passphrase when creating a bucket altogether.
I believe there is UX redesign in the works, discussed in another thread.