Rysz

My version will follow the master branch more closely in general, with extensive testing and consideration by me before updating (so no blind pushing). It's designed to provide an alternative to Simon's plugin which users can choose to remain on if they feel it works well for them. I feel both the description in combination with the changelog would allow any more interested users to make a sufficently informed choice (probably more so than with many other plugins on CA). In general though, from my impression following the more than cautious NUT development these past months, users will likely not even notice a change in the backend unless they were having problems which suddenly become resolved - hence me not going further into detail on this in the description. If Simon should decide to deprecate his version, which is entirely his decision, I'll consider providing a legacy branch for users wishing to remain on the older "stables". Until then, they can choose from the multiple versions available as with most other popular plugins on CA. No offense intended and none taken from my side as well. 🙂

I literally described my vision for my "flavour" of the project above, nobody is forcing anyone to use it over Simon's version and it's his decision how he'll proceed with his fork. What's your end game with these questions, did I miss something on my end here? I'm just trying to offer users an alternative.

I'm in contact with Simon regarding the future of his plugin, right now mine's just "my alternative" with a more up to date backend (built from a recent master branch state), some bugfixes and a re-factored code base, which users can choose to use if they wish - just like Plex has different versions for example. For a full list of changes, basically anything in the changelog from 26/07/2023 onwards is different in my version - probably best to just compare or test it out. Seeing as NUT is a continuous integration project with a very irregular "stable" release schedule (sometimes spanning many months to more than a year), I feel it's currently best to offer users the latest updates from the master branch as opposed to updating the backend not once in more than a year (last "stable" was back in 05/2022 and tons of quality of life changes have been made since then). Users can always choose to stay on a version they feel well with, but I feel it'd be unfair to not offer the latest updates which might offer fixes for users with game-stopper type problems. I've been following the NUT development very closely and it's very reasonable and careful in nature, so I feel things are very unlikely to just "break" between any such backend updates. I might offer both a stable and developmental branch to choose from in the future, but not at the moment as I feel 2.8.0 "stable" is just too ancient compatibility-wise at this point and 2.8.1 is already on the horizon.

Make note of your configuration, uninstall the "old" plugin, install the "new" plugin. 🙂

It's an alternative version with a different (newer) NUT backend and a few minor bugfixes, you can choose which one to use, but don't install two at the same time - I'll clarify this better in the application description.

Yes, I've sent you a PR a couple of days ago with both SSL1/SSL3 packages: https://github.com/SimonFair/NUT-unRAID/pull/19

Hey - thanks for testing and writing here! 🙂 You need to remove the ; and space at the beginning of the line, that's only for commenting in the configuration files. So for your share to become enabled the share section needs to look like this: ; START OF DEFINE USER SHARES HERE SECTION [share] path = /mnt/user/DerperThought time machine = no ; END OF DEFINE USER SHARES HERE SECTION The above example would create a share called share linking to /mnt/user/DerperThought You could also (probably easier) name the share DerperThought too, then it'd look like this: ; START OF DEFINE USER SHARES HERE SECTION [DerperThought] path = /mnt/user/DerperThought time machine = no ; END OF DEFINE USER SHARES HERE SECTION Please let me know if it works now, you'll need to restart AFP or better your array for the changes to become active.

You made two admin users with differing rights... that makes no sense. Also you shouldn't use existing user account names (like root) for all this, better do it like this: upsd.users [admin] password=adminpass actions=set actions=fsd instcmds=all [monuser] password=monpass upsmon master [slaveuser] password=slavepass upsmon slave upsmon.conf MONITOR [email protected] 1 monuser monpass master SHUTDOWNCMD "/sbin/poweroff" POWERDOWNFLAG /etc/nut/no_killpower NOTIFYFLAG ONBATT SYSLOG+EXEC NOTIFYFLAG ONLINE SYSLOG+EXEC NOTIFYCMD "/usr/sbin/nut-notify" NOTIFYFLAG REPLBATT SYSLOG+EXEC and on WinNUT (in this example) you'll use username slaveuser and password slavepass. You can change the passwords, of course, but I'd keep the usernames simple like that. These are fictional users, they have nothing to do with your user accounts on UNRAID. monuser = only the device the UPS is connected to (UNRAID) slaveuser = all devices that should also shutdown (over network)

