Samsonight

How are yours set up? In detail, where possible. Good point. Bringing arrays from several Unraid servers together on one server is exactly what multiple arrays should make easy, so I'm planning an export/import for the plugin: - Export on each old server: a file with each slot's disk (serial, size, parity or data, slot number) and the array's own settings. No passwords or keys. - Import on the new server: the file becomes the main array or an extra one. Unraid recognises array disks by serial number and size, so the import matches each slot the same way, shows you the full plan before anything is written, and stops if a slot doesn't match exactly one free disk. Slot order is kept as it was, which matters with two parity disks, and nothing is formatted. Then the disks start in their old slots with parity still valid, with no guessing which disk was parity. For arrays in VMs it depends on how the disks reach the VM. If each VM gets its controller passed through, the VM sees the real disks with their real serial numbers, and the import is the same pure mapping: no copying and no new parity sync. With virtual disks or disk images it would mean copying the data and building parity again, which an import can't avoid. Disclaimer: Multi Arrays is an independent project, not made or supported by Lime Technology. Neither its author nor Lime Technology takes any responsibility for any results caused by this plugin or its implementation. It is a proof of concept, meant only to show how simple support for multiple arrays could be. If that doesn't sit well with you, wait for the official support for multiple arrays in Unraid.

Agreed — vagueness from a vendor is a poor sign today, and ownership is ownership. The direction of travel in the industry is clear and runs entirely your way: Coordinated Vulnerability Disclosure (CVD) is the documented norm (ISO/IEC 29147 for disclosure, ISO/IEC 30111 for handling). A vendor is expected to publish an intake channel, acknowledge reports, assess them, and state a verdict — “affected / not affected / won’t fix, and why” — rather than leave users to guess. CISA’s Secure by Design pledge explicitly asks vendors to own CVE issuance for their own products, including accurate CWE and CVSS data, and to publish advisories themselves instead of waiting for users to do it. The EU Cyber Resilience Act (CRA) turns this from good practice into law. As of 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents affecting their products, and that notification duty applies to all in-scope products with digital elements, with fines of up to €15 million or 2.5% of worldwide turnover for non-compliance. The full vulnerability-handling and CE-marking obligations follow in December 2027. A commercial NAS OS sold into the EU is squarely in scope. Transparency is the product. Modern expectations include a public security advisory page, machine-readable advisories (CSAF/VEX), and an SBOM so customers can answer “does this affect what I bought?” without filing it themselves. cyber resilience act reporting obligations in force One more thing I’d stress: a vendor on their game issues verdicts proactively, not only when a report lands on their desk. When something is circulating — a CVE in an upstream component, a forum thread, a blog post — the expected response is a short statement: “We’re aware this is circulating and causing speculation. We are not affected, because [the vulnerable code path isn’t reachable / the component is built without that feature / the service isn’t exposed by default]. No action needed.” Or, if they are: “Affected in versions X–Y, mitigation is Z, fix lands in release W on date D.” That is precisely what VEX (“Vulnerability Exploitability eXchange”) exists for: a machine-readable “not affected, and here’s why”. Silence lets speculation fill the gap, and the vendor is the only party who can close it with authority. So filing CVEs and letting the community weigh in isn’t jumping the gun — it’s doing the vendor’s job for them. And frankly, without this particular “gun jump” the subject wouldn’t even be on the table: nobody would be discussing it, nobody would be asking the vendor for a verdict, and the issue would sit unacknowledged until someone exploited it. That alone shows the process working as intended. The fix for noisy or low-impact entries is a vendor statement with a verdict and an ETA, not silence. References from earlier discussions: - CVE Reports board (its own header): "This board is solely for publicly disclosed CVEs" — https://product.unraid.net/b/cve-reports - 2021-12 Log4Shell: users asked why nothing was pinned from Lime Tech; the "OS not affected" answer came from the community — https://forums.unraid.net/topic/117267-any-log4shelllog4j-risks-with-unraid-os-andor-popular-docker-containers/ - 2022-03 Dirty Pipe (CVE-2022-0847): "Can we get a patch for this?"; stable fix came with 6.10.0 on 2022-05-17 — https://forums.unraid.net/topic/120883-unraid-os-692-vulnerable-to-dirty-pipe-cve-2022-0847/ - 2024-03 xz backdoor (CVE-2024-3094): users checked the OS's xz version themselves; no vendor statement in the thread — https://forums.unraid.net/topic/159952-mar-29-2024-xzliblzma-potential-compromise/ - 2024-07 regreSSHion (CVE-2024-6387): "Is there a formal policy on patching critical CVE's in unRAID?" / "just be upfront about it"; fixed in 6.12.11 on 2024-07-16 — https://forums.unraid.net/topic/169144-are-there-any-mitigations-for-cve-2024-6387/ - 2025-01 Lime Tech's own disclosure post, which shows how it should look: who is affected first, fix, patch plugin, credit — https://forums.unraid.net/topic/185572-critical-security-vulnerabilies-discovered/ (same thread: "I can't seem to find a security contact on the Unraid site.") - CISA Secure by Design pledge, CVE goal: "CISA cautions against interpreting the mere presence of CVEs as a negative sign ... more comprehensive reporting of CVEs benefits everyone." — https://www.cisa.gov/securebydesign/pledge - EU CRA reporting obligations, from 11 September 2026 — https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

