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.

Ran it and regret doing so❤️ , one could loose (principal) sleep over this, here is a good example of when apps should be approved / frozen to the ca community repo... (correlated with Grype) https://ca.unraid.net/apps/virtual-dsm-06xvzjd1or2zn9 Put mildly, a scan of virtual-dsm lights up like New Year's Eve. I doubt there's a single up-to-date piece in it: Trivy finds 138 CVEs that already have a fix, plus another 328 with no fix yet. And that's only the container. On first start it downloads Synology's DSM and runs it in a VM, and no image scanner can see inside that. Synology patches DSM without bumping version numbers, and its release notes mostly just say "Fixed security vulnerabilities" without naming a single CVE. So I unpacked the DSM it installs and looked for myself. By default that's still 7.2.2 from 2024. It ships PHP 8.1.9 compiled in December 2022 and Python 3.8.15, which is end-of-life, compiled in November 2022. Whatever Synology backports, those binaries are two years older than the fixes. Underneath it all, Synology keeps its own fork of the Linux 4.4 kernel, a branch upstream stopped supporting in 2022. Matching DSM's component versions against the CVE database gives about 4,190 unique CVEs, 3,766 of them in the kernel. Plenty of that is noise: about 600 are for GPU, Wi-Fi and Bluetooth drivers the VM doesn't even ship, and a few are for io_uring, a feature that only appeared in Linux 5.1. But sorting the real ones from the noise has to be done by hand, one CVE at a time. What you can do today: Set URL to the DSM 7.4.1 installer (https://global.synologydownload.com/download/DSM/release/7.4.1/90080/DSM_VirtualDSM_90080.pat) before the first start. It installs and boots fine, and comes with PHP 8.1.32 and OpenSSL 3.0.19, all built in 2025–2026. That cuts the critical non-kernel matches from 31 to 22. Same 4.4 kernel though. If you're already installed, run DSM's own updater. The base 7.2.2 is exposed to Synology's own SA-26:13 (remote, CVSS 9.8) until Update 9. On the container side, an upstream PR (#1406) is pending that drops the fixable CVEs from 132 to 47 with one line.

The template installs upstream's deprecated v1 (latest). Could it move to :2?Hi @CorneliousJD , thanks for maintaining this template. Following up on @froggles question (page 99): we run this container ourselves, so I checked what latest actually contains. Upstream has deprecated latest. The Docker Tags page says: "latest tag is deprecated, which is always pointing to v1. Please consider using Recommended Tags." (wiki). The security policy lists 1 and latest as deprecated and 2 as supported (SECURITY.md). The template has no tag, just louislam/uptime-kuma (template), so every install from CA gets v1. What latest contains (image built 2026-09-16, checked 2026-10-24): Uptime Kuma 1.23.17 on Debian 10, EOL 2024-06-30 (endoflife.date), with Node.js 18.20.3, EOL 2025-04-30 (endoflife.date), and OpenSSL 1.1. Because the image keeps getting rebuilt, Unraid shows it as freshly updated (Marc_G2), while the app inside stays on 1.23. What :2 contains (image built 2026-10-23): Uptime Kuma 2.5.7 on Debian 12, Node.js 22.23.4 and OpenSSL 3. The 2.0.0 stable release came out on 2025-10-20 (release), so v2 is not a beta. The current release is 2.5.7 (releases). The template maps the Docker socket for the Docker container monitor, so this container effectively has root on the host. That is one more reason to keep it on supported software. Anyone can check their own container with: docker exec UptimeKuma sh -c 'grep PRETTY /etc/os-release; node -v; grep -m1 version /app/package.json' Suggestion: change the template's Repository to louislam/uptime-kuma:2 for new installs, and add a short note to the Overview and the first post with the migration steps below. Upstream calls v1 to v2 "a major version update" with "some breaking changes" (migration guide), so existing users should switch knowingly rather than by surprise. For anyone switching now (steps from the migration guide): Stop the container and back up /mnt/user/appdata/uptimekuma. Edit the container and set Repository to louislam/uptime-kuma:2. Don't use the rootless tags: upstream says they are "not recommended for upgrading from v1 to v2" (wiki). Apply, then follow the log with docker logs -f UptimeKuma. The first start converts the heartbeat history. Upstream's own 20 monitors with 90 days of data took about 7 minutes, and "On slower hardware or with more monitors, this can take hours." Don't interrupt it: "If the migration process is interrupted, you must restore from backup and retry the upgrade." (migration guide). Until it finishes, the web page only shows Cannot GET (froggles). Check the breaking changes before relying on them: badge durations, SMTP templates (now LiquidJS, case-sensitive), and JSON backup/restore, which has been removed (migration guide). Thanks again for the template!