netatalk - AFP for UNRAID (6.10+) A plugin that integrates the legacy AFP file sharing protocol into newer UNRAID versions. The Apple Filing Protocol (AFP), formerly AppleTalk Filing Protocol, is a proprietary network protocol, and part of the Apple File Service (AFS), that offers file services for macOS, classic Mac OS, and Apple IIs. In OS X 10.8 Mountain Lion and earlier, AFP was the primary protocol for file services. Netatalk is a freely-available Open Source AFP fileserver, this plugin provides an integration of such a server into UNRAID. AFP was earlier removed from UNRAID - it is no longer being developed by Apple and is considered fussy and deprecated, however some people with outdated computers might have no other means to access their fileserver, while others might even prefer it over NFS or SMB for other reasons. This plugin for UNRAID was developed to let any such users finally update their outdated UNRAID servers without losing their beloved AFP file-serving capabilities or it might possibly draw back some users to UNRAID who couldn't live without AFP and switched elsewhere. For obvious reasons this plugin is still considered EXPERIMENTAL and is not officially endorsed by LimeTech. Please do report any issues or feedback you have in this topic, it'll help with the development of the plugin! How to install? https://raw.githubusercontent.com/desertwitch/nAFP-unRAID/main/plugin/nafp.plg (via UNRAID Web GUI: Plugins ➔ Install Plugin ➔ Enter URL ➔ Install) ... and hopefully coming soon to Community Applications. 🙂 How does it work? After installation AFP is disabled by default and waiting for your configuration. All necessary steps to configure and use the plugin are explained in the GUI (Settings ➔ AFP). How to contribute? https://github.com/desertwitch/nAFP-unRAID ... and of most importantly - please do test and report back here! Why do you have to revive this godforsaken protocol, just let it rest at last?! I, too, have a few old Apple devices that can only speak AFP... unfortunately! 🤪

Can you post your configuration (black out the passwords), the log you appended earlier makes me think it's a configuration issue. Access denied is usually due insufficient user permissions (misconfiguration) or wrong passwords.

Well, it follows your folder structure - so you can organize it as you want. For example it could be like this: = Holidays === Holidays in Spain ===== 2023 (photos in this folder) ===== 2022 (photos in this folder) === Holidays in Italy (photos in this folder) = House Renovation === New Pool (photos in this folder) So anything is possible if you organize it by folders 😋

How old is the UPS battery? It sounds like the battery is dying and the UPS battery can't handle your configured settings anymore before going into a LOWBATT state (which always triggers an immediate shutdown sequence). You can test this by putting the following setting with a lower "battery low" value (= from what battery percentage the UPS considers a LOWBATT state) in your ups.conf, but make sure to put it on line 15 or lower to not get overwritten: override.battery.charge.low = 10 If the shutdown is now happening later than before, it's your battery. If it doesn't change anything, try these settings (also put in ups.conf starting from line 15) ignorelb override.battery.charge.low = 10

Touché 🙃, but mine do at least offer the benefit of more than a year's worth of additional compatibility changes and bugfixes, so that's something I can live with considering the immense benefit for the end users. If we're custom building packages now, which you all seemed to advocate for, I'd at least build them offering the latest changes and keep them up to date as much as possible.

PiGallery2

https://github.com/networkupstools/nut/milestone/8 I think it's mostly continuous integration rather than following a regular schedule for official releases, probably best to build from the master branch every now and then.

Yeah, I'm guessing since it says "2.8.0-signed" it was built from this source code release: https://github.com/networkupstools/nut/releases/tag/v2.8.0-signed But that's more than a year old already, so many changes have been made to NUT since then. My versions were built from the master branch as of as of 26.08.2023, feel free to use them. 🙂

For the two of you and anyone else already on 2.8.0 but still experiencing incompatibility or problems with their UPS: I've compiled a more recent 2.8.0 backend package with the latest commits and changes based on the current state of the GitHub master branch (as of 24.08.2023), feel free to test if these upstream changes resolve your problems and please do report back here. A ton of bug fixes and changes have been made to the upstream NUT project since the NUT backend package (currently shipping with the NUT plugin) was last built (back on 30.04.2022), so it's definitely worth trying if you're still frustrated over something not working as intended. 🙂 If you do not have any problems, I suggest sticking with what you have installed. How to install this experimental version with the new backend? Uninstall your current NUT plugin Go to Plugins => Install Plugin Enter URL: https://raw.githubusercontent.com/desertwitch/NUT-unRAID/stale-testing/plugin/nut-2.8.0.plg Click on Install 🙂 Ideally restart your server (definitely restart your server if you run into problems) Here's a screenshot to illustrate the process:

Another confirmed working for NUT:

Thanks a lot - I can confirm this working with NUT on my instance. All relevant binaries and drivers remain accessible throughout the shutdown process. I've directed the other users experiencing this problem to the RC version as well. Hopefully we'll have one or two more people confirming this as working as expected now.

