aptalca

I occasionally see them too. They don't seem to cause any issues

Did you put both letsencrypt and ombi on the same custom network as described in the readme? Are you using the default default site config, which has the include statement inside the server block for the proxy-confs? If you modified that part, delete the default site config and restart. After that navigate to https://yourdomain/ombi

What are you trying to accomplish with the auth_request line? What is /auth-4 referring to? Just remove that ombi config and use the built-in one. Instructions here: https://github.com/linuxserver/docker-letsencrypt/blob/master/README.md#site-config-and-reverse-proxy

As far as validation goes, your server does not need to be reachable from the internet as long as you use dns validation. Your server (the container) will connect to the letsencrypt servers and get a key, post it on cloudflare (or another supported dns provider) and then the letsencrypt servers will connect to the dns server to check the txt record. They won't try and connect to your unraid machine. The only connection from unraid will be outgoing. My question is, what is your purpose for getting the cert? If you want to use the cert for openvpn, you can use letsencrypt to get it and manage it, and then you can mount the folder in the openvpn container and point to the cert. If you want to use it for local connections but still with third party validation, I guess you can do that as long as your dns directs local clients to the local address when they query for the domain name (pfsense will do it with dns resolver).

Issue 1: you are redirecting from www.yourdomain to yourdomain, however you have the option only_subdomains set to true, so your cert only covers www, but not yourdomain Issue 2: are you using ldap for authorization? How is that set up? Issue 3: nginx isn't even starting for you because you have another site config enabled somewhere with a server block that contains the "default_server" directive

That's just the problem. Acme challenge key is generated on the fly by letsencrypt servers. So you can't really do that with a variable. Manual validation process goes like this: 1) user types certbot to start process (can include variables like url, email, validation type, etc) 2) Letsencrypt generates and outputs a key, starts waiting 3) User goes on their dns provider's interface and creates a new txt record with that key 4) User tells certbot they created it and it propagated 5) Letsencrypt checks the dns records to confirm txt record and provides user the cert As you can see, the above process requires user interaction, which presents two problems, it is hard to do in docker start up, and it cannot be automated. You have to go through the manual process every 90 days. The dns plugins automate the process by taking care of steps 3 and 4,but it requires a specific login for each dns provider as their apis for updating records are vastly different. If you're willing to do that manual process, you can use our nginx image instead, and run certbot in it manually. As for the feature request, please submit it here: https://github.com/certbot/certbot PS. I personally don't think using cloudflare is a workaround. It delivers about 10% of the internet (cdn, proxy) and I bet it is a lot more reliable as a dns provider than any hosting company

I'm sorry but we're all adults here and I can't hold your hand. There are 3 references to --cap-add on that page and if you read all three, you'll realize what it means. There is also google search that provides a lot of answers to common questions. Everybody's environment and needs are different. A step by step guide may work for someone in a specific situation, but not another person. Some people like subfolder, some like subdomain methods for reverse proxy, some want to password protect, some don't, some want to use organizr as their homepage, some prefer heimdall, etc. We provide the tools and the instructions on how to use them. You need to put in some effort to try and understand how things fit together rather than blindly follow some guide that may or may not work for what you're trying to achieve. We already made reverse proxy as easy as possible with the preset configs. I honestly don't know what a step by step guide would add since you already have letsencrypt set up and can access the homepage. That's usually the hard part due to port forwarding.

You need to create that folder if it doesn't exist, and drop your custom user profiles in there: https://forums.plex.tv/discussion/73702/writing-profiles-for-dlna-devices

The devs of these projects have provided all the information one needs to set this up. There are even preset reverse proxy configs for common apps, most of which only require a simple rename of a file to activate (including both ombi and nextcloud): https://github.com/linuxserver/docker-letsencrypt/blob/master/README.md#setting-up-the-application

They all do it through txt records. The reason api keys or tokens are needed is so letsencrypt (certbot) can create the txt records itself for automation, rather than asking the users to do it manually. You can always point your name servers to a supported free dns service like cloudflare and use their plugin.

Easiest way at the moment is to buy a cheap domain name and point the name servers to cloudflare

We support the official dns plugins maintained by letsencrypt (certbot) and unfortunately there isn't one for duckdns yet. Perhaps you can submit a request to them: https://github.com/certbot/certbot

This container already supports dns validation

Yup, I should have clarified. I rebooted the server that hosts the appfeed (restarted the container rather) and it started working. No clue what the issue was. But then again, my years of providing tech support to extended family taught me that the first step of turning things off and back on tends to fix 95% of the problems lol

Works great. Thanks

I use unifi, but only for APs. The router is pfsense

Rebooted the server, the feed is back

Delete the config folder and recreate the docker

Nginx is not doing anything wrong, nginx (in this container) is not even up during validation. What you're seeing here is that when the letsencrypt server tries to connect to your domain on port 443 to validate, it gets a response from the unraid server's gui instead of the webserver in the container. It means your port forwarding is not correct.

I have some nfs mounts and on the dashboard, only some of them show the used space correctly. I have a suspicion it might have to do with spaces in mount names. Notice how in the attached screenshot, the ones without spaces show correctly and the ones with spaces don't? Thanks

https://github.com/linuxserver/docker-heimdall/blob/master/README.md#adding-password-protection

Oh yeah, the tautulli mobile app doesn't support other auth methods. I had to switch to the built in authentication in tautulli

In tautulli settings, did you check "enable http proxy" and "enable https"? If so, don't. Also, did you modify the tautulli proxy conf file to put in the internal ip? You weren't supposed to modify it at all. Only set the http root and restart the tautulli container, then rename the conf file and restart letsencrypt. That's all.

Yes, as long as they all use the same token (under same account) Enter them comma separated, no spaces

You can't put in a domain name in a location directive like that. Location is for subfolders, server block and server name are for domain names. For handling two domains differently, you need to create two server blocks, one will have server name of domain A and the other will have domain B Look at that cp example I linked to. It is a second server block where the server name is set to a different subdomain (cp.*). You can change that to domain B It's not really coding. It's a basic nginx config. If you're still confused, there are plenty of how tos and guides online about how the different sections in the nginx site config work EDIT: also if you have no idea what something does, rule of thumb is, don't delete it. Everything in that default config is put there for a reason. Deleting things randomly is a recipe for breakage. And don't put random text in places without commenting them out. Nginx will try to interpret it as actual settings and will error out.