brentdog

I see this error on boot as well but it does not stop or slow down the boot process for me. Just annoying. Why is the solution to remove the mover tuning plugin? I'm using that plugin so I really do not want to remove it. Is that plugin deprecated? I cannot find any documentation that its deprecated.

Thanks @JonathanM. Yeah I understood that one of my 18TB would have to be the new parity drive which is why I pointed out that current parity was 12TB and that I wanted to avoid a parity swap, but I should have been more explicit.😀 I'll report back when complete.

I am replacing 2 6TB drives with 2 new 18TB drives. I currently have a single 12TB parity drive. What is the best way to do this with minimal array downtime? I would really like to avoid a parity swap which would probably take a day and a half at the rate the preclear on the 18TB drives is going. I'm fine with being without redundancy temporarily (while parity is rebuilt) as everything important is backed up. I also can temporarily have all drives connected at the same time although the end state will have the 2 6TB drives removed. Running unRAID 6.10.0-rc2

I had some time to try to debug this myself today. Turns out you need one of the yes/no criteria (age, min size, etc.) set or the base mover is used. This is different than previous versions of the plugin where you could just set the percent threshold and it would move everything when you hit that threshold. I set the age limit to something reasonable and it is working as expected now. Just curious if this change was intentional?

Just upgraded to 6.9 and subsequently upgraded the mover tuning plugin to latest. Now it seems as if the plugin isn't used at all when the mover is invoked. Everything gets moved when the mover is invoked even though I have the used space threshold set to 70%. I see that there are still some debugging echo statements in age_mover script and none of these show up in the syslog (I have mover logging enabled). I uninstalled and reinstalled the plugin and still just seems to use the base mover.

OK I feel stupid. I had an OpenVPN server in front of nginx using the port-share option (probably should have mentioned that). I have had this setup for years when nginx was on an Arch vm and always got the real ip in the nginx logs. I switched back to my Arch vm just for grins and it was only seeing the Unraid server IP in the logs as well. So something changed, I have no idea what. I moved OpenVPN back to its standard port and have my router forwarding straight into swag and I now see the real client ip addresses in the access log. I even see the real ip addresses in the Bitwarden log now to boot.

Was this ever resolved? I am having the same issue and the same bad luck with google. The only thing I am trying to proxy right now is self-hosted Bitwarden container. Then only conf I changed was the Bitwarden proxy one to rename it to bitwardenrs. I followed Spaceinvaders videos for the most part and am using a user defined bridge network. Everything works as far as clients accessing Bitwarden through the domain. But all access through nginx gets reported as coming from my Unraid server's IP address and everything in the Bitwarden log is either from the Unraid server's IP address or the address of the Swag docker. Is this just how it works inside docker? I was previously using nginx directly (not in a container) on an Arch vm and always got the real internet ip addresses in the logs. But I was really hoping to ditch that vm and go with an all container solution. I'm not sure what other information to provide. Any help would be greatly appreciated?

I love how unRAID allowed me to make use of my menagerie of different sized drives EASILY. I would love to see an Android app to manage unRAID or at least a mobile optimized version of the web interface.

Any ETA on 5.12.22 in the latest tag? It's been the stable release for over 2 weeks. I've got a USW-Flex-Mini that I can't adopt until I can get on 5.12.x. Thanks!

Happy Birthday Unraid!