There are now two open pull requests for this, so the people who asked for it to be looked at can follow them: https://github.com/unraid/webgui/pull/2811 keeps a hand-set guest address and a ua- alias on a PCI device when you save from the form, and stops multifunction='off' being read back as On. https://github.com/unraid/webgui/pull/2812 keeps clock timers, input devices, sound and graphics settings the form has no field for. Neither is merged, so a form save still behaves as described in this thread. For the original post: - The aliases are not the problem. They are libvirt's own names, and libvirt drops them when a VM is defined, with or without the form. - Much of the big diff is a running VM compared with a stopped one. id='1', index=, backingStore and the alias lines only appear in the XML of a running VM. - The change that matters is the GPU and its audio ending up on different guest buses. Since Multifunction was added to the form, setting it to On for the GPU keeps the two together, though on a bus the form picks, not the one you set by hand. - Other PCI devices that share a slot are still split onto separate buses by a form save, and neither pull request changes that. If your VM breaks after a form save in a way this doesn't cover, please post the XML from before and after, with the VM stopped both times.

<reserved post>

<reserved post>

Support thread for CVE Lens for Unraid, the plugin formerly called Trivy Scan. Until now it was discussed in the CVSSv4 9.2 PHP vulnerability topic What it does It scans the images of your containers and the Unraid OS for known vulnerabilities and shows one row per CVE: what is affected, whether an update or a newer image fixes it, and which targets could not be scanned and why. Container images are scanned with Trivy. Trivy has no advisory data for Unraid's Slackware packages, so those are matched against NVD with Grype. - Known exploited badge (CISA KEV), EPSS score and an "Exploited / likely" filter - Notifications for new fixable critical CVEs, and when a known exploited CVE newly affects a container image - End of life marking for base images that no longer get fixes - Ignore list with a reason and an optional expiry date - Container risk table: privileged, Docker socket, host network, ports on all interfaces and so on. Environment values and command lines are never read. - CSV and JSON export, new and gone CVEs since the last scan, a small trend line - Progress panel, log viewer, dashboard tile and an optional "Vulnerabilities" header tab Screenshots and full documentation: https://github.com/luuvasara/unraid-cve-lens Install Plugins, Install Plugin, paste: https://raw.githubusercontent.com/luuvasara/unraid-cve-lens/main/unraid-cve-lens.plg Requires Unraid 6.12.0 or later. The plugin is not in Community Applications yet. Updates come through Plugins, Check for updates. If you still have Trivy Scan installed, updating it moves you over to CVE Lens with your settings and data. First scan Nothing is scanned or downloaded at install or at boot. Open Settings, CVE Lens and press Scan now, or set a schedule. The first scan downloads about 6 GB of databases to your appdata folder and can take a while. Later scans reuse them. Settings, CVE Lens, Databases has the options. The scanners run in containers pinned by digest. The container that can read the Docker socket has no network, and the ones with network have no Docker socket. Reading the results A finding means an installed version is in an affected range, not that it can be exploited on your server. The Known exploited badge and the EPSS score help you decide what to look at first. - In a container image: update the container. If the newest image still has it, the fix has to come from the image's maintainer, so raise it in that container's support thread. - In the Unraid OS: the fix comes with a newer Unraid release, so don't patch it by hand. NVD only knows upstream versions, so a fix that was backported into a release can still show up. Check the release notes; "Ignore..." in the expanded row hides a finding with a reason. Asking for help A report without details can't be answered. Every request needs all of this: - Unraid version and CVE Lens version - What you did, step by step - What you expected, and what happened instead, with the exact error message - The image or package and the CVE, if it is about a finding - The relevant log lines (View log on the report page, or /var/log/unraid-cve-lens.log). Read them before posting, as they name your images. - A screenshot, if possible Bugs, feature requests, pull requests and development discussion belong in the repository, not in this thread: - Bugs and feature requests: https://github.com/luuvasara/unraid-cve-lens/issues - Discussion and ideas: https://github.com/luuvasara/unraid-cve-lens/discussions - Pull requests: https://github.com/luuvasara/unraid-cve-lens/pulls Use this thread for previously unanswered questions about installing and using the plugin. Anything else will be pointed to the repository, so that it stays in one place and can be tracked. Thanks to @Xaero for the original plugin this grew from and for the OS package matching.

