[Solved] Minio, NGINX, SSL Issue

#1

I’m having trouble getting Duplicati to reach my Minio server. I set up an NGINX reverse proxy VM which forwards to the minio VM. I set up Let’s Encrypt on NGINX. I can access Minio through the appropriate subdomain using HTTPS in the web browser.

However, Duplicati throws up two different error messages, depending on how I type in the URL. If I use “url.url”, I get “Failed to connect: The request signature we calculated does not match the signature you provided. Check your key and signing method.” This happens whether or not s3-ext-forcepathstyle or “use-ssl” are selected.

If I instead use “https://url.url”, I get Failed to connect: A WebException with status NameResolutionFailure was thrown.” This happens whether or not s3-ext-forcepathstyle or “use-ssl” are selected.

#2

Welcome to the forum @johnross2007

If nobody here has an answer, you might try putting that error message in a search engine for some ideas (although some people have found that path difficult too). It probably comes from third-party library code.

Although I don’t have anything that talks S3, I did use the Duplicati GUI to play with naming, then went into Commandline in the GUI to see what had been made. Here are examples from a predefined server and a custom one, putting url.url in the customer server entry field.

s3://myaccessid-mybucket/?s3-server-name=s3.amazonaws.com&s3-location-constraint=&s3-storage-class=&auth-username=myaccessid&auth-password=mykey

s3://myaccessid-mybucket/?s3-server-name=url.url&s3-location-constraint=&s3-storage-class=&auth-username=myaccessid&auth-password=mykey

#3

Thanks! I just fixed it. Doing a backup now but it looks like its working fine.

I had not accurately followed the directions at: Minio Docs for NGINX Setup

However, including the “health_check” from that link broke NGINX. After deleting that, everything works.

I don’t understand exactly what proxy_set_header does, but its addition is what fixed my issue.

#4

For those potentially looking for more detail, the active health check with “health_check” is only supported by paid commercial nginx installations, which is likely why it was failing.