Nirvash

I just gave it another go... can't believe how much this has improved in barely a month. Now it's perfect! Waaaaay better than any other fan control software currently available for Unraid. Not only i could finally uninstall the Dynamix Fan Control plugin, I can also stop using the CoolerControl container, which didn't play nicely with spun down drives. A hooray to you! Two new suggestions: 1.- I saw the latest CoolerControl updated added support for liquidctl, showing the sensors of AIO watercoolers. Would be nice to have that as a CPU Sensor option. For instance, I cool my server just with the AIO pump without the rad fans spinning. Only when the CPU reaches a certain temperature threshold I spin the fans. If I could use the water temperature I'd use that and spin the fans only when the water gets too warm. 2.- All that empty space could be used to show the current average temp of the selected disks or the CPU (or water) temp, and the speed in RPM and % of the PWM controller, which I believe it's data you are already have if you click on the Chart button. You could make it so it only shows if there's enough empty horizontal space.

I don't understand, looks almost identical to "Dynamix Auto Fan Control". It even has that weird weird weird way to set up the temperatures and speeds. Wouldn't it make more sense to set a 1-100 percentage instead of having to mess with 0-255 PWM? Also a temp curve to say that at 40c you want 100% 30c 50% etc. It would make the plugin a lot more intuitive to use.

Files with dollar signs in their filename cause the Mover to fail, and disabling a Validation step doesn't seem like the ideal solution. Could something be done about this? Unraid: Unraid Status Mover Tuning Notification Error: Invalid filename path: '3D Models/$ Jobs/MeshBody1.stl'. Please either change the filename to valid or disable the 'Validate input filenames' option. warning http://Unraid.nas:180/Settings/Scheduler Error: Invalid filename path: '3D Models/$ Jobs/MeshBody1.stl'. Please either change the filename to valid or disable the 'Validate input filenames' option.

I'd understand them not working if they weren't in the same network, but they are... I've had issues with docker networks before so I'll blame it on that.

Is there any way to enable a log that it's a bit more descriptive? I'm setting Karakeep for my family, since Pocket is closing down, and I'm having a hell of a time getting browserless to work. 2025-05-24T10:48:34.992Z info: [Crawler] Connecting to existing browser websocket address: ws://browserless:11312?token=ORckYQ3AW06NpAw 2025-05-24T10:48:34.994Z error: [Crawler][2016] Crawling job failed: [object Object] I set browserless-v2 and changed the name (removed -v2) and the port to an arbitrary one since 3000 was already used and token matches, so I don't know why it's not crawling correctly. Edit: Changing it to IP:PORT instead of the name of the container made it start working. Why wouldn't the container name work? We'll never know... I suspect my docker is cursed. 🥲

@husqnz put these two lines at the end of your go file and reboot. sed -z 's|nchan_publisher;|nchan_publisher;\n\t error_log /var/log/nginx/nchan_error.log;|' -i /etc/rc.d/rc.nginx /usr/sbin/nginx -s reload Then, through SSH, tail /var/log/nginx/nchan_error.log and see if it's complaining about anything in particular.

@husqnz Did you perchance followed advice someone shared some years ago and modified the go file to alter the nchan memory?

Honestly I'd rather find a fix that will work for everyone. Edit: I think I figured it out: Checked /var/log/nginx/error.log and had these errors: 2025/05/06 15:12:09 [emerg] 13282#13282: "nchan_shared_memory_size" directive is duplicate in /etc/nginx/conf.d/servers.conf:4 2025/05/06 19:18:44 [emerg] 960158#960158: "nchan_shared_memory_size" directive is duplicate in /etc/nginx/conf.d/servers.conf:4 Which points me to some instructions I found in the forums some time ago that suggested editing /etc/nginx/nginx.conf to add more nchan_shared memory_size among other things. I needed to go back to /boot/config/go and remove the line that alters nchan_shared_memory_size and reboot again. That fixed the issue. # Fix NGINX limits to stop stupid log messages sed -i "s;zone=authlimit:1m rate=30r/m;zone=authlimit:1m rate=60r/m;g" /etc/nginx/nginx.conf sed -i "s;zone=authlimit burst=20;zone=authlimit burst=60;g" /etc/nginx/conf.d/locations.conf # Fix nchan memory leak REMOVE THIS LINE ->>>> sed -z 's|nchan publishers\n\t#|nchan publishers\n\t#\n\tnchan_shared_memory_size 2M;|' -i /etc/rc.d/rc.nginx sed -z 's|nchan_publisher;|nchan_publisher;\n\t error_log /var/log/nginx/nchan_error.log;|' -i /etc/rc.d/rc.nginx /usr/sbin/nginx -s reload I suggest the devs to enable nginx error logs into the diagnostics. AFAIK you don't have this info when people share their diags and you are blind against these issues. I'm fortunate I had that enabled.

