CloudFlare R2 - Can't Establish Connection

[chrisspiegl]

I am trying to use R2 with Mountainduck.
I set up the API Access Key ID and Secret Access Key via the R2 interface and got the URL for the bucket.
Separating the bucket name /files-production from the URL and entered it with the Cloudflare R2 Storage (S3) Profile.

However, I can't establish a connection and wonder what may be the case? I tried looking at the docs but could not get any additional information.

I also noticed that the <key>Hostname Placeholder</key><string>&lt;accountid&gt;.r2.cloudflarestorage.com</string> in the profile does not appear to be working since instead of this, it just displays the s3.amazonaws.com in the Server field. Or rather: the placeholder is working, but the default URL that is visible when selecting the profile is s3.amazonaws.com.

Anyone with a working R2 connection? Maybe you can help me out here?

Here is the login error message and the config of the R2 API Keys:

[dkocher]

Please confirm you are using the Cloudflare R2 Storage (S3) enabled from Preferences → Profiles.

[dkocher]

Can you confirm you have only the Account ID in the hostname set in Server but not the bucket. I cannot reproduce with a equivalent setup accessing a single bucket in CloudFlare R2 by setting it in the Path field.

[chrisspiegl]

I have set the details exactly as shown on the screenshot.
In the Server: field, I have ACCOUNTID.r2.cloudfalrestoreage.com as it is given by Cloudfalre.
I cannot enter any path after the .com since then an error DNS LOOKUP FAILED will happen.

The Path: field is then set to the bucket name based on how it is set up on CloudFlare.

I also have worked with Cloudflare in other S3 libraries when working directly with code, and it did work. So I am not clear what may be going on. Which is why I am reaching out for help here. Thinking I may be missing something? Some setting I should chagne? Set different?

[dkocher]

Your configuration looks sane. Do you connect through a HTTP proxy that might interfere with request headers?

[chrisspiegl]

No HTTP Proxy as far as I am aware. That is very strange.

[chrisspiegl]

I had time to test some more and found out the following (which finalizes this for me for now):

My initial testing with my files-production bucket kept not working. This bucket was set to be located in the EU based on the ability to set this in Cloudflare when creating the bucket. Then you also use the ACCOUNT_ID.eu.r2.cloudflarestorage.com URL (note .eu. in there).

Then I created a test bucket which was not “locked” to be in the EU, and I was able to connect to that bucket (obviously also using the ACCOUNT_ID.r2.cloudflarestorage.com the version without the .eu.).

I then created a new bucket which has a “location hint” to be set to “Western Europe”. Again, it is working (without the .eu.).

So, using “Location: Automatic” instead of “Location: Specify jurisdiction” works.

I don't quite understand why that may be… and I don't care enough about the “Specific jurisdiction” to investigate further, now that I have a working version.

[dkocher]

It looks like CloudFlare R2 introduced support for location constraints ¹. I recall previously only auto was available and is set accordingly in the connection profile. Because the region is part of the request signature calculation that explains the failure authenticating for buckets with a location constraints. I have opened ² to look into this.

Footnotes

1. https://developers.cloudflare.com/r2/reference/data-location/#available-hints ↩

2. Add location constraints for CloudFlare R2 profiles#91 ↩

[chrisspiegl]

That explains a lot. One thing to note: it's not just about the available-hints but more importantly, in my case, about the Jurisdictions with S3 API.

The strange thing here (based on the docs by Cloudflare):

They say that the region: "auto" should still be set to auto and the only difference is the url containing the .eu. qualifier?

[dkocher]

The use of a different endpoint only applies to the jurisdictional feature. But I assume the same applies here that requests must be signed for the specific location instead of auto.

Jurisdictional buckets can only be accessed via the corresponding jurisdictional endpoint. ¹

Footnotes

1. https://developers.cloudflare.com/r2/api/s3/tokens/ ↩

[dkocher]

@chrisspiegl You may want to try the connection profile from ¹ by replacing the version in the Profiles of your application support folder.

Footnotes

1. Fix #91. profiles#92 ↩

[chrisspiegl]

I'll try the profile; however, I think these are two different things.

From the Cloudflare Docs, they literally show in the code example that one should use region: "auto" when using the jurisdictional buckets and only change the corresponding endpoint? Which makes me believe that the “region hints” have nothing to-do with it (see code example from the Cloudflare docs page):