Four releases: 2026.11.03 with @Xaero 's work, 2026.11.04, which renames the plugin to CVE Lens for Unraid, and 2026.11.04a with new features. 2026.11.04b: CVE Lens now runs on Unraid 6.12 (6.12.0 or later). On 6.12 the OS scan failed before, because Docker older than version 25 doesn't know the mount option it used; that is fixed, and the dashboard tile now matches the stock tiles on 6.12, 7.0 and 7.1. Older releases (6.9 to 6.11) are not supported: their dashboard has no API for plugin tiles, and they are not tested. Update through Plugins, check for updates (an older install goes straight to 2026.11.04b). A new install uses: https://raw.githubusercontent.com/luuvasara/unraid-cve-lens/main/unraid-cve-lens.plg The rename. The plugin now checks more than Trivy's output (the OS packages are matched with Grype, see below), so the name changed. The repository moved with it: https://github.com/luuvasara/unraid-cve-lens. The old addresses keep working. Updating the Trivy Scan entry installs CVE Lens and moves everything over by itself: - settings, schedule and os-ignore.txt are copied; - the data folder (databases and the last report) is moved, so nothing is downloaded again; - the old log is added to the new one, older notifications open the new page, and the dashboard tile keeps its place; - about a minute later the Trivy Scan entry removes itself, along with its folder on the flash drive. The header tab is still "Vulnerabilities". The settings page is now Settings, CVE Lens, so a bookmark to /Settings/TrivyScan needs updating. 2026.11.03: Unraid OS packages are now checked for CVEs. Most of this is @Xaero 's work: six pull requests, all merged. This was the big gap: Trivy has no advisory data for Slackware (or for the Fedora base of Unraid 8), so the ~400 OS packages were only listed. Now the package list is mapped to NVD product names and matched by upstream version with Grype, in a container with no network, no Docker socket and nothing of the host except that list. Settings, Unraid OS: "Match OS packages against NVD" (on) and "Include the kernel" (off). NVD only knows upstream versions, so a fix that was backported into an Unraid release can still show up. Check a finding against the release notes; os-ignore.txt next to the settings file hides a CVE. NVD entries without a version range (they match every version) and disputed entries are listed as "not counted", with the reason. On the 7.3.4 release files that leaves 73 CVEs out of 160 raw matches. OS package matches never trigger the "new fixable critical" notification. Also new in 2026.11.03: - Settings, Databases: per database (Trivy, Java, Grype), keep it on disk between scans or download it for each scan and delete it afterwards, with its size shown. All are kept by default; the Grype database is about a 200 MB download and 3.1 GB on disk. - Target filter in the report: everything, the Unraid OS, container images, or one image. Fixes: - With many images the report step could run out of memory and fail with an empty log line. It now has room for large runs, logs the real error, and keeps the scan results so the report can be rebuilt without scanning again. - Locally built images (compose, docker build) are no longer sent to the registry check, which could only fail with "authentication required". - @Niklas the header tab's page is now named Vulnerabilities, so the browser title matches the tab label. A bookmark to /TrivyScanTab needs updating. Tested in a 7.3.4 and 6.12.15 VM: the update from Trivy Scan through "Check for updates", the update to 2026.11.04b, scans, a reboot, and the pages checked in a browser. 2026.11.04a: new features - Exploit data: a "Known exploited" badge for CVEs on CISA's KEV list, an EPSS column (the estimated chance of exploitation in the next 30 days), an "Exploited / likely" filter and a count in the summary. A CVE that newly appears on the KEV list and affects a container image triggers a notification. Settings, "Exploit data" turns it off. - End of life base: images whose base OS release no longer gets fixes are marked, so "no fix" findings there make sense. - Ignore list: "Ignore..." in an expanded CVE row hides a finding for all images, one image or the OS, with a reason and an optional expiry date. Ignored findings are left out of counts and notifications; when an entry expires, the CVE counts again and notifies once. - Container risk: a collapsed table with the settings of each container that matter for security (privileged, Docker socket, host network or PID, added capabilities, devices, runs as root, ports on all interfaces, no healthcheck, :latest). Environment values and command lines are never read. - Export and history: CSV or JSON of the current view or the whole report, the CVEs that are new or gone since the last scan, and a small trend line. - Progress panel: while a scan runs, each step with its time, the download and then the unpacking of each database with time left, images scanned, and the latest log lines. Afterwards it shows how long each step took. - View log: one click on the report page, the settings page or the dashboard tile opens Unraid's live log window. - Which scanner found what: a card each for Trivy, Grype (NVD) and the exploit data, with version, database date, what it covered and what it can't see, plus "Trivy" / "Grype · NVD" tags on every CVE and a "Found by" filter. On a slower box the first scan takes a while. On a test VM limited to 2 cores, 4 GB and a hard-disk-speed array it took about 40 minutes, most of it unpacking the databases (the Grype one alone about 25 minutes); later scans reuse them. The progress panel shows where it is. Thanks again @Xaero for the original plugin this grew from. Feedback and PRs welcome as before. Ping for those who asked for a CVE / vulnerability scanner for Unraid over the years: @L0rdRaiden (the most active forum proponent towards this kind of functionality) @HelixX23 @caplam @nearcatch @Jclendineng @a_n_d_y @nametaken_thisonetoo @pish180. And a wave to @mstrhakr maintainer of Compose Manager Plus and @primeval_god for the original Docker Compose Manager.

