I am still playing around trying to figure out how Tardigrade works.
I now have an issue of not being able to delete a bucket.
What happened is something like this:
uplink rm sj://music/song1.mp3
Error: uplink: permission denied (metainfo error: Unauthorized API credentials)
You can inspect each of the access grant, what they allows to do:
uplink access inspect --access grant1
or
uplink access inspect 1Fdr......
I’m not sure what to do with this.
$ uplink access list
=========== ACCESSES LIST: name / satellite ================================
muzik / xxx@europe-west-1.tardigrade.io:7777
prive / xxx@europe-west-1.tardigrade.io:7777
publik / xxx@europe-west-1.tardigrade.io:7777
$ uplink access inspect --access muzik
{
"satellite_addr": "xxx@europe-west-1.tardigrade.io:7777",
"encryption_access": {
"default_key": "xxx",
"default_path_cipher": "xxx"
},
"macaroon": {
"head": "xxx",
"caveats": [
{
"not_after": "xxx",
"not_before": "xxx",
"nonce": "xxx"
}
],
"tail": "xxx"
}
}
[folaht@pjehrsohmehj Prive]$ uplink ls sj://muzik/
Error: uplink: uplink: permission denied (metainfo: metainfo error: Unauthorized API credentials)
[folaht@pjehrsohmehj Prive]$ uplink ls sj://muzik/ --access muzik
Error: uplink: uplink: permission denied (metainfo: metainfo error: Unauthorized API credentials)
[folaht@pjehrsohmehj Prive]$ uplink ls sj://muzik/ --access publik
Error: uplink: uplink: permission denied (metainfo: metainfo error: Unauthorized API credentials)
[folaht@pjehrsohmehj Prive]$ uplink ls sj://muzik/ --access prive
Error: uplink: uplink: permission denied (metainfo: metainfo error: Unauthorized API credentials)
Did you have all those accesses in the Satellite UI?
Or all of them was generated in the uplink share? If so, is the basic access grant still on the satellite?
Please, check also caveats not_before and not_after, did they allow an access at the current date?
You mean in Projects? No. Do I need to recreate those access grants?
not_before and not_after check out.
You need to have either base parent (root) Access Grant in the satellite, then use it to configure or import to the uplink and then create other (Child) access grants for other purposes. Or have each of Access Grants with all caveats generated in the satellite UI.
If you deleted a root access grant, all derived accesses are automatically revoked too.
How can one see which one is root?
I have probably done that.
I kept deleted and recreated all my access grants because I wanted a change of names.
Is there a way to regain root access grant?
Yes, just create another one and import it to the uplink import --overwrite.
If you want to import it with a different named access instead of default, you can specify it in the uplink import --access named-access 1Dfgkrk.... --overwrite
You will need to create derived access grants with the uplink share for all your previous accesses, because previous ones have been revoked with deleting an access grant from the satellite UI.
Or you can generate a new ones in the satellite UI directly, then they would be independent on each other.
$ uplink share --access=prive
$ echo 1Dfgkrk... | tee prive.access
$ uplink import prive prive.access --overwrite
access "prive" overwritten.
Nothing changed.
[folaht@pjehrsohmehj Prive]$ uplink ls sj://muzik/ --access prive
Error: uplink: uplink: permission denied (metainfo: metainfo error: Unauthorized API credentials)
[update]
[folaht@pjehrsohmehj Prive]$ uplink share
Sharing access to satellite ...@europe-west-1.tardigrade.io:7777
=========== ACCESS RESTRICTIONS ==========================================================
...
Paths : WARNING! The entire project is shared!
=========== SERIALIZED ACCESS WITH THE ABOVE RESTRICTIONS TO SHARE WITH OTHERS ===========
Access :
1Dfgkrk...
[folaht@pjehrsohmehj Prive]$ uplink import 1Dfgkrk... --overwrite
default access overwritten.
[folaht@pjehrsohmehj Prive]$ uplink ls sj://muzik
Error: uplink: uplink: permission denied (metainfo: metainfo error: Unauthorized API credentials)
[folaht@pjehrsohmehj Prive]$ uplink ls sj://dosje
Error: uplink: uplink: permission denied (metainfo: metainfo error: Unauthorized API credentials)
Still no luck.
I did find out that the accesses are in plain code of config.yaml.
They match all the access files I’ve written.
I’ve also noticed that when I delete the access grants in the browser, they still show up in uplink access list, but “default” is missing.
I probably want to delete all of them except the default one, assuming I can pick and choose which folders on which client I want shared with rclone.
The access grants in the satellite is not synced with accesses in the uplink. They serves the same purpose, but they are independent.
When you shared an access via uplink, you should not import it to the same uplink to the default access again.
I would suggest to delete all accesses to be not messed up, clear the browser cache and cookies and generate a new access grant, import it to the uplink
Make sure that you have an access with that access grant first:
uplink import 1bFGhh... --overwrite
uplink ls
If all ok, then you can create an restricted access grant to the some bucket
uplink share sj://muzic
and import the result to a different named access (not to default on the same PC account at least 
):
uplink import --access muzic 1Fght.... --overwrite
uplink --access muzic ls
Delete all accesses in the satellite or uplink? If both, how do I do the latter?
I tried revoking:
[folaht@pjehrsohmehj ~]$ uplink revoke --access muzik
Error: accepts 1 arg(s), received 0
[folaht@pjehrsohmehj ~]$ uplink revoke muzik
Error: invalid access provided
PS. While reading this documentation page
I come across this sentence…
For anyone who has previously configured an uplink please use the blahblaghblag
I think there might be a typo in there.
Thank you! Fixed an issue in the documentation.
And created a bug regarding revoke a named access grant. At the moment you should provide the serialized access grant after uplink revoke.
However, when I asked to remove accesses I mean to remove them from the satellite UI and from the config.yaml (or remove the config.yaml).
The revoking is working too, but the accesses will remained in the config.yaml, and if would try to use them, they will say that they are not authorized to do anything. This is the same result as if you remove the root access grants from the satellite,