I am using dremio-community-4.0.1-201909191652190301_211720e_1.noarch.rpm
I have dremio (single node) running aws ec2 (under company vpc), server is up and I am able to login to dremio UI and create postgres data source and run query.
I did add the required read policy to the role that was assigned to ec2. I am able to run the following commands by logging into ec2:
[ec2-user@ip-10-83-21-86 ~] aws s3 ls trhub1stg-cato --recursive
[ec2-user@ip-10-83-21-86 ~] aws sts get-caller-identity
For us, this same error occurred immediately upon updating from version 3.3.2-201908141640190085-d60145d to version 4.0.2-201910020123580864-a98a0b9. We’ve performed similar troubleshooting steps and have found the same issues as @rlin.
We’re also working with our support team to figure out why this is occurring.
@rlin, we enabled Compatibility Mode (Experimental) in the Advanced Options of our S3 Connection and it immediately started working again. It might be a fluke, but now we’re able to run queries.
There were some new fields added to the advanced options, most notably Encryption Key ARN. As we use several different encryption keys within that s3 connection, we can’t use that field. Perhaps the compatibility mode gets Dremio to ignore that field when making the API call? Just speculation.
Hi @balaji.ramaswamy,
I am having a similar issue with Wasabi S3 buckets (like Minio).
@Ben kindly helped me, but I thought I’d loop you in in case you had seen this.
It appears the Dremio S3 layer is trying to authenticate against AWS rather than Wasabi. Is there a property or configuration that would force Dremio to authenticate against Wasabi?