Thanks @dlandon on for the quick rebuild. I can confirm it: the dlandon/owncloud:latest image created 2026-10-23 ships php7.4-fpm 1:7.4.33-31, the PPA's fixed build (Launchpad). Anyone can check with docker run --rm --entrypoint dpkg-query dlandon/owncloud -W php7.4-fpm. Doing MariaDB first and then evaluating ownCloud/PHP 8 separately, without forcing anyone into a major ownCloud upgrade, sounds sensible to me. I'll also post a fix for the built-in updater's 504 in the support thread. A note on @Xaero's script: php -v can't tell a patched distro build from an unpatched one. As ownCloud puts it: "php -v reports 8.3.6 or 7.4.33 before and after the fix. Only the package version tells you whether you have the fix." (ownCloud). On Debian or Ubuntu based images, check the package instead, for example docker exec <container> dpkg-query -W 'php*-fpm' 'libapache2-mod-php*', and on Alpine docker exec <container> apk info -v | grep php. Fixed builds are listed per distro by Ubuntu and per upstream version by php.net. The same pattern beyond PHPI ran a second pass over the same 300 images as in the first post for end-of-life base systems and runtimes: Debian, Ubuntu, Alpine, CentOS, Python, Node.js, Java, .NET and OpenSSL 1.x. Each was checked against the dates on endoflife.date. 293 images were scanned, and 45 contain at least one end-of-life component (counting Python 3.10, which ended 2026-10-01). An old library inside an image is not automatically exploitable, so these are the most typical cases, not an exploit list. Build dates are the image's own Created field. Each finding can be checked with docker run --rm --entrypoint cat <image> /etc/os-release. 1. Rebuilt in 2026, but on an end-of-life base or runtime (the ownCloud pattern): UptimeKuma (louislam/uptime-kuma:latest, built 2026-09-16, Docker Hub): Debian 10, EOL 2024-06-30 (endoflife.date). Node.js 18, EOL 2025-04-30 (endoflife.date). OpenSSL 1.1 Docker-Github-Actions-Runner (myoung34/github-runner:latest, built 2026-10-23, Docker Hub): Ubuntu 20.04, standard support ended 2025-05-31 (endoflife.date). Node.js 20, EOL 2026-04-30. Python 3.8, EOL 2024-10-07 (endoflife.date) omada-controller (mbentley/omada-controller:latest, built 2026-08-31, Docker Hub): Ubuntu 20.04 (endoflife.date). OpenSSL 1.1 Odoo17 (odoo:17, built 2026-09-09, Docker Hub): bundles Node.js 12, EOL 2022-04-30 (endoflife.date) Alpine 3.18, EOL 2025-05-09, and Alpine 3.20, EOL 2026-04-01 (endoflife.date), in images rebuilt in September and October 2026: autoheal (3.18), tvheadend and htpcmanager (linuxserver), HandBrake and FileBot (jlesage) 2. Templates pinned to an old tag, frozen for good: Postgres12.5 (postgres:12.5-alpine, built 2021-01-29, Docker Hub): PostgreSQL 12, EOL 2024-11-21 (endoflife.date). Alpine 3.13, EOL 2022-11-01 GrafanaLoki (grafana/loki:master, built 2021-11-04, Docker Hub): Alpine 3.13 elasticsearch (elasticsearch:6.6.2, built 2019-03-06): Elasticsearch 6, EOL 2022-02-10 (endoflife.date), on CentOS 7. kibana (kibana:7.12.0, built 2021-03-18): CentOS 8, Node.js 14. ElasticSearch-5 (elastic/elasticsearch:5.6.14, built 2018-12-11) seafile-10 (seafileltd/seafile-mc:10.0-latest): Ubuntu 20.04, Python 3.8. DockerRegistry (registry:2): Alpine 3.18 3. Images nobody has rebuilt in years, still listed: httpbin (built 2018-10-24): Ubuntu 18.04, Python 3.6 UniFi-Video (built 2020-08-13): Ubuntu 18.04, Python 3.6, OpenSSL 1.0 couchpotato (linuxserver, built 2022-03-01): Python 2.7, EOL 2020-01-01 (endoflife.date) statping, Varken, Shadowsocks (all built 2020) and coturn, CalibreWeb, hassConfigurator (all built 2021): Alpine 3.12/3.13, EOL 2022 (endoflife.date), OpenSSL 1.1 None of these templates is marked Deprecated in the CA feed today. All three groups pass a "does the image exist and get pulled" check, and none would pass a runtime check. The ownCloud image was rebuilt within hours of being raised here, which is great. Most of the images above have nobody raising them. That's why the requests in my first post are about a scheduled runtime check, not a rebuild-date check.

