Object Storage Issue in us-southeast-1
I am encountering several issues with Object Storage in the us-southeast-1 region. I am trying to upload files to the storage using Rclone and have gotten a few different errors depending on the exact configuration I use. I can read the data, but not write. I encounter no issues with I use the us-east-1 region for the object storage instead.
This is my rclone config file:
[ets-storage]
type = s3
env_auth = false
provider = Other
access_key_id = ****
secret_access_key = ****
region = us-southeast-1
endpoint = us-southeast-1.linodeobjects.com
acl = private[ets-storage2]
type = s3
env_auth = false
provider = Other
access_key_id = ****
secret_access_key = ****
region = us-east-1
endpoint = us-east-1.linodeobjects.com
acl = private
When using this config, I get the error:
InvalidLocationConstraint: The specified location-constraint is not valid
status code: 400, request id: , host id:
I also tried changing the endpoint to be the entire URL including the bucket name itself and not just region.linodeobjects.com. When I do this, I get the error:
2023/08/24 20:55:16 Failed to copy: InvalidParameter: 1 validation error(s) found.
minimum field size of 1, HeadObjectInput.Key.
I am not sure if I have an issue in my config somewhere, but as far as I can tell the configuration between us-east-1 and us-southeast-1 are the same, but one works and the other doesn't. Any help you can provide would be appreciated.
Thank you.
1 Reply
eruzanski
Linode Staff
I successfully employed Rclone in conjunction with Object Storage by following the steps outlined in the guide titled Use Rclone to Sync Files to Linode Object Storage.
In comparing the provided documentation with your configuration, I observed a few distinctions. Notably, our guide suggests opting for Ceph as the provider and omitting the specification of a region. This variance might account for the encountered error, although I'm still puzzled as to why the error seems to manifest in one region exclusively.
Interestingly, it's worth noting that our documentation highlights the inclusion of the https:// segment in the S3 endpoints, a detail I adhered to during my testing as well. This subtle difference in formatting could potentially contribute to the divergence in outcomes.