Dor

Change the TubeArchivisit-RedisJSON container to use redis/redis-stack-server:6.2.6-v9 Annoyingly this is not the first time an update to redis broke TubeArchivist's setup.

Could we get a "latest-v3" tag? I'd still like to receive updates, but I do not wish to upgrade when v4 releases, I rather wait some times for issues to be ironed out, there's also some features being changed/replaced (release profiles replaced by custom formats) and I fear the migration process would hinder Sonarr's functionality the way I've currently got it set up.

Min Free Space does work around this issue, but smarter logic shouldn't be dismissed as unnecessary, and if this has a performance cost, make it a toggle in share settings, I expect it to have a very minimal impact on media shares (less files, but bigger ones), and when it would normally run into the issue described in the original post, it would be significantly faster.

There exists a very odd limitation with the WebUI where some services such as SMB can only be configured while the array is stopped, this makes little sense when said services can be stopped and restarted or commanded to reload configuration, which is what plugins such as Unassigned Devices and Recycle Bin are doing with the SMB service while the array is running.

Close all additional webui tabs to the server and see if it continues

I seem to have found an odd bug. When tunnels are set to be inactive, (re)entering the VPN Manager and changing any information (such as the tunnel or peer's name) and applying, activates the tunnel. Deactivating it and doing so again without leaving the page won't activate the tunnel again, but revisiting the page and changing information once again will. This has accidentally caused me to activate two commercial VPN tunnels as I was naming the "peers" and the server became inaccessible until a reboot (I was unable to use the local terminal since the GPU was previously attached to a VM and I can't seem to get the iGPU to work with unRaid)

I've created a fork of the PIA scripts to simplify the install process on unRaid, it's still not as simple as importing a configuration, but the scripts now generate a file following the "wg#.conf" convention which gets picked up by the Dynamix WireGuard plugin, it also fills the public key and VPN type fields correctly (which exist in "wg#.cfg"). I also added a user script to be used with the User Scripts plugin to make configuration changes (like re-selecting a server) easy to make, all you really need to fill to be up and running are the PIA account credentials. You can find my fork at https://github.com/DorCoMaNdO/pia-wireguard-unraid, the user script is part of the repo at unraid_userscript.sh

I've recently set up an OpenVPN client container to route a few containers through as I don't want the VPN to affect all of the server's traffic, however I'm unsatisfied with the setup and loss of features such as easy access to routed containers' WebUIs and I think this could be done better. Proposed changes: Add "Container" as a "Network Type" option which would then display another dropdown with available containers. This will address the need to enable the "Advanced" view to manually write the command to do so, unRaid could also keep track of the target/VPN container's name and update all dependent templates accordingly. Apply ports defined in a routed container's template on the target/VPN container. This will address the need to modify both containers during setup, the issue of a container setup breaking when the network type set in the UI is still "Bridge" with ports defined, and the need to modify the target/VPN container to remove the ports after removing the routed container, and re-enable easy access to WebUI. Allow multiple network setups such as using the "Bridge" network type when the target/VPN container is shut down when VPN routing is not desired for any reason temporarily, without needing to modify routed containers to "Bridge", redefining ports only to undo so when VPN routing is desired again. I'm still new to docker (and Linux in general) but from what I understand this might require two installations of the docker containers, but this could be handled by unRaid by starting/stopping the appropriate install based on whether the target/VPN container is running and restarting the routed containers when the state changes (but not when the target/VPN container is restarting). Enable the WebUI menu option on containers under more conditions (or a toggle in the template to always enable it). This spans a bit beyond the initial scope of this request but it will allow the easy access of routed containers' WebUIs among other use cases, the option is currently dependent on the network type (at least it wouldn't work on any container network) and at least one port being defined in the template (even if blank or if the port is hardcoded), this prevents the use of hardcoded/remote addresses, dynamic DNS and hardcoded ports.