Great plugin, saves a lot of boring maintenance work 😊
I noticed that you have the option "Delay in days before updating applications:" for plugins, but not for docker containers.
Is there a special reason for this?
I personally would find it quite valuable to have this option for Docker as well.
If a "bad" image is published I would assume that this would be fixed within a couple of days, so having a delay of 2 or 3 days would be fine.

On 12/7/2025 at 3:15 AM, kintrupf said:

Great plugin, saves a lot of boring maintenance work 😊
I noticed that you have the option "Delay in days before updating applications:" for plugins, but not for docker containers.
Is there a special reason for this?
I personally would find it quite valuable to have this option for Docker as well.
If a "bad" image is published I would assume that this would be fixed within a couple of days, so having a delay of 2 or 3 days would be fine.

literally came to this support thread to +1 this too. I think it is a fantastic feature that would help for containers. I don't need bleeding edge, i need stability. So in my use case, a delay of x days helps with that. Yes, I also use the appdata backup plugin so can always revert - but id rather not have to do that if its as easy as just waiting for an update to be 'stable' prior to updating the container.

thank you to the original devs for this plugin

On 12/6/2025 at 12:15 PM, kintrupf said:

Great plugin, saves a lot of boring maintenance work 😊
I noticed that you have the option "Delay in days before updating applications:" for plugins, but not for docker containers.
Is there a special reason for this?
I personally would find it quite valuable to have this option for Docker as well.
If a "bad" image is published I would assume that this would be fixed within a couple of days, so having a delay of 2 or 3 days would be fine.

I'd like to +1 this comment as well. A "Delay in days before updating applications" function for docker containers (as is already available for plugins) would be very much appreciated.

Hi, has anyone found a fix to this problem, if not I would like to raise an issue, where is the best place to do this?

When a container network type is set to "container" (e.g a container networked via gluetun VPN)

and the host network container (gluetunvpn) is set to auto update, when it auto updates the

client network containers (e.g container going through gluetunvpn) is not rebuilt until you click in the docker tab in unraid.

Container stays down infinitely until visiting unraid webgui and heading into docker.

In short, any containers networked via a container set to auto update do not rebuild automatically after auto update

Edited February 11Feb 11 by rory13

i deleted all immich containers but they're still showing up in the "docker auto update settings"-list in this plugin for some reason. any ideas on why?

Go to Apps-> Previous Apps and remove things you don't want anymore.

On 2/21/2026 at 11:52 PM, Kilrah said:

Go to Apps-> Previous Apps and remove things you don't want anymore.

the containers i see in the "docker auto update settings"-list in this plugin is not in the "previous apps" list. but i deleted everything there, but the containers (immich) still show up in the plugin.

Edit: added diagnostics if anyone could help out. and a screenshot showing the immich "containers" in the plugin that shouldnt be there.

unraid-diagnostics-20260226-1655.zip

Edit 2: apparently a reboot of the server is needed to clear the list in the plugin of containers no longer present. so for anyone coming here with the same issue, reboot the server.

Edited April 9Apr 9 by kakburken

On 2/11/2026 at 2:24 AM, rory13 said:

Hi, has anyone found a fix to this problem, if not I would like to raise an issue, where is the best place to do this?

When a container network type is set to "container" (e.g a container networked via gluetun VPN)

and the host network container (gluetunvpn) is set to auto update, when it auto updates the

client network containers (e.g container going through gluetunvpn) is not rebuilt until you click in the docker tab in unraid.

Container stays down infinitely until visiting unraid webgui and heading into docker.

In short, any containers networked via a container set to auto update do not rebuild automatically after auto update

install the "User Scripts" plugin

change the VPN_CONTAINER variable to match the name of yours

change the CONTAINERS variable to match the name(s) of the containers (separated by a space) connected to GLUETUN_VPN.

this script checks if your containers can reach google.com cloudflare.com or amazon.com

if they cannot, they get restarted. it also by default sends you an Unraid notification