We should address the elephant in the room. While Lime Tech doesn't produce Community Applications, but it knows full well that most of its users install their apps through it, as the PHP2Shell CVE report itself shows. Patching the OS's own PHP within a day (7.3.4 release notes) was good. Marking that report "Completed" (status) while CA keeps offering images built on the same vulnerable runtime is not. Pointing at template authors doesn't make a known problem go away. And this is only about images bundling end-of-life PHP, before we even get to every other vulnerability in them. Example: ownCloud, the only ownCloud server in CAhttps://ca.unraid.net/apps/owncloud-1pime4b13gmkef (image dlandon/owncloud) 418,354 downloads, 9,052 this month, first seen 2018-08-11, privileged, port 443 (all from the CA page) The other ownCloud server template, for the official owncloud:latest image, is already marked Deprecated, so anyone searching CA for ownCloud today gets this one What the image contains, pulled 2026-10-23 (built 2026-09-11). You can check any line yourself with docker run --rm --entrypoint dpkg-query dlandon/owncloud -W php7.4-fpm nginx mariadb-server and docker history --no-trunc dlandon/owncloud: Base: Ubuntu 22.04.5, in standard support until 2027 (Ubuntu release cycle) PHP: 7.4.33 via php-fpm from the third-party ppa:ondrej/php. Ubuntu 22.04 itself ships PHP 8.1 (Ubuntu). PHP 7.4 has been end-of-life since 2022-11-28 (php.net) The build recipe explicitly pins PHP 8.4 out (Pin-Priority: -1 for php8.4*, visible in docker history) ownCloud 10 "Classic", which only supports PHP 7.4 (owncloud/core#40811). ownCloud 11, which requires PHP 8.3, has been out since 2026-07-30 (release) A fresh install downloads owncloud-complete-latest, which still resolves to ownCloud 10.16.0 from 2025-11 (download.owncloud.com), although 10.16.6 is current (ownCloud) MariaDB 10.6 (held), nginx 1.18, redis, exim4, sshd, ImageMagick 6, Tailscale The published image carries the pre-fix PHP build (7.4.33-30). The PPA's fixed build (-31) appeared on 2026-10-21 (Launchpad), with a patch titled "Minimal mitigation for EOL version" (diff). A container picks it up only if it is restarted with the template's AUTO_OS_UPDATES=1 (template). Users cannot tell from CA which build they have. Even ownCloud's own official image needed Freexian's paid PHP 7.4 LTS to get the fix (ownCloud, Freexian). To be fair, the OS layer is otherwise reasonably current: a Trivy scan (trivy image dlandon/owncloud, 2026-10-23) found 0 critical issues outside the kernel headers. The problem is not neglect of the OS. It is an application kept alive on a runtime that its upstream stopped supporting four years ago. Timeline of promises and deprecations2018-08-11: dlandon/owncloud first seen in CA (CA page) 2018-12-31: the official Docker "owncloud" image is deprecated "in favor of the official owncloud/server image" (Docker Hub). CA marks its template Deprecated (CA page) 2019-11-28: PHP 7.4.0 released (php.net) 2022-11-28: PHP 7.4 end of life, last release 7.4.33 (php.net) 2022-12-02: ownCloud: "For community users we will provide a docker image with maintained PHP 7.4 free of charge", relying on "Ubuntu 20.04 will provide maintenance for PHP 7.4 till at least April 2025." (ownCloud) 2023-05-24: the issue "PHP 7.4 is past end-of-life, yet 7.4 is the only version supported" is closed 21 minutes after opening (GitHub) 2025-05: Ubuntu 20.04 standard support ends, and with it the basis of the 2022 promise (Ubuntu) 2026-04-24: ownCloud: "PHP 7.4 reached end of life, and running a production system on an unsupported runtime is a compliance problem." PHP 8.3 support for Classic is announced as pre-alpha (ownCloud blog) 2026-07-30: ownCloud Classic 11.0.0 released: "PHP 8.3 is now the minimum supported version." The built-in updater app is removed (release, announcement) 2026-09-11: the CA image is rebuilt, six weeks later, still on PHP 7.4 and with PHP 8.4 explicitly pinned out (docker history --no-trunc dlandon/owncloud) 2026-10-21: PHP2Shell (CVE-2026-109618/-109619, CVSS 9.2). "PHP 8.1 and older no longer receive updates from the PHP project" (php.net) 2026-10-22: ownCloud: "These vulnerabilities do affect OwnCloud Classic." It fixes its own images: ownCloud 11 through Ubuntu 24.04's own PHP 8.3 package, ownCloud 10 only through Freexian's paid PHP 7.4 (ownCloud, image details) 2026-10-22: Unraid 7.3.4 patches the OS's PHP (release notes) and the CVE report is marked Completed, with nothing said about CA images (report) 2026-10-23: the CA template is unchanged and still promoted, with no warning to its roughly 9,000 monthly installers (CA page) From the template's own support thread (all 19 pages read)2020-10-22, maintainer: "Because ownCloud is exposed to the Internet, it is important to update for security reasons." (page 10) 2022-06-24, maintainer: "Don't do an auto update, it will fail." (page 14) 2022-11-28: PHP 7.4 reaches end of life (php.net). The thread never mentions it, then or since 2023-01 and 2024-05: users ask for an ownCloud Infinite Scale (oCIS) version and get no answer (page 16, page 17) 2024-07 to 2025-08: no maintainer posts for 13 months while users report failures (page 17, page 18) 2025-08-04, maintainer: "Because of the Mariadb EOL cycle, it has become very difficult to build a new container using older versions of Mariadb." The image moves to Jammy and MariaDB 10.6 and drops PHP 7.2 and 7.3, but keeps 7.4. A frozen :legacy tag gets "no more updates" (post) 2025-10-26, maintainer: "The built in update hasn't worked for me for a long time." (page 19) 2026-09-12, maintainer: "Tailscale support added" (page 19). This came six weeks after ownCloud 11 on PHP 8.3 was released, and the thread doesn't mention it The end-of-life MariaDB got dealt with because it broke the build. The end-of-life PHP never broke the build, so it never got dealt with, even after a PHP 8.3 ownCloud became available, and new features keep landing on top of it. A check of the rebuild date cannot see this. How other catalogs handle thisFlathub refuses EOL runtimes: "Submissions using an end-of-life runtime, extension or baseapp will not be accepted." (Flathub) F-Droid labels publicly instead of hiding the problem, with the anti-feature "Known Vulnerability" (F-Droid) Homebrew deprecates formulae when "the software installed by the formula has outstanding CVEs": warning first, then install fails, then removal, all on published dates (Homebrew docs) Google Play hides outdated apps from new users and keeps them for existing ones: "Existing apps must target Android 15 (API level 35) or higher to remain available to new users" (Google) WordPress.org: "Security is the ultimate responsibility of the plugin developer … Should a plugin be found to have security issues, it will be closed until the situation is resolved." (WordPress) Docker Official Images separates an automatic rebuild ("as a result of its base image being updated") from maintenance (docker-library) CA itself already has Deprecated, Incompatible and Blacklisted states, and may remove apps that "lack ongoing support" (CA docs). What's missing is a definition of support that a scheduled rebuild on a free CI service cannot satisfy on its own. What I'm asking forDefine support by the runtime, not the build date. An image that ships a runtime past upstream end-of-life is not "supported", however recently it was rebuilt. Detect it automatically, and keep checking. Scan listed images on a schedule against an end-of-life table such as endoflife.date, instead of relying on a one-time check at listing. Flag it publicly where people install. Show an "End-of-life runtime / known vulnerability" badge on the CA page and in the install dialog. Notify existing users through Fix Common Problems. Apply staged, dated consequences: a warning, then hidden from new installs but kept for existing users, then Deprecated. Give longer grace periods for heavily used templates, and publish the dates. Keep a public, permanent record of flagged and delisted templates, with reasons and dates, so nothing is quietly removed or quietly kept. Show download counts for flagged templates separately, so a big number is never the reason a template stays listed. Ask template authors to re-confirm every N months that the runtime is supported. No answer starts the countdown in point 4. Allow an exception when an author can show a maintained backport. ownCloud's own image does this with Freexian (ownCloud). Such a template gets a note instead of a delisting. Scan: PHP in the 300 most-pulled CA imagesMethod: the 300 Docker repositories with the most pulls in the CA app feed (applicationFeed.json, updated 2026-10-20), latest tag each, scanned 2026-10-23 for any PHP binary or PHP web module and its version. Pull counts are Docker Hub totals for the repository, not CA installs. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net). 294 images scanned, 6 could not be pulled 31 contain PHP. 27 of them are already patched, including distro backports (Debian 8.2.35-1~deb12u1, Ubuntu 8.3.6-0ubuntu0.24.04.13) 4 still ship an unpatched or end-of-life PHP and are listed in CA as active: wallabag (wallabag/wallabag): PHP 8.1.32, image built 2025-10-07. PHP 8.1 is past end of life (php.net) NGINX---PHP-FPM (richarvey/nginx-php-fpm): PHP 8.2.7, image built 2023-06-10. Unpatched Cachet (cachethq/docker): PHP 7.3.14, image built 2020-09-21 speedtest-tracker (henrywhitaker3/speedtest-tracker): PHP 7.4.15, image built 2021-05-04 Plus the ownCloud example above (CA page), which falls outside the top 300 by pulls. Two more images on old PHP are already marked Deprecated in CA, which shows the mechanism works when someone uses it: muximux (PHP 7.4.26) and speedtest (adolfintel/speedtest, PHP 7.4.28). Anyone can reproduce a line with docker run --rm --entrypoint php <image> -v. How Lime Tech implements this is its call. It needs to be an ongoing process, not something checked once in 2018.

