aptalca

I don't believe that's container related. You should ask in one of the unraid threads.

Do you have the app installed and logged in? Are you hitting that link while on the mobile device you installed and set up the app? I just installed the app on my phone, entered the url with subfolder, and logged in. The app works. And hitting that link in the mobile browser launched the app. The link won't do anything until your phone registers those mobile links with the ombi app which won't happen until you install it and set it up.

Did you use the preset conf? That one is confirmed working with the mobile app (by others). Unfortunately I don't own the app so I can't test.

Post a screenshot of your settings

Because your nextcloud is configured to redirect all connections to the domain name

Did you follow the directions at the top of the sample conf file? Once set up, you're supposed to access nextcloud through your domain not the local ip, because it will redirect everything to your ip. If you're seeing the welcome message, you have an issue with a redirect. Clear your browser cache, then recheck your settings.

For the first part, yes. The thumbs are in a folder called media (iirc). You can move that folder to the array and create a symlink in its place. You need to make sure that the symlinked location is accessible from inside the container. Once it is symlinked and out of your appdata folder, ca backup should not back up that location (unless you specifically select it)

There is an extra domains variable: https://github.com/linuxserver/docker-letsencrypt/blob/master/README.md That will let you get a cert that covers them. Then you manage the different domains via server name directives in the site config. For example, each server block would be for a different domain and you set the server names accordingly.

It's renewed automatically as long as you don't change the port forwarding or whatever else is necessary for validation

Don't use the conf you got from the ombi github. It's not correct in this use case. Follow the directions here: https://github.com/linuxserver/docker-letsencrypt/blob/master/README.md#site-config-and-reverse-proxy

You need to go to your domain, not the local ip, and use https. It's in the readme.

That's likely the issue. Don't use double auth. Use either grafana's built in or htpasswd.

How do you access the unraid gui?

I only got it when I accidentally enabled pgs subs (forced transcode) on a high bitrate h265 file on my low power server. If the transcode rate is less than 1x, you'll get that message. Could there be an issue with the write speeds on the drive that causes a bottleneck and a low transcode rate?

Do you have any authentication options set up in grafana by any chance? Dual auth could cause problems. I haven't used grafana but your proxy conf seems fine. Also what is "frequently"? Do you always leave a browser window open with grafana? Just curious

What is the validation error above that? Are you sure unraid is not using port 80?

There hasn't really been a significant change to the image. Our images do get refreshed for package and os updates weekly, that's why you see the update notification. The changelog on github or docker hub tells you the changes to the image other than package updates. In your case, make sure that the ip on duckdns matches your home ip. And also make sure that nothing changed with regards to the port mapping on unraid and port forwarding on your router. You can remove the only subdomains or set it to true but keep in mind that when you do so, it will try to validate the cert again and if there is a port related issue, it will fail. So you should perhaps wait until you figure out the connection issue before changing it. Another issue can be that your client ip may be blocked by fail2ban if you had isuues with authentication (not sure if you use htpasswd). Try connecting from a different ip, on a mobile phone through the cell connection, etc.

Wagging the finger was not the intention, apologies if it came across that way. Ironically, most of our support requests are from users who don't read the docs or the logs but in your case, you just read too much 😉 I have a love hate relationship with certbot because although they act like they make everything easy for the users, I feel that their efforts are misguided. Like that message for instance, they do go out of their way to spam their "just do certbot renew" every chance they get but in reality nobody wants to have to run a manual command every two months on each production server. Certbot should instead focus on their automation and non-interactive operations so we don't have to try so hard to hack it. Anyway, that's my rant for the day. Perhaps that's why I was more touchy than usual. It's a fragile system due to the hacks.

Did your ip change? Also not sure why you have only subdomains set to true. It prevents you from using yoursubdomain.duckdns.org with the cert but with no advantage

That is a certbot message, directed to our image, not you. So it is telling our image, not you, to run it "again". If you didn't manually use certbot to get the cert, don't manually use it to renew. Also a rule of thumb, don't exec into the container to run things unless you're specifically told to by the lsio team

I have a feeling you poked around a bit too much inside the image. You're really not supposed to be going in and running "certbot renew" manually. We certainly don't support that. Next time, just check the logs in the log folder. Certbot already attempts to renew every night "properly". If that fails, logs will tell you why. For starters, you need to stop nginx before you can renew the certs via http, which the image does during the auto renews.

Glad it worked

Make sure the other container is named onlyofficedocumentserver with all lowercase and if it's listening on port 80, use http, not https in the proxy pass directive

It means it's stopping the services to restart the container. Nothing wrong. I don't understand what you mean about nextcloud and its ports. If you follow the directions in the readme, you shouldn't need to worry about ports. Post exactly what you did to get it to work, post copies of any file you modified. Otherwise we're shooting in the dark.

Renewals or validation don't get affected by nginx settings as letsencrypt/certbot puts up its own webserver during validation. Something changed in your system since the original validation that letsencrypt server is no longer able to access the container on port 80