#!/bin/bash
# VPN Container Watchdog Script (Multi-Site Check with Discord Notifications)
# Designed for Unraid to monitor containers running through a VPN (e.g., Gluetun)

# -----------------------------------------------------------------------------
# CONFIGURATION
# -----------------------------------------------------------------------------
# The name of your VPN provider container
VPN_CONTAINER="gluetun-vpn"

# List of dependent containers to check (separated by spaces)
CONTAINERS="prowlarr sonarr radarr"

# List of sites to check for connectivity (Google, Cloudflare, Amazon/AWS)
TEST_URLS=("https://google.com" "https://cloudflare.com" "https://amazon.com")

# How long to wait for recovery in total (900s = 15m)
MAX_WAIT_SECONDS=900

# How often to check for recovery status
POLL_INTERVAL_SECONDS=30

# Path for the lock file to prevent concurrent runs
LOCKFILE="/tmp/vpn_watchdog.lock"

# -----------------------------------------------------------------------------
# FUNCTIONS
# -----------------------------------------------------------------------------

# Send to Unraid's notification system (which forwards to Discord)
send_notification() {
    local SUBJECT="$1"
    local MESSAGE="$2"
    local IMPORTANCE="${3:-normal}"
    
    # Log to the User Scripts log
    echo "$(date): [$IMPORTANCE] $SUBJECT: $MESSAGE"
    
    if [ -f /usr/local/emhttp/webGui/scripts/notify ]; then
        /usr/local/emhttp/webGui/scripts/notify -e "VPN Containers Watchdog" -s "$SUBJECT" -d "$MESSAGE" -i "$IMPORTANCE"
    fi
}

# Check if a specific container is running
is_container_running() {
    [ "$(docker inspect -f '{{.State.Running}}' "$1" 2>/dev/null)" == "true" ]
}

# Test internet connectivity via curl inside a specified container
check_connectivity() {
    local CONTAINER="$1"
    
    # If container isn't running, it's definitely not connected
    if ! is_container_running "$CONTAINER"; then
        return 1
    fi
    
    for URL in "${TEST_URLS[@]}"; do
        if docker exec "$CONTAINER" curl -sf --head "$URL" --connect-timeout 5 > /dev/null; then
            return 0 # Success
        fi
    done
    return 1 # Failure
}

# Poll until all specified containers are running AND have internet connectivity
check_container_up() {
    local TARGET_CONTAINERS=("$@")
    local WAIT_TIME=0

    echo "$(date): [INFO] Polling for connectivity: ${TARGET_CONTAINERS[*]} (Max ${MAX_WAIT_SECONDS}s)"

    while [ $WAIT_TIME -lt $MAX_WAIT_SECONDS ]; do
        local STILL_OFFLINE=0
        for CONTAINER in "${TARGET_CONTAINERS[@]}"; do
            if ! check_connectivity "$CONTAINER"; then
                STILL_OFFLINE=$((STILL_OFFLINE + 1))
            fi
        done

        if [ $STILL_OFFLINE -eq 0 ]; then
            echo "$(date): [INFO] All polled containers are ONLINE and RUNNING."
            return 0
        fi

        echo "$(date): [INFO] Still waiting for recovery ($STILL_OFFLINE containers remaining)... ($WAIT_TIME/${MAX_WAIT_SECONDS}s)"
        sleep $POLL_INTERVAL_SECONDS
        WAIT_TIME=$((WAIT_TIME + POLL_INTERVAL_SECONDS))
    done

    return 1
}

# Robust restart/rebuild for Unraid
restart_container() {
    local NAME="$1"
    local STATUS=$(docker inspect -f '{{.State.Status}}' "$NAME" 2>/dev/null)

    # If it's NOT running, use Unraid's native rebuild
    # This recreates the container from XML, fixing stale --network=container:xxx IDs
    echo "$(date): [INFO] Performing Unraid XML-based rebuild for $NAME..."
    if [ -f /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/rebuild_container ]; then
        /usr/bin/php /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/rebuild_container "$NAME"
    else
        echo "$(date): [ERROR] Unraid rebuild script not found! Attempting standard start."
        docker start "$NAME"
    fi
}