PHP2Shell (CVE-2026-109618/-109619) and PHP 7.4Hi @dlandon , thank you for keeping this container going all these years. I have one security issue to raise and a couple of questions. PHP2Shell is an unauthenticated remote-code-execution bug in PHP itself, disclosed on 2026-10-21 (php.net). ownCloud has confirmed it affects ownCloud Classic (ownCloud). The current image (built 2026-09-11) ships php7.4-fpm 1:7.4.33-30 from the ondrej/php PPA, which predates the fix. The PPA's fixed build, 1:7.4.33-31, has been out since 2026-10-21 (Launchpad). For anyone running this container: Restart it. With AUTO_OS_UPDATES=1, which is the default, the restart installs the fixed build. Check with: docker exec ownCloud dpkg-query -W php7.4-fpm It should show 1:7.4.33-31 or newer. If you have auto-updates off, or run the :legacy tag ("no more updates"), you won't get the fix. Please keep the container off the open Internet until you have it. Three suggestions, if you have a moment: Rebuild now so the image ships the fixed PHP. A build started after 2026-10-21 gets -31 from the same PPA (Launchpad). This can also be guarded so that a cached layer can never ship the old build again. ownCloud's own first "patched" image shipped -30 by mistake (discussion): RUN apt-get update && apt-get install -y --only-upgrade 'php7.4*' && dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php7.4-fpm)" ge 1:7.4.33-31 Point fresh installs at the current 10.16.x. owncloud-complete-latest still downloads 10.16.0 from 2025-11 (download.owncloud.com), while 10.16.6 is current (ownCloud). Consider ownCloud 11 on PHP 8.3 as the way off PHP 7.4. ownCloud 11.0.0 was released on 2026-07-30 and requires PHP 8.3 (release). Ubuntu 24.04 ships PHP 8.3 with security support, so the PPA wouldn't be needed. ownCloud's own 11.0.1 image gets this fix that way (discussion). It upgrades from 10.x, though it is a major release with breaking changes (notes). It also removes the built-in updater app, which settles the updater problem from earlier in this thread. About the built-in updater (the 504 at "Creating a checkpoint", page 19): I reproduced it and found the cause. The .php location in the shipped nginx site config has no fastcgi_read_timeout, so nginx gives up after its default of 60 seconds (nginx docs). The web updater runs each step as one request, and the checkpoint step copies the whole ownCloud tree, which easily takes longer than that on appdata. In my test, adding fastcgi_read_timeout 3600; let the full web update from 10.15.2 to 10.15.3 complete. Details for users and for the image: Workaround for existing installs (the site config in appdata is persistent): docker exec ownCloud bash -c 'f=/config/nginx/site-confs/default; grep -q fastcgi_read_timeout $f || sed -i "/fastcgi_pass php-handler;/a\ fastcgi_read_timeout 3600;" $f; nginx -t && nginx -s reload' The updater also needs to write to the whole webroot. 60_get_owncloud.sh resets it to root:abc on every start, so "Checking System" can fail until docker exec ownCloud chown -R abc:abc /config/www/owncloud is run. That has to be repeated after each restart. The command-line updater avoids nginx entirely. It took 10.15.2 to 10.15.3 in 20 seconds: printf '1\n' | docker exec -i ownCloud /sbin/setuser abc php /config/www/owncloud/updater/application.php upgrade:start Suggested image change: add the timeout line to /defaults/default, and have 40_set_config.sh add it to existing copies if it's missing. The same grep -q … || sed -i … as above does that. The updater calls the instance at its own address. With the self-signed certificate it only skips the certificate check for localhost, so opening ownCloud by LAN IP fails with cURL error 60. This matches the certificate note in the first post. Thanks again for your work.

