Docker manager deletes its shared fallback icon (question.png) when an icon-less container is removed/updated

[chodeus]

Environment

Unraid 7.3.2. The relevant code is unchanged on current master (line refs below are master).

Summary

Containers whose template has no Icon get the shared fallback path recorded as their personal icon, and removeContainer() later unlinks that recorded path — deleting question.png from the docroot for the whole system. The file only comes back on reboot (bzroot re-extract).

Chain

1. include/DockerClient.php:346 — if (empty($tmp['icon'])) $tmp['icon'] = '/plugins/dynamix.docker.manager/images/question.png'; → persisted per-container into the webui-info registry (docker.json).
2. include/DockerClient.php:894 (removeContainer()) — $iconRAM = $docroot.$info[$name]['icon']; if ($cache>=1 && is_file($iconRAM)) unlink($iconRAM); — for an icon-less container, $info[$name]['icon'] is the shared fallback, so the static file /usr/local/emhttp/plugins/dynamix.docker.manager/images/question.png gets unlinked.
3. Anything that removes/recreates such a container with cache flags triggers it. Observed in the wild via CA Docker Auto-Update updating an icon-less container: syslog Installing Updates ... 22:03:08–22:06:30, images dir mtime 22:06:02, question.png gone.

Impact / aggravator

Once the file is missing, include/DockerContainers.php:99-100 renders icon-less containers with src = question.png and onerror=this.src='(the same path)'. Since the fallback itself now 404s, the unguarded onerror reassigns the same src and the browser re-requests in a tight loop — measured ~737 requests in 5 seconds from a single open Docker page with 15 such <img>s (≈150 req/s against nginx, plus error-log churn on the /var/log tmpfs). Third-party plugins that reuse the same fallback path in their own onerror handlers (e.g. folder-view style plugins) inherit the storm.

Reproduction

1. Create a container with no Icon template value — its docker.json entry records icon: /plugins/dynamix.docker.manager/images/question.png.
2. Update or remove it through a path that passes cache flags (CA Docker Auto-Update does).
3. ls /usr/local/emhttp/plugins/dynamix.docker.manager/images/ → question.png is gone; the Docker page now 404-loops for every icon-less container until the next reboot.

Suggested fix

In removeContainer(), only unlink per-container cached icons (<name>-icon.png under images-ram/images) and never the shared default — e.g. skip the unlink when the recorded icon equals the question.png constant. Independently, guarding the JS fallback in DockerContainers.php (onerror="this.onerror=null;this.src=...") would eliminate the 404-loop failure class entirely.

[chodeus]

Also see https://product.unraid.net/p/7-3-2-dashboard-nginx-log-spam-from-stale-docker-template-fallback-icons?b=unraid-os-bugs

[nicknick923]

Hit this exact failure mode today on 7.3.2 (uptime 19 days, so no reboot in between — matches the "only comes back on reboot" note above).

Trigger for us was the CA Docker Auto-Update cron (4:30am daily), updating readarr-audiobooks, which has a dead Icon URL (https://hotio.dev/webhook-avatars/readarr.png, 404 — hotio doesn't even have a readarr repo anymore). Not icon-less per se, but a container whose icon fails to resolve/download seems to land in the same fallback path as described, and question.png was wiped both this morning and yesterday morning at the same cron time — matching the "removeContainer() during update with cache flags" chain.

Scale for us: single open Dashboard tab produced ~115,000 identical 404s for question.png logged by nginx in under a second (one persistent connection, same request id), which filled the 128MB /var/log tmpfs completely and triggered a "log filling up" alert. So the onerror-loop tightness can be much worse than 150 req/s depending on browser/HTTP2 behavior — worth weighing that into the priority of the JS-side guard (this.onerror=null) independently of the unlink fix, since that alone would have fully contained our incident even with question.png still missing.

Worked around by: restoring images/question.png from unraid/webgui@master, and fixing the dead icon URL on our container. Both are session-local though — will recur on the next auto-update of any icon-broken container until #2707/#2709 land. Happy to test either fix on this box if useful.

[junkerderprovinz]

Nick Sosinski (@nicknick923) just so you're not waiting on it, this is already fixed on master (a different PR than the ones you mentioned, #2693, merged 2026-07-27) and backported to 7.3 via #2708. Should be in the next release either way.