Interesting. I’ve encountered the same error when trying to add a ‘new’ S3-compatible storage, but an ‘old’ existing connection Google Cloud S3-compatible storage wasn’t affected.
To clarify: I personally cannot afford any S3-compatible cloud storage (alas…) for the amount of data I have on Cells; however, I’m constantly experimenting with whatever kind provider is happy to give me a free trial, and see how well such providers will integrate with the rest of my complicated setup
I haven’t tested Backblaze yet, but it’s quite clear that they only support V4 authentication, as do most of the providers I have been playing around with. Google Cloud apparently still supports V2 authentication — although they seriously encourage the upgrade to V4 — and that might be the reason why I had no problems with their connection.
Interestingly, when trying to connect to Cells using its own S3 API, it seems that only V4 authentication is supported. I suspected as much when doing some tests in the distant past, but today I experimented with the popular, generic s3cmd Python-based command-line tool to access remote buckets. It has no problems connecting to Cells via V4 authentication, but throws an (expected) error using V2. The documentation for this is very straightforward and doesn’t go into details.
So, it seems that Cells is correctly configured to accept only V4 authentication for its own datasources, but it fails to connect with V4 authentication when mounting external datasources?
{
"level": "info",
"ts": "2022-10-24T13:25:41Z",
"logger": "pydio.grpc.data.sync.personal",
"msg": "{\"level\":\"warn\",\"ts\":\"2022-10-24T13:25:41Z\",\"logger\":\"pydio.grpc.data.sync.personal\",\"msg\":\"Cannot contact s3 service (bucket cloud-personal), will retry in 1s\",\"error\":\"The V2 signature authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256\"}"
}
Formatted message:
{
"level": "warn",
"ts": "2022-10-24T13:25:41Z",
"logger": "pydio.grpc.data.sync.personal",
"msg": "Cannot contact s3 service (bucket cloud-personal), will retry in 1s",
"error": "The V2 signature authorization mechanism you have provided is not supported. Please use AWS4-HMAC-SHA256"
}
I just made a test with 4.0.2-rc1. As said, I’m not using Backblaze, but rather Cloudflare R2, which also only accepts v4 signatures.
I can confirm that it works when manually editingpydio.json to create a new Storage + Workspace (since from the web backoffice I will constantly get the “V2 signature authorization not supported” error) and adding the GatewayConfiguration object just for the service, while using StorageConfiguration elsewhere — both with "signatureVersion": "v4".
When logging back in and attempting to change any Workspace settings, the usual “v2 not supported” error appears and prevents me from editing anything and saving; but manually changing pydio.json and restarting Cells will work.
I believe I could try a few more providers (lots of copy & pasting of configuration aspects which I have no idea about what I’m doing) if you wish, but I now believe that all will work — so I guess that for the final release of 4.0.2, you could simply consider “v4” the default signature type, and just let all the configuration use it as a default — and nobody will have any issues.
And for 4.1 you could add the selection of v2 vs. v4 as an option on the web interface, although the truth is that v2 is pretty much obsolete and deprecated on all storage providers compatible with the S3 API — it’s just used for some more obscure APIs that Amazon provides to other services (at least that’s what I managed to figure out). Thus, dropping v2 signatures for object storage (and making v4 the default) should have no impact on existing services.
But that’s just my opinion There are thousands of providers around, and there might be the odd exception here or there… thus, having the ability to fall back to v2 is perhaps a good idea.