For future reference: a post like this — “a new PHP vulnerability” with no CVE number, no source link — reads as fearmongering. JorgeB’s reply below shows how to do it properly: name the vulnerability and link the advisory. This one happened to be widely reported, but usually that’s not the case, and an unsourced warning leaves readers with nothing but uncertainty. See vagueposting.

the keyword PHP2Shell was missing

More checks to implement in the plugin:

Follow-up on the default change: it never reached existing installs, and nothing tells you. 6.10.0 changed the default ("for 'domains' and 'system' shares, change 'Enable Copy-on-write' default setting from 'No' to 'Auto'"). But the setting is only applied when a share folder is created ("Set when adding new share only"). On my server the system share shows Auto in the GUI and in its .cfg (shareCOW="auto"), yet the folder on the btrfs pool, and every subfolder in it, still carried the NOCOW (C) attribute from the old default. Nothing in the release notes or upgrade docs mentions that existing folders keep it, and the GUI gives no hint. Whether you have leftovers depends on your server's history, not its version. The NOCOW flag is only set when the folder or file is created, and only on btrfs (it does nothing on XFS). Anything migrated later (mover between array and pool, a pool replacement, a copy or restore) is written as a new file, which takes the flag of the folder it lands in rather than the one it had. On two of my three servers the system share had been moved at some point (one lived on an array disk before a new pool was added) and came out clean. Only the server where the folder had been created directly on the btrfs pool under the old default kept the flag. Check whether you have leftovers (read-only): lsattr -d /mnt/*/system /mnt/*/domainsA C in the flags means the folder is still NOCOW: ---------------C------ /mnt/nvme/system <- leftover NOCOW flag ---------------------- /mnt/nvme/domains <- fine Fixing it doesn't need "empty the share, delete it, recreate it". On a directory, the C attribute only decides what new files inherit (btrfs(5): "When set on a directory, all newly created files will inherit this attribute"), and it can be cleared on a non-empty folder. I just did it: find /mnt/nvme/system -xdev -type d -exec chattr -C {} +Afterwards lsattr -d showed no C on any of the folders. Existing NOCOW files keep their flag ("this flag can be set/unset only on empty files"). Clearing the folder only makes new files follow the configured setting. Existing files keep the flag until they are rewritten as new files. Suggestion: when a share's configured Copy-on-write setting and its folder's actual attribute disagree, Fix Common Problems could warn about it, or Unraid could offer to align it once on upgrade. That way the new default actually reaches existing installs.