Multiple arrays: a working proof of concept Multiple arrays turned out to be within easy reach, so I built a proof of concept to show how little is actually needed. It is meant as a demonstration for Limetech and anyone curious, not as something to run on your server. Please don't install this on a production server. It loads its own copies of the parity driver and has only been tested in a VM. Use a test box or a VM with disks you don't care about. The goal is to show that proper built-in support is close, not to replace it. Why it's simpler than it sounds Each array is already a self-contained unit, so a second array just needs a second copy of the same stack: - Parity driver: one more copy of Unraid's own md driver per extra array, under its own name (a ~200-line rename patch). - Array management, user shares, mover: unchanged. Each extra array runs Unraid's own components with its own config, state and /mnt. - Main tab: Main2, Main3 … are generated from the stock Main page of the running Unraid version, so they look and work the same (Start/Stop, Check, Spin up/down, live stats). - Disks: Settings › Multi Arrays has a pinning grid, same idea as CPU Pinning: each disk belongs to one array, and an array only sees its own disks. Hot-plugged disks show up on their own. No Unraid file is modified and the whole thing is under 800 lines. The arrays never need to talk to each other; moving data between them is just a copy from one mount to another. To make the GUI side even easier to adopt, I've opened a pull request on the webGUI that lets the stock Main page sections take an array number instead of assuming a single array (no change for existing setups): https://github.com/unraid/webgui/pull/2813 What was tested (Unraid 7.3.4 in a VM, three arrays running at once): parallel parity syncs and checks (0 errors), a pulled disk with emulated reads and a rebuild, start/stop of the main array taking the others along, and install/upgrade/removal. What a proof of concept leaves out: share export (SMB/NFS) and scheduled jobs for the extra arrays, per-disk pages and parity history on the extra tabs, and a driver build for every kernel. All of that is ordinary work once it lives inside Unraid itself. Why now, and not wait for Unraid 8 @tjb_altf4 asked whether multiple arrays will still come in the 7 series or move to Unraid 8. Unraid 8 was announced in August without a release date, and moving to a new base OS is a big job of its own, so my estimate is that it is well over a year away. And a release date is not the date people can use it: nobody moves a multi-TB production server to a new base OS on day one. Most will wait for it to settle, and for the whole ecosystem built up over the 6 and 7 series, every plugin and every App (container template), to be ported and field-tested on the new base. That adds many months more. Plenty of servers are still on 6 today, simply because their owners have had no real reason to change, and a new base OS alone won't give them one. Multiple arrays were promised for the 7 series, and this shows they fit there: nothing in this approach depends on the base OS, so the same design carries straight over to Unraid 8 afterwards. Carrying the arrays themselves from 7 to 8 is just as simple. Unraid 8 will read the same on-disk format and use the same methods as 7, because otherwise nobody could upgrade: nobody is going to be asked to convert multi-TB arrays. An extra array is exactly that format (the same parity layout and the same disk filesystems), with its own config folder on the flash. So Unraid 8 will support it natively from day one. And even if Unraid 8 shipped with no multi-array support at all, upgrading a multi-array server would still just work: the main array is untouched by all this and starts as usual, and the extra arrays simply sit idle as unassigned disks with their data and parity intact, waiting for the logic to arrive. That is how native this is: nothing about the main array or the disk format changes. (The one rule while they wait: don't assign or format those disks elsewhere.) The only thing that decides whether multiple arrays are there is whether the logic is included in Limetech's code, and that logic can go into the 7 series today. For everyone who has asked for this over the years: @Lolight @my.name.jeff @Raki72 @hawihoney @marcelunraid @niteman1969 @Gabcraftia @jcm808 @I Enjoy Creating Videos @PeterDB@Jerky_san @swamiforlife @Rudder2 @jortan @XDUDE3D @Maximus01701 @aglyons @StancuFlorin @PiMan314159265 Disclaimer: Multi Arrays is an independent project, not made or supported by Lime Technology. Neither its author nor Lime Technology takes any responsibility for any results caused by this plugin or its implementation. It is a proof of concept, meant only to show how simple support for multiple arrays could be. If that doesn't sit well with you, wait for the official support for multiple arrays in Unraid.

