aptalca

Post your container settings

That much is clear. I think you're really confused. Dyndns is irrelevant. We're not talking about name resolution of the domain url. We're talking about name resolution of container names used in the nginx proxy_pass directive. Ports 80 or 443 also have no relevance. They are the listening ports of the nginx/letsencrypt container. There is no such thing as "already used in the network". Ports are device specific, not network. No one said anything about ports being resolved. We are trying to make a distinction between container ports and host ports, which docker maps via -p (--publish) and can be different.

Name resolving has everything to do with the docker network used in this case. The dns resolver is defined as "127.0.0.11" in the user's config as posted above (also as such in the preset proxy confs we provide), which is docker's resolver. If both containers are in a "user defined bridge network", that resolver will resolve container names and aliases to container IPs used in that "user defined bridge network". There is no such resolution in the default docker bridge network. Also fyi, you can simply not set any network in the container creation arguments and docker by default will use the default bridge. And when a container connects to another container via the docker bridge network IP, it should use the container port, not the host port mapped as saarg wrote. Either you are confused, or you are arguing semantics for the sake of arguing. In any case, you are not being helpful.

No issues at all with xfs formatted cache drive here (Samsung one, too)

As you can see at the bottom of the post you quoted, his issue was fixed when he deleted his appdata. I don't know what to tell you other than to say it is your appdata that's the problem. The file in question resides in the config folder and the path referenced in the log is merely a symlink that points to the file in your appdata folder.

If it's macvlan, it blocks connections between macvlan and host. Try to ping it from inside the letsencrypt container

Don't copy paste a conf from another source. Use an existing preset proxy conf and modify accordingly. The conf you posted above is missing all the ssl bits, and it tries to reverse proxy localhost, which won't work in a container. Also see the examples in the default site config for very basic confs

Check docker hub tags and you'll see the updates. Github repo also lists all the releases that will coincide with docker hub updates. We no longer do Friday updates. Instead, there are new builds pushed when either 1) there is a commit to the active branch 2) there is a new upstream release 3) the is an os package update

See two posts above yours

Could be a few things. If you're using btrfs cache pool, there is an existing unraid issue that causes it, not related to sab. You can also limit the number of processor cores sab uses so it doesn't use all during extraction

Add it to extra domains?

Realip module is already in there

Oh wait, I might be mistaken. It does have library selection for Plex but it might not have it for emby. You should ask on their github

Use the host ip and port for it

No idea what your issues are, but as a rule of thumb, don't update this container while you're away on vacation. Also, a backup plan is important (I have 3 vpn implementations running on 3 devices). With that said, my instance is rock solid. Runs for weeks and no issues.

I don't think it was confirmed as a btrfs bug. It could be specific to unraid's implementation of btrfs. Not sure. We need the unraid team to look into it and chime in.

That's a Plex issue as it's related to libs they package with their binary. You should ask on their forum.

Fyi, your sonarr is accessible from the internet. Everything works properly. Your issue is hairpin nat or nat loopback. PS. Don't forget to enable http auth for sonarr or you might notice strange shows added to your library

Literally two posts above your first one: "Check the Plex server log in the config folder to see why Plex is crashing. If it's corrupt database, restore from backup. Plex takes database backups automatically every 3 days"

Why did you change the port? Don't do things the conf doesn't tell you to do

See my response to someone else above

Yeah the one scenario was, if a gpu is being actively used for transcoding when you start a VM with that gpu passed through, unraid gets locked up. If you start the VM when there is no active transcode, the gpu will no longer be available to the container so it will fall back to something else, no crashes. Whether it falls back to igpu or software, I don't know the answer. I never tried it. But it's really a plex question.

Check the Plex server log in the config folder to see why Plex keeps crashing for you

In ombi gui, open the emby server settings, there you can manually select which libraries you want ombi to scan

Check the Plex server log in the config folder to see why Plex is crashing. If it's corrupt database, restore from backup. Plex takes database backups automatically every 3 days