Leaderboard

fixed for you

Technically it is possible, but configuring it could potentially be quite involved. Your sharing PC meets to act as a router. I think Windows had a slightly less involved way but I remember it being hit or miss, but that was like 10+ years ago now.

TLDR: DON'T INSTALL THE SOFTWARE ON YOUR NAS, IT'S A SECURITY NIGHTMARE, DON'T INSTALL ANY SOFTWARE PROVIDED BY YOUR UPS UNLESS YOU REALLY, REALLY TRUST IT I bought a Powercool Smart UPS earlier this year, it arrived with linux software and installation scripts, but I had concerns about just running this on my NAS so elected to try and manually configure it via TrueNAS (I couldn't get it working properly so abandoned that and bought a new Eaton UPS which just works). I've just gone back to look at the Powercool UPS with the intention of getting it set up for my gaming PC and thought I'd check the software out. First thing I did was look at how it was installed, which is as root, no sandboxing, no user for the software (so it's never getting installed) Then I asked copilot to audit it (an actual good use for AI): The summary (full report attached as markdown) is: neokylin/ ├── install.sh 🟡 MEDIUM #4 — deletes/relies on predictable /tmp socket & lockfile paths ├── SECURITY-REVIEW.md (audit report — added by this review) ├── upsSmartView.desktop ─ (launches per-user GUI that talks to root daemon; context for #2) ├── upsSmartView.service 🟠 HIGH #2 — runs upsSmartServer as root, no User=/sandboxing, Restart=always └── upsSmartView/ ├── upsSmartServer 🟠 HIGH #2 — root daemon, system()-executed external program via unauthenticated /tmp socket │ 🟡 MEDIUM #4 — predictable /tmp lockfile (symlink attack) │ 🟡 MEDIUM #6 — writes cleartext SMTP/shutdown passwords to config │ ⚪ LOW #7 — insecure RUNPATH (relative `lib`, /home/zang/… dev path) ├── upsSmartServer.sh 🟠 HIGH #3 — forces LD_LIBRARY_PATH to EOL bundled libs ├── upsSmartView 🔴 CRITICAL #1 — hardcoded FTP update credentials; plaintext-FTP updater, MD5-only integrity │ 🟡 MEDIUM #5 — default password `123456`, weak credential storage in SQLite ├── upsSmartView.sh 🟠 HIGH #3 — forces LD_LIBRARY_PATH to EOL bundled libs ├── copylib.sh ─ ├── cp.sh ─ ├── istartTest ─ ├── snmpTest ─ ├── snmpv3_boot_counter ─ (encoded engine ID only; not a secret) ├── libpng12.so.0 🟠 HIGH #3 — libpng 1.2.54, EOL branch with known CVEs ├── upsevent_ch.wav ─ ├── upsevent_en.wav ─ ├── config/ │ └── IDBK/ │ └── upsSmartView.conf 🟡 MEDIUM #6 — cleartext credentials at rest, world-readable (0644) ├── dep/ (95 bundled libraries) 🟠 HIGH #3 — EOL/vulnerable vendored stack, e.g.: │ ├── libssl.so.1.0.0 🟠 HIGH #3 — OpenSSL 1.0.2v-dev (EOL Dec 2019) │ ├── libcrypto.so.1.0.0 🟠 HIGH #3 — OpenSSL 1.0.2v-dev (EOL Dec 2019) │ ├── libQt5*.so.5 🟠 HIGH #3 — Qt 5.9.8 (EOL) │ ├── libicu*.so.56 🟠 HIGH #3 — ICU 56 (ancient) │ └── … 🟠 HIGH #3 — old libc, libexpat, libgcrypt, libfreetype, etc. ├── lib/ │ ├── libupdateManage.a 🔴 CRITICAL #1 — contains the hardcoded FTP credentials / FTP updater code │ ├── libsnmpClient.so ─ (SNMP attack surface for #3's vulnerable parsers) │ ├── libSnmpManage.a ─ (SNMP attack surface) │ ├── lib<model>*.so ─ (UPS device protocol drivers) │ ├── cJSON/ ─ (leftover vendor build artifacts — CMakeFiles, .o files) │ └── libmodbus/ ─ (leftover vendor build artifacts) ├── platforms/ │ └── libqxcb.so 🟠 HIGH #3 — part of the EOL Qt 5.9.8 runtime └── sqldrivers/ └── libqsqlite.so 🟠 HIGH #3 — part of the EOL Qt 5.9.8 runtime (also where #5's weak-password SQLite DB is accessed) This is would appear to be an intentional developer backdoor/maintenance pipeline left in production code pulling anything from a remote chinese IP and running it on your computer. It would be trivial to push some code to your NAS that not only can execute anything including stealing your data, but also wipe the entire thing (or just wipe any trace of them having been there) SECURITY-REVIEW.md

