I am having the same issue my upgrade to 7.0.0. All of my containers are labelled as 3rd party. Two of them were out of date, and after updating they were fixed. Though, the others are currently update to date.

From reading the thread it looks like the current best solution is to stop all running containers incorrectly labelled as 3rd party. Then for each of those containers do "Add Container" -> Select the template for it -> Make an innocuous change -> "Save" (? or Apply ?) -> Delete the old 3rd party container. ?

No other easier way than doing this for each container?

2 hours ago, topunraid said:

A 3rd Party container cannot be edited

Correct but if it was form the CA the template exist.

 

Remove the docker. (image included...)

then go to add container and select the template that was the docker.
make a edit and apply.

Thanks primeval_god

as 3rd party dockers due to this error are still template files with the dockers name on unraid...

 

 

Force update in advanced view should work also, as this rebuilds a new container from the image (even if image is unchanged).

Force update is not available for 3rd Party

You can try forcing the update via CLI, I use this myself as part of a custom script to make bulk updates to templates.
 

# where $CONTAINER_NAME is the container name
# e.g. /usr/bin/php -q /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/update_container radarr

/usr/bin/php -q /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/update_container $CONTAINER_NAME

If there is a template in place it should update with the required flags... worth a try (ensure you have backups first)

This worked, perfect!

7 hours ago, tjb_altf4 said:

You can try forcing the update via CLI, I use this myself as part of a custom script to make bulk updates to templates.
 

# where $CONTAINER_NAME is the container name
# e.g. /usr/bin/php -q /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/update_container radarr

/usr/bin/php -q /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/update_container $CONTAINER_NAME

If there is a template in place it should update with the required flags... worth a try (ensure you have backups first)

 

Awesome the let make a user scirpt to force update teh docker ps list:

 

#!/bin/bash

# Get the list of running Docker container names
CONTAINER_NAMES=$(docker ps --format '{{.Names}}')

# Check if there are any running containers
if [[ -z "$CONTAINER_NAMES" ]]; then
    echo "No running containers found."
    exit 0
fi

# Iterate over each container name and run the update command
for CONTAINER_NAME in $CONTAINER_NAMES; do
    echo "Updating container: $CONTAINER_NAME"
    /usr/bin/php -q /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/update_container "$CONTAINER_NAME"
done

echo "Update process completed."

 

3 minutes ago, bmartino1 said:

 

Awesome the let make a user scirpt to force update teh docker ps list:

 

#!/bin/bash

# Get the list of running Docker container names
CONTAINER_NAMES=$(docker ps --format '{{.Names}}')

# Check if there are any running containers
if [[ -z "$CONTAINER_NAMES" ]]; then
    echo "No running containers found."
    exit 0
fi

# Iterate over each container name and run the update command
for CONTAINER_NAME in $CONTAINER_NAMES; do
    echo "Updating container: $CONTAINER_NAME"
    /usr/bin/php -q /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/update_container "$CONTAINER_NAME"
done

echo "Update process completed."

 

although I wouldn't change your script as its better for progress, update_container can actually accept an array and runs a little quicker that way e.g. update_container "radarr sonar" 

On 1/14/2025 at 4:07 AM, primeval_god said:

Ok that makes sense. Then you really would have to remove and re-add from the saved template.

We need auto start configuration for 3rd Party container.

9 hours ago, Kation said:

We need auto start configuration for 3rd Party container.

if you want it to autostart, create a template for it and manage like any other Unraid native container.

Another option is to add the following flag to the container run cmd, but autostart won't be manageable in UI
--restart=unless-stopped
More info: https://docs.docker.com/engine/containers/start-containers-automatically/#use-a-restart-policy

 

Edited January 16, 20251 yr by tjb_altf4

3 hours ago, tjb_altf4 said:

if you want it to autostart, create a template for it and manage like any other Unraid native container.

Another option is to add the following flag to the container run cmd, but autostart won't be manageable in UI
--restart=unless-stopped
More info: https://docs.docker.com/engine/containers/start-containers-automatically/#use-a-restart-policy

 

It's a big trouble to recreate every container if docker broken. So use a command line from a txt file is easy to recreate.

 

And I use a custom plugin to create a network, it never show in template dropdown list.

And this plugin has a bug case docker hangs while starting if any container use --restart=unless-stopped

#!/bin/bash

# Define the path to the Unraid Docker Manager update script
UPDATE_SCRIPT="/usr/local/emhttp/plugins/dynamix.docker.manager/scripts/update_container"

# Log start
echo "[$(date)] Starting Docker update process..."

# Check if the Unraid update script exists
if [ ! -f "$UPDATE_SCRIPT" ]; then
    echo "Unraid Docker Manager update script not found at $UPDATE_SCRIPT."
    echo "Falling back to manual update process for all containers."