Re the NOCOW-leftover suggestion above: I put together a small check that warns when a share's Copy-on-write setting is Auto but its btrfs folder still has the NOCOW attribute (btrfs only, read-only, one lsattr per share). PR: https://github.com/unraid/fix.common.problems/pull/10 Feedback on false-positive handling welcome - e.g. whether it should be limited to domains/system.

Follow-up to my earlier posts here about Reboot/Shutdown ending unclean while the mover, a btrfs scrub/balance or a ZFS scrub is running. I measured it on a 7.3.4 test VM and opened two webGui PRs as proofs of concept: - https://github.com/unraid/webgui/pull/2809 : the GUI blocks Reboot, Shutdown and array Stop while such a job runs, names the job and says how to resolve it ("do it anyway" stays possible). - https://github.com/unraid/webgui/pull/2810 : rc.local_shutdown clears those jobs before the timed array stop. This covers what the GUI can't block: UPS, power button, Ctrl-Alt-Del, command line. Measured (Reboot from the GUI, one run each, pool disk throttled so the jobs last): | Job running | Stock 7.3.4 | Patched | |---|---|---| | mover, 3 GB file | "Forcing shutdown..." after the 90 s timeout | 32 s, clean | | btrfs scrub | forced, unclean, parity check at boot | 33 s, clean | | btrfs balance | forced, unclean, parity check at boot | 35 s, clean | What's actually going on: - Stop is disabled during parity/mover/btrfs operations, but Reboot and Shutdown check nothing. ZFS scrub isn't handled at all, not even for Stop. - The mover can't simply be stopped. The current file is copied inside shfs, so mover stop and even kill -9 on move don't end it. The user share stays busy until that file is complete, and with a big file that's longer than any sensible timeout. Ending that copy leaves the source intact and a .partial file on the array, which the next mover runs clean up. - Every shutdown path ends in the same single timed array stop in rc.local_shutdown. Nothing in it stops the mover or cancels a scrub or balance. Why it matters more every year: I found 19 public reports of timed-out or unclean shutdowns since 2016. In 10 of them the answer was "raise the shutdown timeout". The default is still 90 s, it's one fixed value for every system and every running job, and on a UPS it is capped by the battery anyway. Meanwhile drives keep growing (Seagate's average shipped capacity went from 7.3 TB to 13 TB between late 2022 and mid-2025). So the forced parity check after an unclean shutdown now takes a day or more once the largest disk is 14 TB or larger. Sources, timeline and the reports themselves are in the PR descriptions. The PRs are meant to show that this is reproducible and fixable with small changes. Whether Lime Technology takes them or does it better, I'd mostly like to know why it has stayed open this long.