Hi! I'm coming from this thread -> You can find the diags BEFORE deleting the certs there. The three pem files I deleted were: certificate_bundle.pem HomeServer_unraid_bundle.pem Unraid_unraid_bundle.pem Now, after deleting the certs and rebooting, my Nginx is still failing to start. Diagnostics after deleting the certs attached in this post. The only cert i have now is `Unraid_unraid_bundle.pem`. May 6 15:12:09 Unraid emhttpd: shcmd (46): /etc/rc.d/rc.nginx start May 6 15:12:09 Unraid rc.nginx: Starting Nginx server daemon... May 6 15:12:09 Unraid root: Regenerating private key and certificate... May 6 15:12:10 Unraid root: Starting the Unraid API May 6 15:12:14 Unraid root: [PM2][WARN] Applications unraid-api not running, starting... May 6 15:12:14 Unraid root: [PM2][WARN] App unraid-api has option 'wait_ready' set, waiting for app to be ready... May 6 15:12:14 Unraid root: [PM2] App [unraid-api] launched (1 instances) May 6 15:12:14 Unraid root: ┌────┬───────────────┬─────────────┬─────────┬─────────┬──────────┬────────┬──────┬───────────┬──────────┬──────────┬──────────┬──────────┐ May 6 15:12:14 Unraid root: │ id │ name │ namespace │ version │ mode │ pid │ uptime │ ↺ │ status │ cpu │ mem │ user │ watching │ May 6 15:12:14 Unraid root: ├────┼───────────────┼─────────────┼─────────┼─────────┼──────────┼────────┼──────┼───────────┼──────────┼──────────┼──────────┼──────────┤ May 6 15:12:14 Unraid root: │ 0 │ unraid-api │ default │ 4.8.0+… │ fork │ 13352 │ 2s │ 0 │ online │ 0% │ 205.2mb │ root │ disabled │ May 6 15:12:14 Unraid root: └────┴───────────────┴─────────────┴─────────┴─────────┴──────────┴────────┴──────┴───────────┴──────────┴──────────┴──────────┴──────────┘ May 6 15:12:14 Unraid root: Starting nchan processes... May 6 15:12:14 Unraid rc.nginx: Nginx server daemon... Failed.

Thanks for posting the path to where the certs are located. That's what i needed lol I moved these files to another folder and I'm rebooting now. Edit: Unfortunately, deleting the certs did not fix the issue. I'll open a new thread for my issue now.

...How?

I'm having the same issue. I updated and the WebUI is not responding. Dockers are up and running and shares are accesible. I'm unsure what steps do I need to take to fix this problem.

I think this plugin is partly the reason why my flash drive is erroring and is starting to fail in less than a year, all because all the hashes and logs and whatnot are being stored on it. Any reason not to have the option to change the location of all the files this plugin generates to the SSD cache?

I see! Nice to know that there improvements towards a more stable UI. I'll be updating as soon as it's ready for production

Hi! My server was doing it scheduled moving and backup operations and might be because it got overloaded, but mostly everything crashed: Unraid's GUI stopped responding and had to start (not restart!) ngnix through an SSH terminal. Docker in general crashed altogether. "Docker" page shows "Docker Service failed to start." Can't access shares through SMB on Windows machines, but shares are visible in the "Shares" page. The task i was doing were a Restic backup using Backrest. Moving from cache to array. And probably the worst offender: Integrity plugin was hashing the newly moved files. Maybe I'm asking too much at once from my poor 4670K? Attached Diagnostics. I'd like to know what happened to prevent it from happening again. Thank you very much. unraid-diagnostics-20250425-0115.zip