fi

# Get the list of running Docker containers
CONTAINER_NAMES=$(docker ps --format '{{.Names}}')
if [[ -z "$CONTAINER_NAMES" ]]; then
    echo "No running containers found."
    exit 0
fi

# Initialize arrays for batch processing
VALID_CONTAINERS=()
MISSING_TEMPLATES=()

# Populate the arrays
for CONTAINER_NAME in $CONTAINER_NAMES; do
    TEMPLATE_PATH="/boot/config/plugins/dockerMan/templates-user/my-${CONTAINER_NAME}.xml"

    if [ ! -f "$TEMPLATE_PATH" ]; then
        echo "Template missing for container: $CONTAINER_NAME"
        MISSING_TEMPLATES+=("$CONTAINER_NAME")
    fi

    # Add the container to the valid update list
    VALID_CONTAINERS+=("$CONTAINER_NAME")
done

# Batch update using Unraid Docker Manager script
if [ ${#VALID_CONTAINERS[@]} -gt 0 ]; then
    if [ -f "$UPDATE_SCRIPT" ]; then
        echo "Updating containers in batch: ${VALID_CONTAINERS[*]}"
        /usr/bin/php -q "$UPDATE_SCRIPT" "${VALID_CONTAINERS[@]}"
        echo "[$(date)] Batch update completed for containers: ${VALID_CONTAINERS[*]}"
    else
        echo "Unraid Docker Manager script not available. Falling back to manual updates."
    fi
fi

# Manual fallback updates (if Unraid script isn't available)
if [ ! -f "$UPDATE_SCRIPT" ]; then
    for CONTAINER_NAME in "${VALID_CONTAINERS[@]}"; do
        echo "Processing container manually: $CONTAINER_NAME"

        echo "Stopping container: $CONTAINER_NAME..."
        docker stop "$CONTAINER_NAME"

        echo "Pulling the latest image for $CONTAINER_NAME..."
        docker pull "$(docker inspect --format='{{.Config.Image}}' "$CONTAINER_NAME")"

        echo "Starting container: $CONTAINER_NAME..."
        docker start "$CONTAINER_NAME"

        echo "[$(date)] Manual update completed for $CONTAINER_NAME."
    done
fi

# Log missing templates
if [ ${#MISSING_TEMPLATES[@]} -gt 0 ]; then
    echo "[$(date)] Containers with missing templates:"
    for CONTAINER in "${MISSING_TEMPLATES[@]}"; do
        echo "- $CONTAINER"
    done
    echo "Please check or recreate the missing templates."
fi

# Log end
echo "[$(date)] Docker update process finished."

Made a user script one can run to update this if encounter again. And to notify which 3rd party are missing temples...
as you would need to remove the docker for to add container and make a template with the docker name and same docker image to bring it back to unraids control.

Edited January 19, 20251 yr by bmartino1
Data - Typo in script

Hi, I have a container created by Pterodactyl before 7.0 and I had it set to auto start, how can I disable it now?

On 1/23/2025 at 7:31 PM, PilaScat said:

Hi, I have a container created by Pterodactyl before 7.0 and I had it set to auto start, how can I disable it now?

? web UI > docker

-- toggle auto start off...
Advance toggle edit wait?

27 minutes ago, bmartino1 said:

? web UI > docker

-- toggle auto start off...
Advance toggle edit wait?

There isn't, in its place there is 3rd party

7 minutes ago, PilaScat said:

There isn't, in its place there is 3rd party

then its via the termianl and docker commands..
 

docker update --restart=no <my-container>

Example:
docker stop <docker name>
docker remvoe <docker name>
docker run -<extra comands...> <docker name>

You have a setting for it to auto start....

 

19 hours ago, bmartino1 said:

then its via the termianl and docker commands..
 

docker update --restart=no <my-container>

Example:
docker stop <docker name>
docker remvoe <docker name>
docker run -<extra comands...> <docker name>

You have a setting for it to auto start....

 

Thank you, I need only this...

I know this is old, but I still have a problem with this and really can't believe this was never acknowledged as a serious regression in the 7.0 upgrade.

I have very old docker containers that now show as 3rd Party, as per the OP. I want to RUN these old containers as they are. I do not want to force an update or remove and re-add them. How do I get back all the management options THAT WERE REMOVED BY THE UNRAID UPGRADE PROCESS?

Thanks for the help.

3 hours ago, buzzra said:

I know this is old, but I still have a problem with this and really can't believe this was never acknowledged as a serious regression in the 7.0 upgrade.

I have very old docker containers that now show as 3rd Party, as per the OP. I want to RUN these old containers as they are. I do not want to force an update or remove and re-add them. How do I get back all the management options THAT WERE REMOVED BY THE UNRAID UPGRADE PROCESS?

Thanks for the help.

run this script.

which if your afected by false Unrad CA 3rd party docker. this will fix them...

If you just run a termainl docker run line then the webui is correct and its is 3rd party...

there was no save template before teh upgraded process they were sitting in memory that was erased at a reboot. This is why its importat to make a new teamplate and fill in teh data to construct the docker run with unraid web ui and not just run the docker run line in unraid termainl... Nothign was saved otherwise and since it was apart of the /var docker sok run stack it was noticed and flaged as 3rd party...

6 hours ago, bmartino1 said:

run this script.

which if your afected by false Unrad CA 3rd party docker. this will fix them...

If you just run a termainl docker run line then the webui is correct and its is 3rd party...

there was no save template before teh upgraded process they were sitting in memory that was erased at a reboot. This is why its importat to make a new teamplate and fill in teh data to construct the docker run with unraid web ui and not just run the docker run line in unraid termainl... Nothign was saved otherwise and since it was apart of the /var docker sok run stack it was noticed and flaged as 3rd party...

And that script will fix the 3rd party problem WITHOUT updating the docker? I want to continue to run the same old ass version that I am currently running that was working fine before the upgrade to 7.0.1.

1 hour ago, buzzra said:

And that script will fix the 3rd party problem WITHOUT updating the docker? I want to continue to run the same old ass version that I am currently running that was working fine before the upgrade to 7.0.1.

unknown. depends on what runnign how its runnign and if the update script sees a docker update as we esentail are telling unraids update script to redownlad the docker. To many varbles to say each way. Make a bug report other wise...

https://forums.unraid.net/bug-reports/

really depends on how urnaids update web ui script works and whats is sent to the update script.

if you docker is set to lattest for example then nope your out of luck its whatever github/docker hub have marekd as lattest. if the docker is set to taht verion then only that verion will be pullled and ran through the update script...

docker ps and other docker coamnds and other data that don't belong to this post would be needed as this would require other back and forth.

On 9/5/2025 at 1:29 PM, buzzra said:

I know this is old, but I still have a problem with this and really can't believe this was never acknowledged as a serious regression in the 7.0 upgrade.

I have very old docker containers that now show as 3rd Party, as per the OP. I want to RUN these old containers as they are. I do not want to force an update or remove and re-add them. How do I get back all the management options THAT WERE REMOVED BY THE UNRAID UPGRADE PROCESS?

Thanks for the help.

If they're showing as 3rd party, then its because the template within /config/plugins/dockerMan/templates-user doesn't exist.

Was this ever deleted by you, or how did you install the container? Manually via the command line and a docker run command? 3rd Party means that management of the container (editing, autostarting etc) is handled by the 3rd party that created it. Even prior to 7.0, without the template you couldn't Edit the container even though the option showed up there.

On 9/6/2025 at 9:06 PM, Squid said:

If they're showing as 3rd party, then its because the template within /config/plugins/dockerMan/templates-user doesn't exist.

Was this ever deleted by you, or how did you install the container? Manually via the command line and a docker run command? 3rd Party means that management of the container (editing, autostarting etc) is handled by the 3rd party that created it. Even prior to 7.0, without the template you couldn't Edit the container even though the option showed up there.

This is simply wrong, all my templates are there and merely the upgrade to 7.0.1 made all my containers "3rd party" except new ones I create.

Edited September 17, 2025Sep 17 by Jamie Owens

On 9/5/2025 at 11:09 PM, buzzra said:

And that script will fix the 3rd party problem WITHOUT updating the docker? I want to continue to run the same old ass version that I am currently running that was working fine before the upgrade to 7.0.1.

It will not, so far as i know it is not possible to fix the issue short of recreating the containers.

On 9/7/2025 at 12:06 AM, Squid said:

If they're showing as 3rd party, then its because the template within /config/plugins/dockerMan/templates-user doesn't exist.

Was this ever deleted by you, or how did you install the container? Manually via the command line and a docker run command? 3rd Party means that management of the container (editing, autostarting etc) is handled by the 3rd party that created it. Even prior to 7.0, without the template you couldn't Edit the container even though the option showed up there.

6 hours ago, Jamie Owens said:

This is simply wrong, all my templates are there and merely the upgrade to 7.0.1 made all my containers "3rd party" except new ones I create.

Yes it is wrong. The reason for the third party status is mentioned much earlier in this thread. Recent versions of Dockerman use a container label "net.unraid.docker.managed=dockerman" to determine which containers it created/manage. The absence of this label indicates a third party container, and containers that were created in older versions of unRAID dont have the label. So far as i know there is no way to add or change the label of a container once it is created, the only option is to recreate it.

Recreating a container generally should not be a big deal, docker containers are meant to be ephemeral not long lived fixtures like VMs. Recreating a container does not necessarily entail an update or a version change. If your goal is running specific version of a container, relying on never recreating the container is not a particularly good method. You should be using a tagged version of the image that does not change for instance "linuxserver/ffmpeg:7.1.1" instead of "linuxserver/ffmpeg:latest". If the image you are using does not provide specific tagged versions you can create your own by using the docker cli to create your own tag of the image version you are currently using. Ideally you should be able to pull officially tagged versions from docker hub at any time, but for safety and if you create your own tags you should take care to ensure you dont delete the specific image from your system. Thing to avoid are the checkbox when removing containers that asks if you want to also remove the image, and commands or plugins that cleanup unused images. Additionally for your own tagged images creating a second tag for archival can save you if you accidentally choose the remove image option when deleting a container.

Note: there are a small number of containers, specifically from linuxserver.io that do update the application within the container whenever it is restarted. Tagging will not help with these, but neither will never recreating a container.

On 9/17/2025 at 8:37 AM, primeval_god said:

It will not, so far as i know it is not possible to fix the issue short of recreating the containers.

Yes it is wrong. The reason for the third party status is mentioned much earlier in this thread. Recent versions of Dockerman use a container label "net.unraid.docker.managed=dockerman" to determine which containers it created/manage. The absence of this label indicates a third party container, and containers that were created in older versions of unRAID dont have the label. So far as i know there is no way to add or change the label of a container once it is created, the only option is to recreate it.

Recreating a container generally should not be a big deal, docker containers are meant to be ephemeral not long lived fixtures like VMs. Recreating a container does not necessarily entail an update or a version change. If your goal is running specific version of a container, relying on never recreating the container is not a particularly good method. You should be using a tagged version of the image that does not change for instance "linuxserver/ffmpeg:7.1.1" instead of "linuxserver/ffmpeg:latest". If the image you are using does not provide specific tagged versions you can create your own by using the docker cli to create your own tag of the image version you are currently using. Ideally you should be able to pull officially tagged versions from docker hub at any time, but for safety and if you create your own tags you should take care to ensure you dont delete the specific image from your system. Thing to avoid are the checkbox when removing containers that asks if you want to also remove the image, and commands or plugins that cleanup unused images. Additionally for your own tagged images creating a second tag for archival can save you if you accidentally choose the remove image option when deleting a container.

Note: there are a small number of containers, specifically from linuxserver.io that do update the application within the container whenever it is restarted. Tagging will not help with these, but neither will never recreating a container.

now that sometime has passed thought i'd share the docker update command to add the label. But didn't say anything until now due to issues it would have caused. as THIS IS NOT A FIX!!!

docker ps to get the docker name for the next command...
docker update -l net.unraid.docker.managed=dockerman <my-container>
@primeval_god this is the docker update command, as you were not aware per post... But is not the underlying issue...

This can and will break other parts of emhttp due to a missing template file and done't restore functionality... this will give the docker that needed label without redownloading or initiating a docker pull. Then a refresh of the docker web ui would show it...

BUT! I can't stress enough to RECREATE THE DOCKER via UNRAID!

or run the Script noted earlier in the forum:
https://forums.unraid.net/topic/178736-docker-container-now-shows-3rd-party/page/2/#findComment-1514066

UNLESS YOU USED DOCKER CLI to connect unraid dockerman dockers via docker cli for networks... like a VPN... in which case your using UNRID docker temptles and docker networks ALL WRONG!

using docker cli to add multiple networks due to missed commands and docker network communications has also been known to flag them out as unraids dockerman is no longer maintaining the docker...
*this is the only instance where updating the label May fix it... as its cosmetic not file corruption and files not in correct areas...

But thats a issues if docker networks, and linux alias for docker names the container template applies this lable by default and it can be seen with docker template authoring.
re applying the label may not fix the 3rd party state if this is network container related due to users using CLI things to other docker network and not making a proper internal docker network to bridge them with user defined networks...

This is where i would recommend using compose plugin and use a compose file to properly setup unraid docker and there networks for cross talk especial with VPNs...
https://docs.docker.com/reference/compose-file/networks/
(Why docker cli pull a docker into 3rd party even though a label exist is due to how emhttp is no longer maintaining its network THIS IS NOT A BUG!) its a template limitation of Docker run and how docker run connects to docker networks...

and is proff of docker network misuse... read the docker networking docks and setup a "INTERNAL docker network with docker alais... things that can be added to the unraid template extra parameters! or in a compose file...
https://docs.docker.com/engine/network/

Edited January 6Jan 6 by bmartino1