Re the NOCOW-leftover suggestion above: I put together a small check that warns when a share's Copy-on-write setting is Auto but its btrfs folder still has the NOCOW attribute (btrfs only, read-only, one lsattr per share). PR: https://github.com/unraid/fix.common.problems/pull/10 Feedback on false-positive handling welcome - e.g. whether it should be limited to domains/system.

@Niklas thanks for the screenshot. That's a second bug, also on my side: the Scan now / Stop / Update DB buttons re-checked the CSRF token after Unraid had already checked it and removed it from the request, so they always refused. My tests ran without Unraid's request handler, so they never saw it. Fixed in 2026.11.01c (Plugins, Check for updates), then Scan now again. Scheduled scans were not affected. Please mind Github cache expiration delays, in minutes. You can use the direct url https://raw.githubusercontent.com/luuvasara/unraid-trivy-scan/main/unraid-trivy-scan.plg on the Install Plugin page to override it (it will install whichever version is actually in the repo).

Thanks for the report @Niklas . Classic "works on my computers": every one of mine had already had the plugin, so none of them hit it. On a true first install the pre-install step exited with code 1 because no earlier package was on the flash, and Unraid aborted. Fixed in 2026.11.01, please run the install again from the same URL.

@Xaero I took your plugin as the base and put it up here: https://github.com/luuvasara/unraid-trivy-scan Install (Plugins, Install Plugin): https://raw.githubusercontent.com/luuvasara/unraid-trivy-scan/main/unraid-trivy-scan.plg don't trust random repos ❤️(which is funny as forking and pull requests do exactly that 😉) Changes vs. your original: - Trivy pinned by version and digest instead of :latest - the container holding the Docker socket has no network; registry logins only go to a separate container without the socket - settings are read as data and validated (the original sourced the cfg as shell) - no scan at install/boot; Stop only removes the plugin's own containers - images scanned by ID; failed images listed with the reason; each CVE counted once New: Unraid OS scan (trivy rootfs, no network, only /usr /lib /lib64 /bin /sbin mounted read-only). It covers Go binaries (docker, containerd, rclone) and Node packages incl. the Unraid API, plus whatever plugins drop under /usr. Stock 7.3.4 release files: 227 CVEs. My live 7.3.4 box with a few plugins: 368 (13 critical, nearly all with a fix upstream), mostly rclone, the Docker/containerd binaries, and plugin binaries like ctop and unbalanced. Limitation: Trivy has no Slackware support, so the ~400 OS packages and the kernel are only listed, not CVE-matched. Unraid 8 won't fix that by itself. The [announced](https://unraid.net/blog/unraid-8-announced) move to uCore means a Fedora CoreOS base, and Trivy supports Fedora CoreOS for SBOM only, not vulnerabilities ([docs](https://github.com/aquasecurity/trivy/blob/v0.76.1/docs/guide/coverage/os/coreos.md)). The "Support Fedora" request, [trivy#121](https://github.com/aquasecurity/trivy/issues/121), has been open since 2019 because Fedora has no machine-readable advisory feed. So the base OS stays the blind spot, and Lime Tech's own patch cadence is what covers it. Tested on live 7.3.4 server, feedback welcome. I'd rather merge efforts than split: PRs either way or co-maintain, your call on CA. Mainly I do not have all that much time to devote towards this but at least its moving. Your original had no licence; mine is GPL-2.0 for now, so tell me if you'd prefer something else. One small correction: the CVSS base score does include exploitability (attack vector, complexity, privileges, user interaction). What it doesn't measure is how likely exploitation is; that's EPSS and the CISA KEV list.