Rysz

Another thing to try apart from NUT would be the default "UPS Settings" (which use APCUPSD) if you haven't already tried that.

I'm sorry, the only thing I can think of is going through these settings again with another USB port or cable (keep the bus, device, busport commented out though to not fix NUT on a specific USB port). Otherwise unfortunately we seem to be out of luck.

Thanks, any luck with the blazer_usb driver on the 2.7.4. backend?

Ok let's try something else, remove the subdriver line again. Then set NUT Backend Switch to "legacy (2.7.4 stable)". Uninstall and reinstall NUT (or reboot server) and make sure the backend actually changed to 2.7.4. Then start NUT again with the same settings (without subdriver). Also try another USB port it that doesn't work.

Can you try adding this line to your UPS.CONF using the NUT configuration editor under NUT Settings? Then restart NUT. subdriver = "hunnox"

Not sure to be honest, this is definitely not normal behaviour for a UPS. It should be available because system boot takes long enough, did you try another USB port or cable?

It seems your UPS takes longer to get ready for a USB connection than it should. I'm not sure what is causing this, as a workaround you can put this in your /boot/config/go file: at now + 3 minutes <<< "/etc/rc.d/rc.nut restart 2>&1 | logger" Which will restart the NUT services 3 minutes after system boot and it should be ready by then. You can also try before on another USB port or with another USB cable, that could also help. 🙂

Please post the NUT Debug Package (can be found in NUT Settings) in the NUT Support Thread:

On most firewalls (like pfSense) you need to open the port 3493 from/to LAN devices.

The monitor password is using incompatible special characters, that's also why you're getting the error and red hand. Change it to something simpler on the master, best without special characters at all, and then use that on the slave as well and it should work. 🙂 Please report back if that solved your problem.

I haven't tried it but it is compiled into the plugin package and present on user's systems at: /usr/lib/mergerfs/preload.so So in theory it should be usable as explained in the README, if anyone tries it please let me know if it works... 🙂

Regarding UD, I'm not sure if you can hide drives from there - I don't know how that plugin selects the drives to display or not. Looks like there is no way at the moment: Regarding Globbing, you need to escape the globbing characters as follows: mergerfs -o cache.files=partial,dropcacheonclose=true,category.create=mfs /mnt/disks/OfflineBU\* /mnt/addons/BUPool See also here for more details: https://github.com/trapexit/mergerfs#globbing

I've compiled a package for you... 🙂 From current Git master with all debug symbols included and also --with-debuginfo. You can install it on your Unraid system as follows: Stop NUT in NUT Settings cd /var/log/packages removepkg nut-2.8.2* (make sure to uninstall only nut, not nut-plugin) Put the debug package somewhere on your system (e.g /root/) cd /root installpkg nut-2.8.2-x86_64-1debug.txz Start NUT in NUT Settings or directly start driver for debugging (as above) nut-2.8.2-x86_64-1debug.txz You can find the build scripts in the packages themselves under /usr/src/nut-2.8.2/nut.SlackBuild Please let me know what debugging information is shown for the segmentation fault, I'm curious too. Probably also worthwhile to raise the debug level on the driver with -DDDDDD

Motherboard um die 51W im Idle Xeon CPU ebenso um die 50W im Idle HDDs um die 40W wenn alle im Spindown LSI Controller um die 27W RAM um die 24W 2 NVMEs bei 6W im Idle Da kommen wir alleine mit den Komponenten schon auf ca. 200W im Idle - wenn gar nichts läuft. Dann hast du 27 Docker in Gebrauch, das treibt den Prozessor an und die NVMEs natürlich ebenso. Die eine oder andere HDD wird zwischenzeitlich auch mal anlaufen, v.a. wenn Plex o.ä. als Docker läuft. Der Verbrauch überrascht mich jetzt überhaupt nicht, das sind halt Workstation bzw. Serverkomponenten. Ein Xeon Prozessor hat jetzt nicht unbedingt Stromsparer als Zielpublikum, auch das Workstation MoBo nicht. Da wirst du nicht viel machen können, außer du wechselst auf Endkunden-Komponenten (sparsame CPU etc.)

Yes, if you remove the powertop package from /boot/extra or wherever you placed it, things will revert to default on reboot.

There's lots of USB disconnects in your logs and it seems something is hibernating your UPS periodically - causing the data staleness. I also see you have powertop installed, which is known to cause such issues. Would be best to remove anything powertop related, reboot the system and watch if the problems come back.

Just updated it, should be fixed with the new update. 🙂

No, the first message actually seems to come from the LLDP plugin which tries to send LLDP beacons from virtual interfaces (which doesn't work). That's actually useful information because that needs fixing (will push an update ASAP), so that it only does it from physical interfaces. The second message is normal after uninstallation and will only occur until the page is reloaded because after uninstallation the client side JS footer code is still there and looking for a no longer existing script until you reload the browser page at which point the code will be completely gone.

Sorry to have spawned such a discussion about this, glad that there's such diligent security mechanisms in place so thanks to everyone involved with that and for the hard work of all our contributing developers as well (including of this plugin). Glad to be a part of the Unraid community exactly for those reasons and many more. 🙂

Thanks for getting back to me so quick, makes absolute sense from your perspective and you're right about other plugins, of course, it probably boils down to moderation discretion and where it makes sense and doesn't (which it seems to do in your case). Please also don't get me wrong for pointing this out. I just think it's good to talk about such things especially at this point in time where people are on high alert with everything. I'm probably also a bit more paranoid after the whole XZ situation and one too many security meetings at work.

Is there any reason the program is closed source now? It seems there's been no update to it for a long time, now suddenly there's a new release with a changed PLG location and all the source code was removed from the GitHub repository. The newly released package contains a compiled binary but no source code to go with it. It's one thing to not include source code with binaries where the source code is publicly available (e.g. rclone), but with a self-coded project I'm pretty sure this is against Community Applications rules and in light of recent developments with the XZ Utils backdoor it really makes me nervous (probably unwarranted). I'm sure there's a solid reason and I don't want to throw around accusations at all, but better to get out in front of this. 🙂 It's just seems a bit weird that there was source code before and now it's suddenly removed before a new release is put out after a longer hiatus, the PLG location suddenly changing too... I mean why go to such lengths, inconveniencing the users with a PLG location change, to remove source code? https://github.com/jbrodriguez/controlr https://github.com/jbrodriguez/controlr/pull/36 https://github.com/jbrodriguez/controlr/commit/154360d41dac9591d8064656f8dffc97337fda1e @SpencerJ @Squid

blazer_ser only works with UPS connected via serial cable (that's why it wants a port = physical location of the device). Sorry then we're really out of luck, 2.7.4. was my last idea for this UPS basically 😕

Actually can you try something else - change NUT Backend to "legacy (2.7.4 stable)" in NUT Settings and reboot the system or reinstall NUT. Then try again with same driver (nutdrv_qx) - sometimes the old backend works better with some UPS.

I'm afraid your UPS doesn't seem to be supported at all, it cannot find or communicate with the device. NUT's hardware compatibility list also doesn't list that specific UPS as supported, so unfortunately it seems we're unlucky in this case. You can try with Unraid's "UPS Settings" (which use a different program: APCUPSD) if maybe the device will be detected there - but I'm not very hopeful. 😞

Is this on UNRAID? You have a weird mount setup for that - how do you mount these /netapp/ mounts? Also, are you sure your appdata is at /mnt/appdata ? It's usually on /mnt/user/appdata, /mnt/disk[number]/appdata?! Please check your paths again and possibly put 2>&1 behind your mergerFS commands so you'll also see any errors from stderr.