aptalca

You're completely missing the point. We're glad that you integrated it. We're unhappy that our efforts and calls for help were largely ignored over the years. You never even reached out to the folks who maintained it for years. Then you have the gall to say you did it to discourage "unofficial" builds as if it was a bad thing that they provided it for years. Yeah, I'm out, too. Not a fan of a one way street.

?? I don't see any acknowledgement

Wow. Talk about a slap in the face. @CHBMB and @bass_rock busted their behinds for years to provide a working solution to unraid users with minimal input and no acknowledgement from limetech. They had to do so much trial and error trying to figure out what may or may not have changed in unraid (out of tree drivers and whatnot) with each new version. All of a sudden limetech finally decides to roll out a solution and they want to 'discourage "unofficial" builds of the bz* files'. Nice one.

Hey guys, While running a parity check, I was faced with 128 read errors on one of the disks, and 22 sync errors. The parity check is still ongoing and it seems the errors happened all at once and then stopped. I checked the smart report for the disk and nothing looks (to me) out of the ordinary. My parity check was not correcting, and still has a few more hours to go. Any ideas on how I should proceed? The integrity of my data is of utmost importance. I already have a hot spare, ready to go, but want to make sure that my data is intact before I do something like that. Diagnostics attached Thanks tower-diagnostics-20201113-1557.zip

You can put multiple names in a single server name directive, don't use multiple directives

To clarify, you CAN edit the default site conf to modify or add server blocks. Alternatively you can add more site conf files like you did. Either works

Main conf is /config/nginx/nginx.conf, which includes (imports) /config/nginx/site-confs/default, which contains the main server block and it also includes (imports) all the proxy confs Check out the examples in the default site conf

If you're doing dns validation, you can get wildcard for b by setting extra domains to "b.com,*.b.com" Then to serve wordpress at b.com, set the server name for the wordpress server block to b.com

Then you'll have to create a custom script that does those steps for you during container start: https://blog.linuxserver.io/2019/09/14/customizing-our-containers/

How did you update it? The bionic repo has 2.17

Yes

That's a question for unraid and/or CA

Perhaps live server needs to bind 0.0.0.0 so it's accessible from outside the container as opposed to bonding 127.0.0.1 which would only be accessible from inside the container

That's correct. You need to enter your network subnet in the gui settings for it to nat

And it's udp (by default)

No

No, nginx would have to be compiled with it

passwd username won't work because it's not using pam See the readme instructions about disabling the "admin" user, reverse that to re-enable admin user, restart container, log in with "admin/password", make your changes to your main user, and then disable admin user again.

Create a cname in cloudflare with just an asterisk as the name "*", pointing to the A record for your domain and that's it. Then in swag docker settings, set the subdomains variable to "wildcard" without the quotes.

Use dnschecker.org to check

It's code server functionality and it's explained in their docs. Our image supports the domain name setup via env var and swag's built-in proxy conf allows it by default. You just need to add "*.code-server.yourdomain.com" to extra domains in swag so your cert covers the sub-subdomains of code server. (Or XXXX.code-server.yourdomain.com of your doing http validation and can't do wildcard)

There is only ever one cert generated with this image and it contains all the names as SANs

I use authelia and it works great. There is no webui for user management yet (I hear it's in the works), but you can set up the users in a number of ways including ldap (I use a simple yaml file). See here: https://blog.linuxserver.io/2020/08/26/setting-up-authelia/ For accessing the domain on lan, you need either a hairpin nat or nat loopback (if your router supports it), or you can set up a split dns (where you tell your local dns to resolve the domain to the unraid lan ip). The main caveat is that swag has to use port 443 on the host, which means you'll have to change unraid's https port to a different one first. Afterwards all requests for https://yourdomain.com will resolve to unraid and the client will connect to swag directly on lan (for http to https redirect, you'd need to change unraid's port 80 as well, so swag can use it, but I don't do that and instead only use the https endpoint so only port 443 goes to swag). Google the three terms I mentioned above and you'll find plenty of info for your router/setup.

I don't know, you tell me. Check all the confs in the /config/nginx folder

You probably had cloudflare cache/proxy turned on, which we recommend against. It's explained in the docs article linked in the first post