The Eaton 3P Ellipse is what I ended up with, so far it's working well. I still need to detach some of the TrueNAS config I'd set up before in order to enable monitoring in HexOS, but I at least got it detecting

yikes, I haven't heard of this brand before but thats definitely a bit red flag. just curious which eaton psu did you go with? my Eaton Tripp Lite OMNIVS1500LCD works just likes to provide wonky data because the nut drivers for it aren't great.

Had a reply from the App auther he is investigating

at this time you are able to set that up if you modify your ups settings in truenas

Hey, Buddy Backup is always peer2peer, so each server is backing up to each server directly, you cannot pass through another server or get the data from another server. If possible, I highly recommend to do the initial backup from B to C locally and only then move C to it's final location.

We know what we want to do and are building the tooling to do it right. It's just premature to get into the details at this point, which is why we aren't sharing much at this stage. All in due time. Why would we take on investors and dedicate our lives to building something we didn't believe in? We definitely knew this would be popular which is why we built it. We are primarily targeting NAS newbies. The entire product is designed with that in mind. That is the majority of our currently deployed users. We have sold to an even larger audience that hasn't deployed yet for one of many reasons (waiting for certain features, waiting for hardware market to stabilize, etc.). Everyone has their opinion, but we are more than a "skin" or an "app." We are an entire replacement management solution for TrueNAS SCALE. SCALE is the engine, but we're the UX. I don't understand your comment about the "blurry line." TrueNAS is responsible for building the OS, middleware, their API, and ensuring a solid and stable platform. We are responsible for the UI/UX and everything we deliver through it. App publishers are responsible for the apps and OS vendors for the VMs. The "blurriest lines" are the responsibilities between app/VM OS vendors and us, but even that we take responsibility for the majority of the time (e.g. handholding all the Immich users through their database migration woes). The ugliest part of support is when the issue is hardware-specific and typically is the result of a hardware vendor doing a poor job of keeping their drivers in lockstep with the Linux kernel, which is not a HexOS or TrueNAS problem nearly as much as it is a hardware vendor problem. It's a good thing I have a great team around me to make all of this and so much more possible at the same time. The vast majority of customers are not having this issue. I've spoken with @mill3000 regarding your support tickets and it sounds like we've spent a lot of time trying to help as best we can, but at the end of the day, there is only so much we can do with bring-your-own-hardware. We have been consistently improving both reliability and performance and we rarely get the disconnect issue from users nowadays and when we do, it's fixed in short order. One of the downsides of being a software-based product is we don't control the hardware or the environment its placed within. Sometimes the combination of components and network just doesn't work right with certain platforms. It's unfortunately the case across the entire software-defined ecosystem. If you want a guaranteed experience with hardware, purchasing TrueNAS gear would be best, but that comes at a premium. I will say that we are working on a hardware advisor for both existing customers and new prospects that will help guide customers to the right gear to help avoid these kinds of pitfalls wherever possible.