aptalca

I can now confirm that the transcoding also works with no issues.

I'm using the lsio container and both live tv and dvr worked out of the box. I am now testing the transcoder option during recording. Not sure if you had that on or off

Check the end of the default config file. There is a sample

I am also having an issue with the plugin stalling. I am in the post-read step of a preclear of an 8TB disk, 22% in, it seems to have stalled. Percentage hasn't changed in hours, time elapsed is also stuck. htop shows the preclear script as running (pegging the cpu core at 100% constantly) and there are two other related active processes: "cmp - /dev/zero" and "dd if=/dev/sdb bs=2097152 skip=1 iflag=direct". Is the preclear still ongoing? Is it only the reporting aspect that is borked? Should I wait another 10 hours for it to finish? The preclear log only shows that the post-read has started, nothing after that. I checked the folder /temp/.preclear/sdb/ and the cmp_out, dd_output and the display_output haven't been modified in hours. Thanks

My hdhr connect is getting delivered today. I'll let you know within the next few days

Base url to root reverse proxy often causes issues. Try the subdomain method. Or see if there is a way to have unifi use a base url as well

I assume you mean separate IP through macvlan. In that case, make sure that your router is forwarding port 443 to the letsencrypt container's IP rather than unraid's

Edit container settings in advanced view, you'll see the field for the gui url

Why are you adding users through command line? You are creating more PAM users as that cli command in the docker description was posted to modify the admin user, which is a PAM account. Create new users (and manage them) through the gui and don't mess with command line

To my knowledge, that is correct

Php.ini is inside the image and not directly accessible. I believe the mysqli package is already installed so it should be good to go. By the way an update was pushed today with bzip2

You have to manually add "client-cert-not-required" to the server config to disable certs. You should be able to access the gui only when you're on your home lan. No remote access (from the wan or internet) to the gui. However, it's ok to be able to access the gui when you're vpn'ed in, because vpn technically puts you on the home lan (you can set whether vpn clients should have access to the subnet of your unraid server or not). Basically, don't forward a port on your router for the openvpn gui port (default 943 I believe) and you'll be fine. Only forward the tcp and udp ports for vpn access.

PAM means the users on the host OS are used. Local means openvpn keeps it own local database for the user list. Openvpn's list is stored in the config folder and survives container recreation. PAM/OS stored users are in the image and get wiped when container is deleted.

As far as I know, you can't vpn in without the certs (unless specifically set in server settings). No one can brute force into your vpn (as long as your certs are high enough bits and they do not have a quantum computer). Even if they know the username and the password, they still cannot vpn in without the certs. However, the gui allows for access with just the username and password. No certs needed, thus prone to brute force. That's why you don't expose it to the world.

I don't believe you can vpn in using the admin user and password. That is just for the gui access. Vpn access should only be allowed with a client certificate. And that is why your gui should not be publicly available. Gui is only protected by a simple password which can potentially be brute forced. Client cert for vpn is much much more secure. But if you allow public access to the gui, a hacker no longer needs to hack in through vpn. They can just brute force the gui password and create a vpn user for themselves. Don't introduce a weak attack surface by publishing the gui. If the gui is not publicly available, keeping the admin password default should not be that big of a deal since it can only be accessed on the lan. If someone's already on your lan, they no longer need to hack into your vpn. If someone who is not currently on your lan needs access to vpn, you should create their cert and send it to them. They don't need to access the gui.

Probably delete the config folder and start over

We can add the package in the next update

The gui probably shouldn't be public facing

I have it set to use local and auto login and it works fine. Users are preserved through updates

It looks like that will fix my problem with user accounts surviving docker updates but what about the admin account? Will this also preserve admin password or is there a better way? Edit: Switching authentication to local doesn't seem to work. Every time I tried to login it would get denied. local auth failed: no stored password digest found in authcred attributes: auth/authlocal:35,web/http:1609,web/http:750,web/server:126,web/server:133,xml/authrpc:110,xml/authrpc:164,internet/defer:102,xml/authsess:50,sagent/saccess:86,xml/authrpc:244,xml/authsess:50,xml/authsess:103,auth/authdelegate:308,util/delegate:26,auth/authdelegate:237,util/defer:224,util/defer:246,internet/defer:190,internet/defer:181,internet/defer:323,util/defer:246,internet/defer:190,internet/defer:181,internet/defer:323,util/defer:245,internet/defer:102,auth/authdelegate:61,auth/authdelegate:240,util/delegate:26,auth/authlocal:35,util/error:61,util/error:44 After switching, did you recreate the user accounts and the ovpn config files?

In the guide you linked to, the part where it tells you to do things inside the container, those things won't survive an update or recreation of the container. However they will survive restarts of the container.

https://slickdeals.net/f/10208984-plex-pass-perks-30-off-silicondust-hdhomerun-connect-extend-or-prime-from-69-99 Plexpass perk gives 30% off on hdhomerun. I snagged a connect for 69$

If you set the version parameter to latest when you create the container, it will attempt to upgrade to the latest during each start of the container. If you are a plexpass user and logged into your plexpass account in plex, the container will update to the latest plexpass version. If not, it will update to the latest public version. The Friday builds come with the latest public version inside

Docker does not pass devices through like kvm does. It only allows the containers to share resources with the host. To use a usb device in docker, you would need a driver for it installed on the host os, which in this case is unraid. If unraid does not recognize the usb device and load drivers, it won't work in docker.

OK, I see that although the issue was fixed back in March per https://github.com/fail2ban/fail2ban/issues/1741 there hasn't been a new release with the fix in it yet. Temporary solution to fix fail2ban here: https://gist.github.com/aptalca/ac9c3f931de460c9a2c12176e26df7d8 However, this issue should not break your reverse proxy. It only breaks fail2ban. You probably have a different issue regarding the subdomains.