Rysz

This is not related to NUT, but rather to the kernel USB subsystem (so the kernel version in combination with your hardware). There's not much to do on the NUT side, because with such instabilities, even if it retries initial connections, it'll fail again eventually. I'd try another USB port (maybe a 2.0 one) or worst case downgrade the OS/wait for an Unraid OS version with a newer kernel version...

On another look... is your UPS name wrong? You're monitoring "nut-srvr", but your UPS name is "nutups"? If you're monitoring "nut-srvr", the UPS name must also be "nut-srvr" - otherwise the GUI won't show the values.

Please try to spin up all your array disks and try the debug package generation again. By any chance, is the UPS server you're trying to connect to running on a UniFi UPS? I'm not sure about your exact setup though, what happens when you run in command-line: upsc [email protected]:34493

I just checked with RC2 and the NUT software itself is fully functional. Your system log has a lot of kernel USB subsystem errors, unrelated to NUT. Power saving (e.g. powertop) or a kernel version compatibility problem with your hardware are possible causes. These kind of problems can however also affect the connectivity of NUT with the UPS, even if not caused by NUT itself.

Please post the NUT debug package that's found in NUT Settings.

Regarding Unifi UPS devices, it seems my guess of a broken, non-compliant protocol implementation on their side was right: https://community.ui.com/questions/UniFi-UPS-sends-incorrect-responses-in-NUT-protocol/7f862573-eda4-4180-a987-0aca1233ee8a#answer/a857cb90-866a-4db0-9f8a-9e1dab1af14a This means that users will need to wait for a firmware update to fix these UPS-side issues.

Can you try running in command line: upsc [email protected] upsc [email protected] ups.status

Nothing unusual sticks out, but it says access denied and looks like a credentials issue. Although that is weird, because even with wrong credentials it should show information (just not register as "slave"/secondary). It does look like they perhaps baked in some stricter authentication on their own; other UniFi UPS users do report: Still no dice connecting to the NUT server while using authentication. Unauthenticated seems OK, just when setting a username/password the NUT server is returning a mix of "ERR ACCESS-DENIED" and "ECONNRESET" when attempting to connect from any 3rd-party NUT client. https://community.ui.com/releases/UniFi-UPS-1-4-13/fdd23b70-1191-4bc1-8485-d85c41a3a510 Maybe this is even some kind of "fake" NUT server (just speaking NUT protocol) that just isn't fully bug-free yet (just a guess). In any case, I'd also try maybe using credentials that don't have any special characters, that could be a factor also... not sure...

Please post the NUT Debug Package found in NUT Settings.

Can you try putting in your UPS.CONF on line 9 or later: synchronous Then save and (re-)start NUT?

Thank you, that's great to hear - please make sure to remove the debug line from the configuration again and restart NUT after. Otherwise the debug information will fill up your logs.

Please add to UPS.CONF: debug_min = 6 and try starting again, then post the debug package again.

I'm confident we can get this to work with NUT as it reports as: Bus 003 Device 002: ID 2b89:ffff UGREEN US3000 And this type of UPS is reported to work with NUT after some tweaking of settings: https://github.com/networkupstools/nut/issues/2987 First stop NUT, then set this setting: Then apply the setting and on the same page go to the NUT Configuration Editor. Put into UPS.CONF the following settings: Save the settings and then change this setting as follows: Then apply the setting and start NUT again, report back if it works. If it doesn't work, produce another debug package and post it again here.

Thank you, any chance you could also post the drivers you were given? I may be able to take a look if we can derive a driver for NUT from them.

Please post the NUT debug package which can be found in "NUT Settings", so I can take a look.

Thank you for the detailed debug package with debug level increased. I'm not sure what to make of your issue, although Eaton devices are usually well supported in NUT. I've logged an upstream issue with the NUT software package developers, and will investigate myself also: https://github.com/networkupstools/nut/issues/3136 I'll let you know if I have any news, hopefully we'll get this resolved for you, as soon as possible.

Please be nice to each oher and create a new support topic instead of reviving an old one.

No, every time it takes me +/- 15 minutes of looking through other people's GitHub repositories to identify where such package collisions are coming from. In this case it's even worse as this isn't even installed as a normal package, but actually bundled into another package, despite half that Python installation being unusable due to missing SSL libraries on newer OS versions. Two colliding Python installations will cause the problems and respective support volume we've seen in your case, so that's not something I can sustainably support in the long term. You can pull the packages themselves and put them into /boot/extra, if that's something you really want: https://raw.githubusercontent.com/desertwitch/python-unRAID/main/plugin/dwpython.plg

Thank you, it's the iSCSI plugin that installs a conflicting Python version. (not Disk Location) You'll have to use either that plugin's Python or uninstall it and be able to use my plugin's Python.

/usr/lib/python3.9/site-packages Another Python installation is somewhere on your system - my plugin does not ship Python 3.9. Please check /boot/extra (= extra folder on your USB stick) if there is such a package, remove it & reboot. Attach diagnostics to your next reply to this topic, so I can take a look at what might be causing this as well.

For what it's worth, I think this whole thing was blown way out of proportion (as it usually happens on Reddit). Most of the posts here actually raise some fair and interesting points. Anything tied to making money comes under heavier scrutiny and can seem somewhat shady or scammy, but that's more an unavoidable perception issue than anything else. Referral links are everywhere - you'd hardly see anyone blink at a "recommend a friend and get a discount"-type offer (e.g. for server parts). In the end, it's probably just the mix of the money-making aspect and the unfortunate referral links that stirred up all the drama... whether justified or not. Good for you that removed them, I'd save myself that headache too.

Honestly I do not see the problem here, creating Docker templates and listing them on CA also requires effort and time. Listing a referal link where otherwise a regular link would be is an easy, non-obtrusive way for people to support that effort with zero negative consequences for them. It's immediately obvious from the link also, so I don't see how this could feel unethical or sneaky either. There's people putting up donation links, this seems like nothing in comparison.

This is related to your USB connection (so either the server's or UPS bus or the cable itself). Easiest would be to try another cable or another USB port (2.0 ports usually are more stable). Otherwise more tricky to "solve", see here: https://forums.unraid.net/topic/60217-plugin-nut-v2-network-ups-tools/?&do=findComment&comment=1350269 In general with such things, unless something doesn't work, I'd probably just ignore the log messages myself.

You can use the existing parity file just fine, it's not bound to the OS in any manner. Easiest would be to mount them within unassigned devices, but then you'd need to roll your own solution for pooling the data (e.g. mergerFS). Otherwise many people put the disks into the Unraid array without Unraid parity (SnapRAID parity as an Unraid data drive) and use SnapRAID. In that case Unraid takes care of the pooling, you get the Unraid mover benefits (share settings etc), but keep using SnapRAID itself for parity. But unless you're super happy with SnapRAID or have a need for it (e.g. error correction), I'd also look at just using Unraid's parity (which is much easier).

The fix for your driver is now included in the "preview" backend that's part of today's update.