[Bug]: Error 400 when using Minio

[mortegro]

What happened?

Thanks für trying to keep remotly-save secure.

When I use the plugin with a minio backend i get the following error for every file:

plugin:remotely-secure:180 Error: Request failed, status 400
at new t (app.js:1:1762600)
at gq (app.js:1:1762792)
at app.js:1:1763469
at app.js:1:237258
at Object.next (app.js:1:237363)
at a (app.js:1:236081)
syncRun @ plugin:remotely-secure:180
await in syncRun (async)
eval @ plugin:remotely-secure:182

The bucket can be accessed and the connection-check works fine. The file "_remotely-secure-metadata-on-remote.json" is created in the bucket.

Is there a way to debug this further?
Thanks in advance.

What OS are you using?

Linux

What remote cloud services are you using?

S3

Version of the plugin

0.4.32

Version of Obsidian

1.5.3

Using password or not

• Yes.

Ensure no sensitive information

• I ensure that no sensitive information is submitted in the issue.

[sboesen]

Hmm. Will look into this and try to reproduce this, may take a few days before I can look into this one. Sorry about the error :(

Are you self hosting minio? Any logs on the server end if so which might help explain the 400?

[mortegro]

Thanks for the quick response. After i bit of detective work i found the error in the server logs:

<Error>
<Code>AccessDenied</Code>
<Message>There were headers present in the request which were not signed</Message>
...
</Error>

The only difference to the request from the working remotly-save plugin is the "x-amz-meta-modification_time". I can see the header in the network-tab in obsidian but in the server-logs the header is not present. The put of the "_remotely-secure-metadata-on-remote.json" does not have this header and works.

With disabling the metadata-sync in the option it works fine ...

[sboesen]

Very interesting. We plan to stop sending this metadata in general in favor of a generic solution, #60 - but until then will add a note for Minio in the readme. Thank you for investigating and following up! Closing this issue in favor of the generic metadata solution in #60.