aptalca

Leave the one you want to access remotely in host networking and read the top of the proxy conf to see what exactly you need to change for host mode

You shouldn't have changed the port if it's connecting via container name. Read the docs for letsencrypt, it's all explained there and the top of each config tells you what to change. Don't change anything else unless you know exactly what you're doing (changing server name to cloud is fine)

Symlinks work as long as nginx inside the container can follow it and access the target. I'm assuming the symlink is pointing to a share hosting your movies on unraid, but the letsencrypt container does not have access to that share (location not mapped) so nginx read the link but cannot find the target. Here's what you can do: 1) map your movies location into your letsencrypt container as "/movies" and create symlinks in your www folder that point to "/movies/filename"

Those errors are harmless. The openvpn package is trying to start itself via systemd after install and also after init and it's failing because there is no systemd service inside the container. We manage it with s6, so you can ignore those errors. Client/admin web pages are managed through the admin gui. By default both are served over port 943, where the naked url gets you the client ui and the /admin subfolder gets you the admin interface. They are all openvpn-as standard behavior.

Your previous logs showed a lot of weird errors. Post a new log with your new config

Did you forward the udp port on your router as udp?

No nano inside openvpn container. He needs to edit it on unraid directly via "nano /mnt/user/appdata/openvpn-as/etc/as.conf"

If you have existing data, you're fine. Only on a brand new install with the latest version, data wasn't being stored properly. It's fixed now. I basically focused so much on upgrades that I didn't notice a bug that affects new installs

It seems there is a bug for new installs. Looking into it. EDIT: Yup, missed something for new installs. PR submitted, should be merged soon. After update, it will reset one more time but then it should be good.

Run it in bridge mode as shown on GitHub or docker hub page

Glad you got it sorted. I'd highly recommend backup options if the server is remote. I personally have 3 options: 1) openvpn on router 2) openvpn on unraid 3) wireguard on an rpi

Alright ladies and gents, the rewrite for openvpn has been pushed to master and there is a new build on docker hub. You should be able to return to linuxserver/openvpn-as or update to 2.7.3 safely

Once we merge to master, I'll notify here so you can switch back to the "linuxserver/openvpn-as" image

Is that in host networking? If not, try host networking. If so, are you on the same network subnet? If not, you need to be. You can ssh tunnel to your host. See the "on a different network" heading at the bottom of this page: https://support.plex.tv/articles/200288586-installation/

You're confusing different tags. There are docker image tags, which are found on the docker hub page under tags. If you don't select a tag, "latest" is selected by default, which is what you're seeing for our image there, simply because you put in "linuxserver/plex" as your image in the container settings. If you change that to "linuxserver/plex:1.15.1.791-8bec0f76c-ls11", then you'll see "1.15.1.791-8bec0f76c-ls11" as the tag in that screenshot for our image. The other tag you're confused about is plex's version tag. Our image (different than the official plex image) supports updating to a custom version inside the container by setting an environment variable to a specific plex version. Other options are "latest", "public" and "docker". docker does no updates and you get the version that comes with that image. Public updates to the latest public release on container start and latest updates to the latest beta/plexpass on container start (as long as you're logged in with a plexpass account). Or you can set the version variable to a long plex version and it will update to that. The long plex version for the current stable is "1.15.2.793-782228f99". That's what you would need to enter in as the "VERSION" variable in container settings. Now as for the other variable for plex downloads, that's the url our image uses to download plex releases. With 1.15, that url changed. So if you enter in a 1.14 version, our image won't be able to download it from the new endpoint, so you need to override that url by passing in the url for old downloads, which is what I listed before. So if you want to update to a 1.15 version, don't specify that url. If you want to update to a 1.14 or earlier, you need to specify that url. I hope that's clear. If you simply want to use version 1.15.1.791-8bec0f76c, the easiest way would be to set the "VERSION" variable to "docker" so it doesn't do any updates during container start, and use the image "linuxserver/plex:1.15.1.791-8bec0f76c-ls11" so you'll use the image that comes with that version with no in container updates

What's the source media you're transcoding by the way? Is it h265? 4K? If so, even on a super fast cpu, it is very difficult to sw decode so your experience is perfectly normal

Thanks so much for the confirmation. We are now using the openvpn recommended backup and restore steps whenever the container is recreated. Hopefully this should alleviate any issues arising from version updates. Downside is, openvpn is installed on container start of a newly created container, which increases the overall space used (between the image and the container) by about 44MB due to duplication, but I think it's a worthwhile compromise.

I rewrote the openvpn-as setup steps to prevent breaking updates. Can I get a few volunteers to test going from 2.6.1 to 2.7.3? If you're interested, please first back up your app data, then change the image in your container settings to "lsiodev/openvpn-as" from "linuxserver/openvpn-as:2.6.1.ls11" and let us know here? It worked for my install but I may have had changed other things manually while tinkering. Thanks

First of all, the additional variable is only needed if you're trying to go back to 1.14, not 1.15. Second, you're missing some digits in the version you are entering. It needs to be longer than that. Third, the "latest" you're seeing in that screenshot is for the docker image, not the version of Plex inside the image

You need to provide more info. Define "not working". What do you observe? And which steps did you do?

Also check the proxy.conf, which used to have a limiter a while back

I don't see how any of it relates to letsencrypt. The log snippet you posted shows one container trying to connect to the other directly via host ip. I don't see any proxying involved

Along with the version for 1.14blah, pass an environment variable where PLEX_DOWNLOAD="https://downloads.plex.tv/plex-media-server"

In other words you need to change the ports unraid gui uses (only the https one if you do dns validation)

Don't expect us to watch videos to figure out what you may or may not have done. Post what you did, your config, full logs, etc. and then we can try and figure what went wrong