# -----------------------------------------------------------------------------
# MAIN EXECUTION
# -----------------------------------------------------------------------------

# 0. PREVENT CONCURRENT RUNS
if [ -e "$LOCKFILE" ]; then
    echo "$(date): [INFO] Another instance is running or a stale lock exists. Exiting."
    echo "$(date): [INFO] To manually remove the lock: rm $LOCKFILE"
    exit 0
fi

# Create lock and ensure cleanup on exit
touch "$LOCKFILE"
trap 'echo "$(date): --- End VPN Watchdog ---"; rm -f "$LOCKFILE"' EXIT

echo "$(date): --- Starting VPN Watchdog ---"
echo "$(date): [INFO] Starting VPN Containers Watchdog check..."

# 0. VALIDATION: Ensure configured containers actually exist
VALID_CONTAINERS=()
for CONTAINER in $CONTAINERS; do
    if docker inspect "$CONTAINER" >/dev/null 2>&1; then
        VALID_CONTAINERS+=("$CONTAINER")
    else
        echo "$(date): [WARN] Container '$CONTAINER' not found. Removing from check list."
        send_notification "WARNING: Invalid Container Configuration" "The container '$CONTAINER' was not found on this system and will be skipped." "warning"
    fi
done
CONTAINERS="${VALID_CONTAINERS[*]}"

# If no valid containers left, exit early
if [ -z "$CONTAINERS" ]; then
    echo "$(date): [ERROR] No valid containers to monitor. Exiting."
    exit 1
fi

# 1. PRE-CHECK: Is VPN container itself running?
echo "$(date): [INFO] Checking if $VPN_CONTAINER is running..."
if ! is_container_running "$VPN_CONTAINER"; then
    echo "$(date): [WARN] $VPN_CONTAINER is NOT running. Polling for up to ${MAX_WAIT_SECONDS}s..."
    
    WAIT_TIME=0
    while ! is_container_running "$VPN_CONTAINER" && [ $WAIT_TIME -lt $MAX_WAIT_SECONDS ]; do
        sleep $POLL_INTERVAL_SECONDS
        WAIT_TIME=$((WAIT_TIME + POLL_INTERVAL_SECONDS))
        echo "$(date): [INFO] Still waiting for $VPN_CONTAINER... ($WAIT_TIME/${MAX_WAIT_SECONDS}s)"
    done
    
    if ! is_container_running "$VPN_CONTAINER"; then
        send_notification "CRITICAL: VPN Container Down" "$VPN_CONTAINER is STILL not running after ${MAX_WAIT_SECONDS}s. Watchdog is aborting." "alert"
        exit 1
    fi
    send_notification "INFO: VPN Recovered" "$VPN_CONTAINER has started. Proceeding with checks." "normal"
else
    echo "$(date): [INFO] $VPN_CONTAINER is running. Proceeding..."
fi

# 2. MAIN CHECK: Identify offline or stopped containers
OFFLINE_CONTAINERS=()

for CONTAINER in $CONTAINERS; do
    echo "$(date): [INFO] Checking status and connectivity for: $CONTAINER"
    
    # Check if container is running
    STATUS=$(docker inspect -f '{{.State.Status}}' "$CONTAINER" 2>/dev/null)
    
    if [ "$STATUS" == "running" ]; then
        if ! check_connectivity "$CONTAINER"; then
            echo "$(date): [WARN] $CONTAINER is Running but has no internet."
            OFFLINE_CONTAINERS+=("$CONTAINER")
        else
            echo "$(date): [INFO] $CONTAINER is ONLINE."
        fi
    elif [ -n "$STATUS" ]; then
        echo "$(date): [WARN] $CONTAINER is in status '$STATUS'. Adding to recovery list."
        OFFLINE_CONTAINERS+=("$CONTAINER")
    else
        echo "$(date): [INFO] $CONTAINER does not exist. Skipping."
    fi
done

