aptalca

That command creates the credentials file. Then edit your site config files to enable it for whatever location you want

I don't even know what workspace files are. My workflow is, open terminal, go to workspace folder, git clone whatever, then from the top menu, open folder, select the cloned folder. Anything under the config folder is accessible by vscode. Also /config is the home of the user running vscode so things that vscode creates will likely be relative to that folder

Ah, I always turn off upnp on the router. Don't want some rogue apps opening ports to the outside without my knowledge

Post a full log and a screenshot of your container settings

None of the team members have a paid openvpn license so we can't really test how it works. I'll try to look into it, but I'm shooting in the dark here

Could be DNS issue (check IP), could be port forwarding (router setting looks correct as long as you moved unraid to a different port) or maybe your ISP just started blocking ports 80 and 443. See here to further troubleshoot (article not published yet but here's a preview): https://blog.linuxserver.io/p/3959a1d3-d70d-4d1d-a4ef-4dcdc0bcfd94/

After thinking about it, here's a PR with sudo access via an optional SUDO_PASSWORD variable: https://github.com/linuxserver/docker-code-server/pull/3

I use both (paid versions too). Soon after I started trying emby out, I completely switched over to it for myself. The main reason was that Plex apps kept transcoding all the time (every time I turn on srt subtitles, if there is multi channel audio, Plex transcodes). Emby apps direct play or direct stream on the same hardware with subtitles. I still have family and friends streaming off of plex. I figured it would be too hard to switch some of them over as they are not very technical. So I still run both, but emby for me, Plex for the legacy folk

Don't get your hopes up too much. He's been saying that for years

Use port 80 and tcp to connect

Root access in gui terminal is not very secure, the official container running as root is also not secure. If you want to add packages to this container and you want them to be persistent, use the custom scripts feature in our baseimages. Keep in mind that we cease to provide further support once you enable that so you will be on your own. Create a folder under /config called "custom-cont-init.d" and inside it place a file with "apt-get update && apt-get install -y blah" That script will be run on every container start and will survive container recreation Dev info here: https://github.com/linuxserver/docker-baseimage-ubuntu/blob/bionic/root/etc/cont-init.d/99-custom-scripts#L14-L31

I honestly have no idea what could cause the container to stop working. It literally just fires off a curl command every five minutes, driven by cron. Can you specify whether the curl is still firing?

https://lmgtfy.com/?q=How+to+use+docker+tags

Those logs are from March and they are several days apart. I'm guessing you shut down the container at night, which is when it's supposed to renew the certs

You can pull an earlier tag from docker hub but badge sure the version variable is set to docker so it doesn't update on start

Don't change the port in the proxy confs

Yup, edit the heimdall subdomain conf and change the server name directive to www.* or server.*

It's all working from here. Check your sonarr if you don't believe me 😁 you really should password protect those services

You keep insinuating that a lot of people are having renewal issues, therefore there must be something wrong with the image. However, 1) Users aren't even checking whether their certs are really expiring, which can be easily done in a browser by clicking on the lock icon, but instead rely on an e-mail that is non-specific and may not even be about the cert that is currently used (you included) 2) Nobody's checking their logs to see what the issues may be that cause a non-renewal (also you included) The logs are rotated weekly and 52 log files are kept. That means you have up to a year's worth of renewal attempt logs. Feel free to go back and find the ones that failed and if you really do identify a bug with the image, we'll fix it.

Read the last few posts

If it works from outside the lan, your issue is hairpin nat. Google how to enable it for your new router

Are you sure your certs were expired? What made you think they were? And what error are you referring to? You might be confusing two separate issues

Check the log folder, under letsencrypt and it will tell you exactly why the renewal failed. Then you can figure out what you may or may not have done

It's usually because the user makes changes to either port 80 mapping or their dns settings so validation fails

Check line 4 of the default site config