This is standard Docker Compose v2 naming rather than anything the plugin does — but there's an important catch about fixing it that's worth adding. Compose names a container after its service's container_name: if set; otherwise it falls back to <project>-<service>-<n>, where <project> is the stack/project name and the trailing -1 is the replica ordinal Compose always appends. That's why your first container is clean — that service has an explicit container_name: (it happens to match the stack name) — while services 2 and 3 don't, so they get the <stack>-<service>-1 form. It's purely cosmetic; containers still reach each other by service name regardless. The fix is to add container_name: to the other services: services: app: container_name: app db: container_name: app-db cache: container_name: app-cache The catch: adding container_name: to a stack that's already running will NOT rename the existing containers on a normal restart — or even on a Compose Update / force-recreate. Compose identifies an existing container by its internal labels (project + service), not by its name, so it keeps the old name when it recreates in place. To actually apply the new names you have to do a full Compose Down, then Compose Up, so the containers are removed and created fresh. One more thing worth checking if a name ever looks "wrong" despite your file being correct: confirm which file actually created the container. docker inspect <container> --format '{{index .Config.Labels "com.docker.compose.project.config_files"}}' shows the exact compose file it came from. If that points somewhere other than the file you're editing (for example a stray docker-compose.yml sitting in a build-context directory), that other file is what's really launching the stack — and that mismatch, not the plugin, is the cause.