19 minutes ago, autumnwalker said:

When I "apply update" manually from the "Docker" tab, the script does not fire

My understanding is those scripts are run by the plugin when it updates containers, standard manual update from the stock Docker page wouldn't know about any of this and bypass it all. 

1 hour ago, Kilrah said:

My understanding is those scripts are run by the plugin when it updates containers, standard manual update from the stock Docker page wouldn't know about any of this and bypass it all. 

Ah ok, I thought it would run anytime the container was started regardless of method.

 

I'll try having it auto update and see if that makes it work.

On 3/31/2025 at 9:00 AM, Kilrah said:

If you run the appdata backup plugin make sure you didn't enable autoupdate in that. 

Ahhh - that might be it. Thanks!

I've been getting a periodic cron error in my syslog, wondering if this needs an update or if I need to manually fix this? crond[3363]: failed parsing crontab for user root: Invalid frequency setting of /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

On 7/3/2025 at 9:45 PM, shwa87 said:

I've been getting a periodic cron error in my syslog, wondering if this needs an update or if I need to manually fix this? crond[3363]: failed parsing crontab for user root: Invalid frequency setting of /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1

I adjusted the frequency settings and saved and I haven't had this error since. Hopefully it sticks!

I have a bit of an issue going on. I’m not sure if it’s this plugin, or just that the plugin is seeing a different problem.

I had immich installed via compose. It was a stack. I deleted the stack. I also cleared out the app data folders associated with it.

But every day when I get the discord notification from the auto update plugin, it has these immich containers needing to be updated. These containers have been deleted.

Any idea how to fix?

5 hours ago, Wonka88 said:

Any idea how to fix?

Have you deleted the dangling images after removing the stack? When you compose down it removes the containers but the images stay there until you remove them.

3 hours ago, Kilrah said:

Have you deleted the dangling images after removing the stack? When you compose down it removes the containers but the images stay there until you remove them.

I have a weekly scheduled script to delete dangling images. I have also pruned unused volumes, and 20 other things suggested by Reddit and ChatGPT.

It looks like there are some CSS issues when the image tag is to long.

Edited August 31, 2025Aug 31 by StancuFlorin

10 hours ago, StancuFlorin said:

It looks like there are some CSS issues when the image tag is to long.

Thats a feature not a bug :)

On 8/31/2025 at 7:00 PM, Squid said:

Thats a feature not a bug :)

🤣

I came here looking to see if it had been reported - as I can't change the settings unless I zoom all the way out

Guess I'll just keep working around the feature 😅

I had a stack in docker compose manager plugin but I deleted it a while ago.

No when I select to not update all docker containers in the Auto Update Applications plugin the docker apps I had previsously installed are shown as unknown. How can I remove them?

I already uninstalled and reinstalled the plugin.

Do those containers show up on the Docker page? If so you probably didn't down the stack before deleting it so the containers are still actually there and need to be removed manually.

Edited October 2, 2025Oct 2 by Kilrah

1 minute ago, Kilrah said:

Do those containers show up on the Docker page? If so you probably didn't down the stack before deleting it so the containers are still actually there and need to be removed manually.

No. None shown. They were deleted and then the stack was deleted. There is no trace of them anywhere (normal places) and they show up as unknown in the plugin.

On 7/7/2025 at 3:47 AM, Wonka88 said:

Any idea how to fix?

I've read the plugins code and if I'm reading it correctly the problem is not the plugin it self, it is how the docker caching works.

The page is build on a foreach loop with the contents from the "getAllInfo();" function which is included by
/usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php

The Function "getAllInfo" uses "getDockerContainers" which lastly returns the docker cache with this line:

if (is_array($this::$containersCache)) return $this::$containersCache;

To fix the wrong display on previously deleted containers you can just reboot your system to clear the cache
an untested alternative might be the the usage of following command:docker builder prune

Edited October 17, 2025Oct 17 by purplehexagon

Rebooted and it fixed the issue. Thx for coming back on this

Hi!

I have a Gluetun VPN container to provide VPN access for other containers (Network type: container, Container network: gluetun). After an auto update of the Gluetun container, the dependent containers are not getting restarted. On manual update Unraid restarts this dependent containers automatically, but on auto updates this mechanism does not work. Hence, the dependent containers/services are unaccessible after an auto update. Any ideas how to fix this?

Thx!

1 hour ago, Tom7320 said:

Hi!

I have a Gluetun VPN container to provide VPN access for other containers (Network type: container, Container network: gluetun). After an auto update of the Gluetun container, the dependent containers are not getting restarted. On manual update Unraid restarts this dependent containers automatically, but on auto updates this mechanism does not work. Hence, the dependent containers/services are unaccessible after an auto update. Any ideas how to fix this?

Thx!

This is a known issue with the way the plugin functions. You can not update a container which creates a network for other containers with this plugin because you can not ensure the dependent containers will be restarted after the update. This is required by docker networking since the network references become stale, still being linked to the previous container ID for actively running dependant containers. From what I understood when I looked into this myself over a year ago, it has to do with the Docker Unraid UI page itself which maintains the functionality to trigger the restart of the dependent containers rather than a universal backend mechanism. This is why it works on the Unraid UI when manually updating and not with the plugin.

I personally deactivated the auto update for my VPN container and either update it manually or use the Backup/Restore Appdata plugin to trigger a dependent update once a week during the automated backup task maintenance. If you do the later method, you can create a start order of your VPN and dependant containers so they start in the correct order after a backup and update.

On 11/5/2025 at 7:25 AM, Tom7320 said:

Hi!