There's a fix available as release candidate now, can you test if it works now?

Might be the USB interface (of the motherboard) then. Could be worth trying a PCIe USB expansion card if it bothers you much.

I'm guessing it's because battery.charge.low is set or reported at 100% for some reason. This'll basically shutdown your system if the battery drops just by 1% (likely to happen during testing). You can configure this directly on your UPS or UPS software (what charge it considers as "low battery") If this value is reported wrong from the UPS (say it's set to 30% on your UPS, but NUT still shows 100%) You can override the value by putting into your ups.conf on line 15: override.battery.charge.low = 30 NUT should correctly report the battery.charge.low value then and act according to this value instead. But make sure to attempt to set this value on your UPS first - this is something that should be set on UPS. Only if it's set on UPS correctly and still reported wrong by NUT you should override the value via configuration:

Please note this when following these instructions to test the new 2.8.0 package. Unless you're also changing the MD5 in the plugin definition file to the MD5 of the new package, the new package will not survive your system rebooting. You'll be thinking you're testing the new package when you're actually right back on the old package. The MD5 mismatching will make UNRAID pull the old 2.8.0 package from the GitHub repository once the system boots. Just sayin'

Why is this a big step? Updates are good in general, I really don't like the idea of always staying on a low version to avoid issues for users who have no issues but maybe make it harder for new users with newer UPS units which are maybe supported by the newer version. NUT 2.8.0 RC3 has been released 04-2022, it's already 07-2023. The plugin has been bundling a 7 year old release (built as a package last 3 years ago) as it's default package until now. It seemed from previous posts on this topic that stability was the prime concern for not upgrading the default to 2.8.0 earlier, people trust things on their UPSs working after all. In the last few months people having problems have been increasingly offered the 2.8.0 flavour of the plugin bundled with the very Sotirov 2.8.0 RC3 (last stable release) package. That has since helped various users fix their problems and seems to be working well overall. I'm just asking, why not stick with the stable release 2.8.0 package that you've already offered to some of your users to fix existing problems and then maybe custom-build the next version for everyone (2.8.1 being around the corner)? It just doesn't make sense from a point of continuity to me to keep users on 2.7.4 for years for sake of stability, then offer a portion of them a 2.8.0 RC3 stable bundle as a band-aid but then not switch the rest over to that stable version when everything seems to work, but instead a 2 days old experimental build which like 3 people have tested so far. I couldn't find anything "built by Slackware", oldest 2.7.4 packages I could find in the repository were built by V'yacheslav Stetskevych according to the build scripts (maybe he's with Slackware?...) Well people are kind of trusting their hardware on their UPS and NUT functioning. So I do think as much careful package stability consideration and testing as possible should go into things working right from the release. But I'll not pursue this further, we'll have to agree to disagree here. I have the utmost respect for all the work done here and I'll continue to contribute my part but I'm one of those people who think that not doing everything in-house has it's benefits too. 🙂

So far everything's working with the new custom-built package. But I do have a consideration regarding the switching of packages over to NUT 2.8.0. The existing NUT 2.8.0 package in @SimonF's repository already is/was the latest stable NUT 2.8.0 (RC3), it's this one from a reputable source providing tons of other Slackware packages too: https://slackware.pkgs.org/15.0/slackpack-x86_64/nut-2.8.0-x86_64-1gds.txz.html (by https://sotirov-bg.net/slackpack/). It's a bit more than a year old, so this Sotirov's package is probably as well made, stable and tested (by a larger audience) as it gets for NUT 2.8.0 on Slackware - that all sounds good to me. Is it then really a good idea to make the already quite large step from a well tested and stable 2.7.4 to a newer 2.8.0 with a custom-built package when we could be switching to Sotirov's one year tried and tested NUT 2.8.0 (RC3) package, which already presents us with the latest official stable release available? Any additions to the NUT GitHub since the last official 2.8.0 stable release (RC3) one could basically still consider as experimental, since there's been no more official stable releases since RC3 and 2.8.1 (https://networkupstools.org/docs/user-manual.chunked/apis01.html) is still being worked on at the moment (but has not been released yet). I mean none of us here can remotely do so much testing with this new custom-built package that it would supersede Sotirov's package from a year ago in terms of testing and stability. Wouldn't it be better to rely on such a package since stability is the paramount concern rather than having the "latest fix"? To me it makes not so much sense that we waited so long with the upgrade from 2.7.4 to 2.8.0 because of stability concerns and then we switch to a few days old custom-built package when there's another more long-term tested and stable one around. Just throwing this in here for discussion, thanks everyone for the efforts.