# 3. ACTION: If containers are offline: Notify, then Restart/Rebuild
if [ ${#OFFLINE_CONTAINERS[@]} -gt 0 ]; then
    # Send the notification first
    send_notification "WARNING: VPN Containers Offline" "Issues detected in: ${OFFLINE_CONTAINERS[*]}. Attempting recovery." "warning"
    
    # Perform the recovery actions
    for CONTAINER in "${OFFLINE_CONTAINERS[@]}"; do
        restart_container "$CONTAINER"
    done

    # 4. RECOVERY VERIFICATION: Use the refined polling function
    check_container_up "${OFFLINE_CONTAINERS[@]}"
    
    # Final status check for notification summary
    SUCCESSFUL=()
    FAILED=()
    
    for CONTAINER in "${OFFLINE_CONTAINERS[@]}"; do
        if check_connectivity "$CONTAINER"; then
            SUCCESSFUL+=("$CONTAINER")
        else
            FAILED+=("$CONTAINER")
        fi
    done
    
    # Prepare and send summary notification
    if [ ${#FAILED[@]} -eq 0 ]; then
        send_notification "SUCCESS: VPN Containers Recovered" "The following containers are back online: ${SUCCESSFUL[*]}" "normal"
    elif [ ${#SUCCESSFUL[@]} -eq 0 ]; then
        send_notification "CRITICAL: VPN Recovery Failed" "The following containers are STILL OFFLINE: ${FAILED[*]}" "alert"
    else
        send_notification "WARNING: Partial VPN Recovery" "Recovered: ${SUCCESSFUL[*]}. STILL OFFLINE: ${FAILED[*]}" "warning"
    fi
fi

echo "$(date): [INFO] VPN Containers Watchdog check complete."

Edited March 13Mar 13 by fazi13

my own version of the above script I wrote a couple years ago. this one does not require you to specifically name containers that are behind your gluetun vpn, as it can resolve those automatically. it also uses a much more robust means of checking if a container is up as not all containers include ping or curl.

it lacks the discord functionality, but also includes some smarts to defer doing this if you're using the ca backups plugin so it doesn't try to restart a container that's down on purpose for backups.

#!/bin/bash

echo "[$(date)]  Checking containers directly linked to GluetunVPN..."

TEST_URL="https://1.1.1.1"
TEST_HOST="1.1.1.1"
TEST_PORT="443"
TIMEOUT=5

GLUETUN_NAME="GluetunVPN"
GLUETUN_ID=$(docker inspect -f '{{.Id}}' "$GLUETUN_NAME" 2>/dev/null)

if [ -z "$GLUETUN_ID" ]; then
echo " Failed to get ID of $GLUETUN_NAME. Is it running?"
exit 1
fi

# --- Detect Unraid "Appdata Backup" plugin activity -----------------------------------------
# We avoid interfering with backups by NOT starting/restarting containers while a backup runs.
is_appdatabackup_running() {
# 1) Any process mentioning the plugin path/name
if ps auxww | grep -Eqi '/usr/local/emhttp/plugins/appdata\.backup|appdata\.backup|ca\.backup2'; then
# Filter out the grep itself; if anything else matches, it's running.
if ps auxww | grep -Ei '/usr/local/emhttp/plugins/appdata\.backup|appdata\.backup|ca\.backup2' | grep -vq 'grep'; then
return 0
fi
fi

# 2) Any tar/rsync currently writing to "Appdata Backup/ab_..." (common output naming)
if ps auxww | grep -Eqi 'tar .*Appdata Backup/ab_|rsync .*Appdata Backup/ab_'; then
if ps auxww | grep -Ei 'tar .*Appdata Backup/ab_|rsync .*Appdata Backup/ab_' | grep -vq 'grep'; then
return 0
fi
fi

return 1
}

if is_appdatabackup_running; then
echo " Appdata Backup appears to be running. Skipping ALL start/restart actions to avoid interference."
echo "[$(date)]  Check complete (no changes made due to backup activity)."
exit 0
fi
# -------------------------------------------------------------------------------------------

echo " Checking for stopped containers that should use $GLUETUN_NAME network..."
for container in $(docker ps -a --format '{{.Names}}'); do
RUNNING=$(docker inspect -f '{{.State.Running}}' "$container" 2>/dev/null)
NET_MODE=$(docker inspect -f '{{.HostConfig.NetworkMode}}' "$container" 2>/dev/null)

if [ "$RUNNING" = "false" ] && [[ "$NET_MODE" == "container:$GLUETUN_ID" ]]; then
echo " Starting stopped container: $container"
docker start "$container" > /dev/null 2>&1
if [ $? -eq 0 ]; then
echo " Started $container"
else
echo " Failed to start $container"
fi
echo
fi
done

# Helper: test network inside a container with multiple fallbacks
container_net_ok() {
local c="$1"

# curl
docker exec "$c" sh -lc "command -v curl >/dev/null 2>&1 && curl -s --head --max-time $TIMEOUT '$TEST_URL' >/dev/null 2>&1"
[ $? -eq 0 ] && return 0

# wget
docker exec "$c" sh -lc "command -v wget >/dev/null 2>&1 && wget -q --spider --timeout=$TIMEOUT '$TEST_URL' >/dev/null 2>&1"
[ $? -eq 0 ] && return 0

# busybox wget (common in minimal images)
docker exec "$c" sh -lc "command -v busybox >/dev/null 2>&1 && busybox wget -q --spider -T $TIMEOUT '$TEST_URL' >/dev/null 2>&1"
[ $? -eq 0 ] && return 0

# /dev/tcp (bash feature; may not exist, but cheap to try)
docker exec "$c" sh -lc "command -v bash >/dev/null 2>&1 && bash -lc 'echo >/dev/tcp/$TEST_HOST/$TEST_PORT' >/dev/null 2>&1"
[ $? -eq 0 ] && return 0

return 1
}

for container in $(docker ps --format '{{.Names}}'); do
NET_MODE=$(docker inspect -f '{{.HostConfig.NetworkMode}}' "$container" 2>/dev/null)

if [[ "$NET_MODE" == "container:$GLUETUN_ID" ]]; then
echo " Checking: $container (linked to $GLUETUN_NAME)"

if container_net_ok "$container"; then
echo " $container is good"
else
echo " Network failure in $container — restarting..."
docker restart "$container" > /dev/null
[ $? -eq 0 ] && echo " Restarted $container" || echo " Restart failed!"
fi
echo
fi
done

echo "[$(date)]  Check complete."

Edited March 27Mar 27 by bstone108

Why not just use the mentioned CNAF container? It's also just a bash script wrapped in a container:

GitHub

containernetwork-autofix/entrypoint.sh at main · buxxdev/...

ContainerNetwork AutoFix (CNAF) - Automatically recreates dependent containers when master container restarts - buxxdev/containernetwork-autofix

Simplicity, size, most containers are a lot bigger than they need to be while this script is only a couple of kilobytes. It also execute faster and has much less overhead.

Container options are good and all, but if you can do it from outside using much fever resources that’s always a good thing.

I would also like to throw in a vote for container update delay like plugins has.

On 5/15/2026 at 8:38 AM, shiftylilbastrd said:

I would also like to throw in a vote for container update delay like plugins has.

Ditto on this... would like the convenience of docker auto-updates but with the ability to delay the update to catch issues brought up by the community (e.g. ai slop).

+1 for docker auto-updates. Its articles like this from Wired, A Hacker Group Is Poisoning Open Source Code at an Unprecedented Scale, that unfortunately make requests like this almost necessary - very much appreciate all real devs and the dedication they impart!

Edited June 7Jun 7 by Lehoi.handia

I have a few questions reading this thread. Is @Squid still maintaining this plugin?

Like mentioned above, +1 for delay on docker auto updates.

Another feature I would like to see is an exclude selector. In my case I have one container I don't want to auto update. To do this I have to disable "Update All Docker Applications", and manually select all except for the one I would like to exclude. When I add new container I need to manually enable the "Auto Update" for those containers. An exclude option would solve this.