-
Does anyone have experience configuring lakeFS to use Apache Ozone for it's block storage solution? I am currently attempting this configuration myself and I'm running into AuthorizationHeaderMalformed errors. I have lakeFS and Ozone operating independently of one another, and I can interact with the ozone API endpoint to control buckets and objects: > aws s3 ls s3://ozone-bucket --endpoint https://ozone.mydomain.com --profile lakefs-user
2025-04-29 16:12:47 1453 test.txt I am using the following configuration to enable the two apps to speak: stats:
enabled: false
database:
type: postgres
blockstore:
type: s3
s3:
region: us-east-1
force_path_style: true
endpoint: https://ozone.mydomain.com
skip_verify_certificate_test_only: true
credentials:
access_key_id: XXXXX-XXXXXX-XXXXXXX
secret_access_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
gateways:
s3:
domain_name: lakefs-s3.mydomain.com
region: us-east-1
I have successfully connected MinIO to my lakeFS deployment using a similar configuration block. This is an example of the errors that I see in the lakeFS pod logs:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
I was able to resolve this issue by enabling virtual-host URLs in my Ozone deployment.
To come to this conclusion, I set In essence, lakeFS was targeting my ozone endpoint as bucket.ozone.mydomain.com/key when my Ozone application was expecting (by default) to be found at it's path-based url: ozone.mydomain.com/bucket/key |
Beta Was this translation helpful? Give feedback.
I was able to resolve this issue by enabling virtual-host URLs in my Ozone deployment.
To come to this conclusion, I set
blockstore.s3.client_log_request: true
to gather additional logs and discovered that my lakeFS deployment was configured to use virtual-host style URLs (see documentation here).In es…