Rysz

Interesting - never noticed this before, but has been here for 7 years: https://github.com/desertwitch/NUT-unRAID/blob/f76b4648b6184421694f4bfd20b813660555757d/source/nut-dw/usr/local/emhttp/plugins/nut-dw/NUTEditor.page#L50 It's the "autofocus" property of the configuration file selector, will be removed with next update: https://github.com/desertwitch/NUT-unRAID/commit/8bf54009c3e278bc1063c6530c9e6c007967e910

Done (included in today's update). 🙂

Thanks for getting back to me! cache=strict is what the CIFS mount defaulted to when mounting it without setting cache=none, so this seems to be the kernel default in the Unraid kernel as well. So cache=strict has resulted in a 8x-10x speed increase from 10MB/s to 80-100MB/s for me, when compared to cache=none, which is equivalent to my maximum network throughput. I have found some more posts on this issue, some dating back years, so this is possibly an issue with certain software/hardware combinations and Samba itself: https://ubuntuforums.org/showthread.php?t=2379232 https://arstechnica.com/civis/threads/poor-samba-performance.1203625/ https://forum.level1techs.com/t/baffled-by-samba-performance-and-variation-help/144418 https://www.truenas.com/community/threads/slow-samba-performance-with-cache-none-option-on-client.77369/ https://gitlab.gnome.org/GNOME/nautilus/-/issues/1973 Interesting is that it doesn't seem related to an increase in iowait, which seems equal with either caching mode. I understand the point about data integrity and consistency. cache=strict, being the kernel default since 3.7, seems to be a relatively safe choice here when considering the amount of time it has been the kernel's default setting (and the - I'm guessing - somewhat common use case of having multiple clients using a Samba mount at the same time). But I'm by no means an expert on mount options or kernel issues... Perhaps a configurable cache setting (strict/none/loose), possibly in combination with cache=strict as default or not, for CIFS mounts would be an idea or acceptable middle-ground for affected users like me? Personally I can patch this in manually on my system, but I'm just thinking into the direction of possibly less IT-experienced users who might run into this too (even if it seems to be a rare occurrence right now). 🙂

I'm having an interesting issue on 6.12.11 and 6.12.13. I've spent the last two days trying to track down why transfers from SMB/CIFS mounts to my Unraid array (which has no parity) suddenly max out at around 10MB/s (having worked well on previous versions of Unraid). This is despite disk and network benchmarks on both servers showing full to be expected speeds. After trying to rule out any other hardware issues and running tons of different scenarios, I've started playing around with the CIFS mounts themselves. Mounted through UD: //192.168.0.15/backup /mnt/remotes/192.168.0.15_backup cifs ro,relatime,vers=3.1.1,cache=none,username=rysz,uid=99,forceuid,gid=100,forcegid,addr=192.168.0.15,file_mode=0777,dir_mode=0777,iocharset=utf8,hard,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=10,closetimeo=30 0 0 results in all transfers maxing out at 10MB/s. Self-mounted with UD options, except cache=none: //192.168.0.15/backup /mnt/remotes/192.168.0.15_backup cifs ro,relatime,vers=3.1.1,cache=strict,username=rysz,uid=99,forceuid,gid=100,forcegid,addr=192.168.0.15,file_mode=0777,dir_mode=0777,iocharset=utf8,hard,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=10,closetimeo=30 0 0 results in all transfers at full expectable speeds around 80-90MB/s. I realize the cache=none flag has been unchanged in UD since 2021... But were there any SMB changes that could result in this problems I'm having (.. on my hardware) ? I'd use NFS but the performance on NFS is not ideal at 40MB/s, as opposed to the custom-mounted CIFS. I found this post similar to my issue: https://www.truenas.com/community/threads/slow-samba-performance-with-cache-none-option-on-client.77369/. Which suggests that cache=strict is a sensible setting in regard to oplocks while preserving reasonable performance, and that also seems to be CIFS default since kernel 3.7...

Great video - Alex is a real self-hosting legend and I'm also really liking this symbiosis of Unraid and Tailscale. Many thanks to our own @EDACerton for his plugin development efforts, making it effortless to install Tailscale.

Interesting, the link I posted above now also shows two positive detections. @ljm42?

No, it's not blocked - it takes whatever is set in "upsd.users" with administrative permissions.

It's taking the credentials set in upsd.users NUT plugin has as defaults admin/adminpass.

That is possible because not all commands require administrative access and these will work with a wrong user/pass combination also.

71 virus scanners/engines say it contains no virus... https://www.virustotal.com/gui/file/5432a7db786a1c1819bd14366bdd3d7691888b8d3ee5363c4cf88ab6d8f1c71b It is however possible that your computer already contains some malware that injects itself into incoming (new) files.

Unfortunately not easily, I'd also recommend building your service in a Docker container or VM instead. 🙂

I think the AiO script doesn't work on Unraid because of the dependencies, but you can try it. 🙂 But my plugin has "SnapRAID maintenance" settings integrated, which cover most functions of the AiO script. These settings were inspired and based on the AiO script and take care of periodic syncs, scrubs and other things. I've been using SnapRAID on my backup server for about half a year and it's been rock solid and a good solution for me. 🙂

This is a common firmware-related problem with the APC BX series and `apcupsd` (Unraid's UPS Settings). The only solution at the moment is to use the NUT plugin with the `preview (latest build)` backend configured... ... and these additional settings added to the end (on line 9 or later) of `UPS.CONF` using the GUI configuration editor: pollonly lbrb_log_delay_sec = 3 lbrb_log_delay_without_calibrating The backend itself can be changed inside `NUT Settings` and requires a plugin reinstallation or system reboot after the change. See for more information: https://sourceforge.net/p/apcupsd/mailman/message/58740970/ https://github.com/networkupstools/nut/issues/2347

I'll put it on the TO-DO list for the next update, you're right "NUT Commands" should be under "User Utilities".

Just to be sure, the default username/password combination in Unraid NUT is admin/adminpass, like this: upsrw -s input.eco.switchable=high-efficiency -u admin -p adminpass Eaton9E2000i So unless you changed this to something different in `upsd.users`, user/pass as in your command will not work.

Hmm, not sure about these values, but there's no difference in the `upsrw` program on Unraid. The program itself works as on any other OS, so either a general program problem or one on the UPS side.

It works fine here, we just recently tested this with another user too. What value are you trying to set?

Bei einer HDD würde man bei solchen Werten dringend zum baldigen Austausch raten. Ich würde es bei einer SSD mindestens genauso, wenn nicht überhaupt dramatischer sehen. Von allen SSDs die ich je besaß, hatte keine während ihrer gesamten Laufzeit je "Reallocated Sectors" o.ä. Man möchte meinen, dass es bei rein elektrischen SSDs hier noch weniger Spielraum, als bei mechanischen Elementen, gibt. Garantiefall ja mit Angabe die Platte wird vom System als entsprechend fehlerhaft erkannt, sollte ja doch uneingeschränkt nutzbar sein. Mit dem Wiederverkäufer würde ich mich hier gar nicht herumärgern (v.a. nach Ablauf einer gesetzlichen Gewährleistung) Direkt mit dem Händler klären, Scrutiny-Screenshots mitgeben und darauf verweisen dass du eine fehlerfreie SSD brauchst.

Thanks for the reminder, I managed to build a driver stub with the provided MIBs, hopefully as a starting point: https://github.com/networkupstools/nut/issues/2372#issuecomment-2370448103 Can't promise I'll be able to get something up and running, if I do I'll ping you for testing (as I have no 9PX).

Why not just use the pre-compiled binaries, they are bundled with all the dependencies. I just tested all the -glibc versions on 7.0 beta and they work just fine... https://github.com/borgbackup/borg/releases

So that everyone can be happy, I have added to the plugin settings a backend branch switch, where one can decide on the Python branch. The default branch "default" remains for full compatibility, stability and requiring little user interaction (has slower version turnover). But now the optional branch "latest" was also added for more bleeding-edge and featureful recent versions (has faster version turnover). 🙂

It works for me, what OS version are you on? Did you try turning "NUT Page Footer" to "No" => Apply => "Yes"? Did you try with another browser or after clearing your browser cache? ... or reinstalling the plugin (doesn't affect configuration), to see if that solves the problem for you?

Sorry man, I don't know what else to say here, but latest doesn't automatically mean greatest (or stable for that matter, but I never claimed it's beta either). It certainly won't "soon need updates already" (with a 2 weeks old version), because that is not the point of the plugin at all, neither is it running Home Assistant. I'm not providing this plugin for running huge environments on Unraid OS or power users and tinkerers expecting high-velocity version turnovers. The idea of the plugin is full OS compatibility, low-maintenance stability and careful version turnovers so that people can rely on their environments long-term with very little interaction necessary (as expected on a storage server). There are better ways to run larger environments than directly on bare-metal Unraid OS, yet Python can still be very useful for self-scripted and storage- or network-related maintenance tasks which this plugin is foremost aimed at (and well capable of).

Even if Python 3.12. were also considered stable or stable enough, it's still in active development (bugfix cycle). Slackware-current uses 3.11.10, as outlined in the initial post this plugin is not about bleeding-edge but full OS compatibility. Python 3.11.10 is less than two weeks old... it should be recent enough to get most things done without running into issues. In general I'd use Python on Unraid for smaller, daily maintenance things and put huge environments like HA into VMs, Docker...