Rysz

Please raise the UPS Debug Level (not the monitor level) to 6 and restart the UPS with that to see the error. Then upload the NUT Debug Package (found in NUT Settings) here.

It's included in the OS now.

If it's after an update, it's usually kernel (USB driver) related, check this post for information: https://forums.unraid.net/topic/60217-plugin-nut-v2-network-ups-tools/?do=findComment&comment=1350269

Fair, for a new system you're probably better off doing that as it can test all memory as opposed to the plugin.

Please post a screenshot of the page where you're getting the error and include how much RAM you have installed.

It's normal it says some packages were not found during the uninstall process. If you're unsure you can reboot the server to ensure any leftover files are gone (but there shouldn't be any).

The UPS does know, it's just that this specific UPS series may report it differently than (most) others so the driver doesn't know what to do. 😉 In any case, if you don't have a power outage at that time - it's calibrating, if you do - it's on battery, and either of the flags tell the driver what's what.

NUT will shutdown your containers and VMs as part of the regular shutdown. It will not do that just because the system is on battery (prior to initiating shutdown). If you want to do that you'd have to use the scripting hooks (in GUI configuration editor) or NUT Actions. It's not supported in the GUI, but can be done in manual configuration mode. It's been on the roadmap for a long while, but it's a large effort and not many are asking for it. OL+DISCHRG usually means on battery or calibrating, some UPS like to expose it like that. The flags allow NUT to show the UPS as OB (on battery) or CAL (calibrating) instead when in this state. It ultimately depends on what your UPS is really doing when it's in this state, then you decide on which flag to use.

Just click on the "Preclear" button as you normally would, and choose "Verify Signature" instead.

It's under "Array-specific Settings" - "SnapRAID Maintenance - Schedule".

Python 3.14 and the uv package manager are now included.

You can edit the UseLogging parameter in the configuration file (in DVM settings). You'll have to restart the service afterwards.

This is a feature that is definitely planned before the v1.0.0 release. In fact all the latest updates contain changes paving the way for this very feature. It's definitely going to be a lot of work, but I want to implement that kind of update command. 😉

Those of you who have problems with NUT 2.8.5, please post logs and which UPS model you're using. Ideally raise the "UPS Driver Debug Level" to the highest level (6) before capturing logs. This can help get those problems fixed for future versions, older backends won't be around forever.

I agree with this take. I don't think that disclosure is the holy grail open-source projects make it out to be. What it does is give maintainers a shallow mechanism to weed out obviously unqualified pull requests without needing to waste their time or creating friction among the other contributors. I don't think this approach translates well to an application store ecosystem, at least not without the issues mentioned above. At the end of the day, disclosure works only as long as people actually disclose something - but in my experience the worst code is usually the one that's not disclosed.

If you're using it on Unraid then you can set up the notifications and cron schedule right in the GUI. Provided you're using the "par2cron for UNRAID" plugin from "Community Applications" ("Apps" tab). You can then find the plugin settings at the end of the "Settings" tab ("par2cron") or otherwise via URL: https://<your Unraid IP>/Settings/dwpar2cron If verification fails you'd be notified and a repair attempted (depending on your plugin settings). You can also set it up to just notify you and you can then manually execute the repair, it's all up to you. Whether it deletes the corrupted file after repair can be configured in the configuration file (by default it does). "Error Notifications", when enabled, would be what notifies you of a verification failure (due to corruption). Naturally you will also always see it in the logs section of the GUI for that respective last ran operation. If you're using it outside of Unraid you'd need to set up your own logs/notifications using your own scripting.

@paulio23 @Karools The new version is now released with the performance fixes and the ability to select one or multiple shares to use par2cron on. Many thanks for your valuable feedback and testing. 💛

Many thanks for the performance profile, it confirms there's no application level bottlenecks anymore. I/O wait aside, the program would be done in 1.5 minutes for the whole array, but there's significant waiting on I/O. Meaning it's the program is spending all that time waiting on the disks to seek and return the requested information. The media share being slower now is likely due to caching effects, maybe more information was cached at the previous run. File: par2cron Type: cpu Time: 2026-04-09 04:31:58 CEST Duration: 2157.09s, Total samples = 98.30s ( 4.56%) Showing nodes accounting for 98.30s, 100% of 98.30s total ----------------------------------------------------------+------------- flat flat% sum% cum cum% calls calls% + context ----------------------------------------------------------+------------- 77.84s 100% | syscall.RawSyscall6 syscall/syscall_linux.go:65 0.01s 0.013% | internal/runtime/syscall/linux.EpollWait internal/runtime/syscall/linux/syscall_linux.go:32 77.85s 79.20% 79.20% 77.85s 79.20% | internal/runtime/syscall/linux.Syscall6 internal/runtime/syscall/linux/asm_linux_amd64.s:36This is unfortunately the hardware limitation here, so there's nothing more we can optimise except for limiting the scope itself. I'll get this new version released today together with changes to allow selecting only a specific share to run par2cron against. I want to allow selecting multiple shares to run it against, but that's a larger task, so for now it'll only be whole array or one specific share. Thanks again for all your feedback, without it I wouldn't have been able to make these improvements. 😉

Many thanks for bearing with me here, I think I've identified the core issue. The problem was that the ignore-file-checker added two stat syscalls per directory, that can quickly scale up. When initially designing this, I didn't really tune this path for performance thinking most people will run it at night... But I've now refactored that and reduced it to the one necessary syscall and mostly zero allocations in the hot path. I'd have a pre-release version ready for testing with the fixes implemented, reducing scanning time by ~50+%. I'd be very grateful if you could test if this version significantly reduces the scanning time against /mnt/user. Just take care that you're executing this version and not the old (installed) one... If it still feels like it's too long, you can run it with par2cron create /mnt/user --pprof perf.pb.gz That will create a performance profile (just of what the application is doing internally, no paths or sensible data) If you'd upload (or DM) that for me I can take a look at what is causing the wait and if it's I/O or a congested application path. Again many thanks for your feedback, it's much appreciated. 😉 par2cron_0.2.2-SNAPSHOT-d7812bf_linux_amd64.tar.gz

Was this during a parity check or something that could impact I/O? Because I cannot replicate this, a similar setup with 4 million files completes in less than 10 minutes here. I'm optimising hot paths some more, but I cannot figure out what would cause a one hour filesystem scan. Unless it's something in your environment that's severely bottle-necking I/O, but your find is much faster... Anything unusual come to mind about your environment or setup as a whole? I'll look into allowing choice of path or shares... but still the one hour seems way out of proportion here.

Thanks for the responses, that definitely feels like it's too long. I'll look into it, how many disks and TBs do you have? Ideally if you know/could check how many files your /mnt/user contains, I could tell if it's a bug or really that slow because of the amount of files. Also, was the indexing always this slow or it got massively worse with this week's update?

Thanks for the quick response and detailed report. The problem should be fixed with the most recent update of the plugin (2026.04.07d/v0.2.2). I've got a few more improvements planned, namely I want to add another creation mode "nested". In nested mode a self-contained PAR2 set shall be created for any matched (sub-)folder's contents. Placing one marker in a top-level "Movies" would create "Movies/A/A.par2", "Movies/B/B.par2", ... sets. Marker files could be set to persistent, specifically for "nested", with PAR2 sets for new folders created from one top-level marker file. The scheduled creation would just pick up that marker file repeatedly, skip folders with existing PAR2 sets, and create sets for those without any. I figured this could be helpful for growing media libraries with a continuous intake of new content, without requiring marker file recreation. Updating a PAR2 set could then be as easy as just deleting the old PAR2 set, without ever needing to recreate a marker file... that's how I pictured it. Anyway this will most likely be part of a more extensive effort, especially on the documentation side, so this'll probably take me a longer while. 😉

The latest update now contains the changed implementation. You will need to use either folder (one PAR2 set, see below) or file (one PAR2 set per file) creation modes for any glob possibly spanning multiple folders. The reason is that recursive mode triggers par2cmdline's "dumb" recursion (which just includes everything in subfolders), and we don't want double-recursion. See more about this in the documentation, but the program will error anyway if you made a mistake: https://github.com/desertwitch/par2cron#creation-glob-patterns Glob pattern **/*.{mkv,avi,mp4,idx,sub,srt,ass,ssa} (in folder creation mode) will now create for this example folder: Run All Day (720p) ├── Run All Day.mkv ├── Run All Day.orig.nfo ├── _par2cron └── sub ├── Run All Day.en.sub └── Run All Day.idxOne PAR2 set called Run All Day (720p).par2 (in the marker-containing directory) protecting: { "name": "Run All Day.mkv", "size": 5863690768, "mode": 511, "is_dir": false, "mod_time": "2015-06-02T15:13:02.734571313+02:00" }, { "name": "sub/Run All Day.en.sub", "size": 9330688, "mode": 511, "is_dir": false, "mod_time": "2015-06-02T13:57:01.121948951+02:00" }, { "name": "sub/Run All Day.idx", "size": 59657, "mode": 511, "is_dir": false, "mod_time": "2015-06-02T13:57:01.503980322+02:00" }I believe this is what you want to achieve with your pattern, but let me know. 😉

Thanks for the valid feedback, glob support is indeed relatively (too) limited. I have good experiences with the doublestar library, would these patterns help you achieve what you want? https://github.com/bmatcuk/doublestar#patterns If so, I can probably relatively seamlessly switch the current glob implementation to this more featureful one.

This is not really correct, the Unraid NUT plugin does ship with an USB-supporting libmodbus. It's possible the UPS is not supported by this relatively new driver, but the library is the required one.