I have a Gluetun VPN container to provide VPN access for other containers (Network type: container, Container network: gluetun). After an auto update of the Gluetun container, the dependent containers are not getting restarted. On manual update Unraid restarts this dependent containers automatically, but on auto updates this mechanism does not work. Hence, the dependent containers/services are unaccessible after an auto update. Any ideas how to fix this?

Thx!

Oddly enough, I just saw this on my Community Apps feed today. Looks like there's a timely solution for us though I have not tried it yet.

On 11/5/2025 at 3:13 PM, JesterEE said:

This is a known issue with the way the plugin functions. You can not update a container which creates a network for other containers with this plugin because you can not ensure the dependent containers will be restarted after the update. This is required by docker networking since the network references become stale, still being linked to the previous container ID for actively running dependant containers. From what I understood when I looked into this myself over a year ago, it has to do with the Docker Unraid UI page itself which maintains the functionality to trigger the restart of the dependent containers rather than a universal backend mechanism. This is why it works on the Unraid UI when manually updating and not with the plugin.

Ah, ok, I understand. Would it be conceivable to implement an "update all containers expect xy" feature? This would be great!

On 11/5/2025 at 3:13 PM, JesterEE said:

I personally deactivated the auto update for my VPN container and either update it manually or use the Backup/Restore Appdata plugin to trigger a dependent update once a week during the automated backup task maintenance. If you do the later method, you can create a start order of your VPN and dependant containers so they start in the correct order after a backup and update.

I don't have the Backup Appdata plugin installed. I'll take a look at it!

9 hours ago, JesterEE said:

Oddly enough, I just saw this on my Community Apps feed today. Looks like there's a timely solution for us though I have not tried it yet.

Thx! I'll give it a try!

On 11/7/2025 at 1:29 PM, Tom7320 said:

Thx! I'll give it a try!

I can confirm that CNAF does the job for me. Thank you for putting me on the right track!!

Hello, I'd like to know if this plugin supports updating containers deployed via Docker Compose?

On 4/1/2025 at 10:51 AM, autumnwalker said:

Ah ok, I thought it would run anytime the container was started regardless of method.

 

I'll try having it auto update and see if that makes it work.

Still not working when auto update fires. Any ideas?

I had an issue with the plugin: updating non existing containers (cached),
Fixed the issue with Cursor, here is the gist of it hope it will help.


Issue Summary

The CA Update Applications plugin continues to track and report updates for Docker containers/images that no longer exist in Docker.

Root Cause

The issue is in the Dynamix Docker Manager plugin's cache system, which the CA Update Applications plugin relies on.

Cache File Location

text

/usr/local/emhttp/state/plugins/dynamix.docker.manager/docker.json

Problem

1. When containers are removed from Docker, the cache file (docker.json) is not automatically cleaned

2. The DockerTemplates->getAllInfo() function reads from this cached JSON file

3. CA Update Applications plugin calls getAllInfo() and displays all entries, including orphaned ones

4. This causes the plugin to show update notifications for containers that don't exist

Code Flow

1. CA Update Applications plugin calls: DockerTemplates->getAllInfo()

2. getAllInfo() function (in /usr/local/emhttp/plugins/dynamix.docker.manager/include/DockerClient.php) reads from the cached JSON file

3. The cache file is populated by DockerClient->getDockerContainers() but never validated against actual Docker containers

4. When containers are removed, the cache entries remain

Affected Containers (Example)

In this case, 10 GitLab Runner containers were affected:

• runner-ray-8hamr-project-1-concurrent-0-75caaa08324d5ae3-build

• runner-ray-8hamr-project-1-concurrent-0-75caaa08324d5ae3-docker-0

• runner-ray-8hamr-project-1-concurrent-0-75caaa08324d5ae3-predefined

• vibrant_chatterjee

• runner-ray-8hamr-project-1-concurrent-0-ba175883e44aa7ce-postgres-0

• bold_goodall

• runner-ray-8hamr-project-1-concurrent-0-18cf7434f7c65279-build

• runner-ray-8hamr-project-1-concurrent-0-18cf7434f7c65279-docker-0

• runner-ray-8hamr-project-1-concurrent-0-18cf7434f7c65279-predefined

• sharp_galileo

Suggested Fix

The getAllInfo() function should:

1. Validate cached entries - Check that each cached container entry still exists in Docker before returning it

2. Auto-cleanup - Remove entries from cache when containers no longer exist

3. Cache invalidation - Implement a mechanism to detect when containers are removed and invalidate/update the cache accordingly

Implementation Suggestion

In DockerClient.php, the getAllInfo() function should:

• After loading from cache, cross-reference with getDockerContainers()

• Remove any cached entries that don't exist in the current Docker container list

• Save the cleaned cache back to disk

Workaround

Manually remove orphaned entries from the cache file:

bash

# Backup first
cp /usr/local/emhttp/state/plugins/dynamix.docker.manager/docker.json /usr/local/emhttp/state/plugins/dynamix.docker.manager/docker.json.backup

# Remove orphaned entries (using PHP)
php -r "\$data = json_decode(file_get_contents('/usr/local/emhttp/state/plugins/dynamix.docker.manager/docker.json'), true); \$current = []; exec('docker ps -a --format \"{{.Names}}\"', \$current); \$current = array_map('trim', \$current); foreach(\$data as \$key => \$value) { if(!in_array(\$key, \$current)) { unset(\$data[\$key]); } } file_put_contents('/usr/local/emhttp/state/plugins/dynamix.docker.manager/docker.json', json_encode(\$data, JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES));"

Plugin Versions

• CA Update Applications: 2024.03.17 (based on file timestamp)

• Dynamix Docker Manager: (part of Unraid core)

Unraid Version

Linux 6.12.54-Unraid