Conflict with UI of Synology DSM Container Manager

[galentx]

Thank you for this excellent tool!

When I perform dockcheck.sh -r -I -F and update containers, the update goes fine but the Synology is left with mangled container names in its UI and I cannot stop nor otherwise manipulate the containers in the UI. My guess is that the UI somehow latches onto a temporary name during the update process and won't let go of it. It has happened more than once, I believe specifically for containers in a 'project' (compose).

If I try to examine details of the name-mangled containers in the UI, I get a "Container undefined does not exist" message. I suspect the name the UI has latched onto is that of the now-deleted previous version (I did accept the pruning offer). Trying to stop the container elicits the same error message and trying to stop the project in the UI just displays an empty progress window and hangs.

I believe I can manually stop the containers in a terminal using the container IDs, then stop and restart the project in the UI and everything will clear up. I think that is what I did last time this happened. I'm going to postpone doing that in case there is any research I can do to help solve this. I'd be willing to try some things here to come up with a suitable patch, but I'm not sure where to start. It seems like we need a way to either 1) not latch onto old versions that are being deleted, 2) force a reset of the state the US depends upon, or maybe 3) use the same (probably undocumented) mechanism the UI uses to stop/rebuild/start the project.

Simply restarting my UI session does not resolve the issue.

Best regards,
Galen

Details:

dockcheck 0.6.6
Synology DSM 7.2.2-72806 Update 3
Container Manager 24.0.2-1535

This is what shows in the UI:

This is the dockcheck run:

$ sudo ./dockcheck.sh -r -I -F

Excluding these names:
logspout

[##################################################] 15/15

Containers on latest version:
grafana
<snip>

Containers with updates available:
1) - graylog-app  ->  url missing
2) - graylog-datanode  ->  url missing

Choose what containers to update.
Enter number(s) separated by comma, [a] for all - [q] to quit: a

Updating container(s):
graylog-app
graylog-datanode

Now updating (1/2): graylog-app
6.2: Pulling from graylog/graylog-enterprise
89dc6ea4eae2: Already exists
31436012ac5b: Already exists
2d16eb76e762: Already exists
ac81863d97cb: Already exists
26f6dfeccc10: Already exists
1b19a48937e3: Pull complete
4f4fb700ef54: Pull complete
eaebc83340ed: Pull complete
5ef9e31f5b6b: Pull complete
61992ffc99cf: Pull complete
Digest: sha256:a265fa8b0a1477135d786f5aa7d707b909c8fd9c0a8f9209a2c5c9fa240a2f0c
Status: Downloaded newer image for graylog/graylog-enterprise:6.2
docker.io/graylog/graylog-enterprise:6.2

Now updating (2/2): graylog-datanode
6.2: Pulling from graylog/graylog-datanode
89dc6ea4eae2: Already exists
cccb50d50c57: Pull complete
764fad8047e4: Pull complete
dc471ae841c3: Pull complete
6edf050e17a6: Pull complete
c52dfcf8354b: Pull complete
73ee682bb6c2: Pull complete
27500565b9e2: Pull complete
Digest: sha256:996acb6e106b6d96e371e9344c32d4b562abf2afd21e5d814362f74e112b0cb3
Status: Downloaded newer image for graylog/graylog-datanode:6.2
docker.io/graylog/graylog-datanode:6.2

Done pulling updates. Recreating updated containers.

Now recreating (1/2): graylog-app
[+] Running 3/3
 ✔ Container graylog-mongodb   Running                                                                                          0.0s
 ✔ Container graylog-datanode  Started                                                                                         20.1s
 ✔ Container graylog-app       Started                                                                                         15.0s

Now recreating (2/2): graylog-datanode
[+] Running 1/0
 ✔ Container graylog-datanode  Running                                                                                          0.0s

Would you like to prune dangling images? y/[n]: y

 Auto pruning..Deleted Images:
untagged: graylog/graylog-enterprise@sha256:796613d00384eb346f25ce98951d39cb66a2069f840d4decaba0071d2594c165
deleted: sha256:7572a82d25b0c828c13118ed142441afbb629abe0ed08185475901aa4cbdb30b
deleted: sha256:f7883c036442c29cb7c21f7bac5367aecd07b15d37d3135740b8cb276e4da2ff
deleted: sha256:8638e2481f105c28b6a9c4d61e47f4a9aa20599af54e7ba9673133aff6c44e72
deleted: sha256:cd8ec0689ae8dfdc5487adcebf271f98d2669ce505d5e34de95ce6f1f5b7d684
deleted: sha256:6d8d187b3855dc0dda3ddf845c50b63151af6b7f67e0f795a5ac6d88d88dfff9
deleted: sha256:659eccaa88f9f3c6615f6c2ba365833459c5226f9344425ce65b6058bfd7b190
untagged: graylog/graylog-datanode@sha256:e4b0b3e1064c0d5d451b3f0f450639dbca13e55393937185c4568e1c2ac69016
deleted: sha256:aa1b4c58704b2f06a1983015bb273b423e32ebdf8cd9b861e7f7494edd11483b
deleted: sha256:0fe815a3a8f64ade5ce0167f32122879b1198bdb217b643242b6576e254629fa
deleted: sha256:9db899ac2e2cb40e90e813ff808b95ead19990d5e4868c4d59be783fb0086b4b
deleted: sha256:b31f8e2dc43cbe76fb9d0f64b63c917b7784ff80e8794009697341fd94daa5ab
deleted: sha256:af2c09d699eb17ec600d2b6b713a8c491747f8cef4d2a20398ef76fd42335fd2
deleted: sha256:ef3217cc643442e6aeada82dbe8d46e13bc76bc913b41a3164c2649fafa3586e
deleted: sha256:74991e7d99f04e3abb31b4031ad74ffcec7577bdf0131407fe0c0c6c0732584d
deleted: sha256:23dbe12f0d3da4bf4fa8377017d6189e39b44414baf73bbae166df0783eec6bf

Total reclaimed space: 2.333GB

All done!

And here is the relevant portion of the docker container listing:

$ sudo docker container ls
CONTAINER ID   IMAGE                                   COMMAND                  CREATED          STATUS                    PORTS     NAMES
25c35055e2e2   graylog/graylog-enterprise:6.2          "/usr/bin/tini -- /d…"   44 minutes ago   Up 43 minutes (healthy)             graylog-app
e8fcbb57e6bd   graylog/graylog-datanode:6.2            "tini -- /entrypoint…"   44 minutes ago   Up 43 minutes                       graylog-datanode
9fea9b9d5005   grafana/grafana:latest                  "/run.sh"                5 days ago       Up 5 days                           grafana
<snip>

Finally, the container listing in json format may provide better insight. The com.docker.compose.replace labels correspond with the name mangling in the Synology UI:

[
    {
        "Command": "\"/usr/bin/tini -- /d…\"",
        "CreatedAt": "2025-06-23 12:38:26 -0500 CDT",
        "ID": "25c35055e2e2",
        "Image": "graylog/graylog-enterprise:6.2",
        "Labels": "org.label-schema.build-date=2025-06-23T10:10:20Z,org.label-schema.schema-version=1.0,org.label-schema.vcs-ref=929b6d9851572af361438cb33df8d2bcf8de2b84,org.label-schema.vcs-url=https://github.com/Graylog2/graylog-docker,com.docker.compose.oneoff=False,com.docker.compose.project.working_dir=/volume1/docker/graylog,com.docker.compose.version=2.20.1,maintainer=Graylog, Inc. <hello@graylog.com>,org.label-schema.vendor=Graylog, Inc.,org.label-schema.name=Graylog Enterprise Docker Image,org.label-schema.url=https://www.graylog.org/,com.docker.compose.config-hash=e4b1bf4648a2d4e032439e1cd1d54d34d97a59225ad26d50adfa75f5a317e098,com.docker.compose.depends_on=datanode:service_started:false,mongodb:service_started:false,com.docker.compose.project=graylog,com.docker.compose.project.config_files=/volume1/docker/graylog/compose.yaml,com.docker.compose.container-number=1,com.docker.compose.service=graylog,org.opencontainers.image.ref.name=ubuntu,org.opencontainers.image.version=22.04,com.docker.compose.image=sha256:33b7369b611d17d34e2c7bbc20febf0bf01c908cf2ccd1c2fc2c0cd1f162811d,com.docker.compose.replace=3addb7e9f2c17293554ef2e51e5cfcda4c421be33fcea7058531d5dd492400a1,org.label-schema.description=Official Graylog Enterprise Docker Image,org.label-schema.version=6.2.4",
        "LocalVolumes": "1",
        "Mounts": "01bbb4e3d2f2e1…,/volume1/docke…,/volume1/docke…",
        "Names": "graylog-app",
        "Networks": "graylog_backend,macvlan0",
        "Ports": "",
        "RunningFor": "48 minutes ago",
        "Size": "0B",
        "State": "running",
        "Status": "Up 48 minutes (healthy)"
    },
    {
        "Command": "\"tini -- /entrypoint…\"",
        "CreatedAt": "2025-06-23 12:38:19 -0500 CDT",
        "ID": "e8fcbb57e6bd",
        "Image": "graylog/graylog-datanode:6.2",
        "Labels": "com.docker.compose.config-hash=163557f122acdd197ace6ad1e32e104f1b16047c7dc9ba62dd73b175a83d85ff,org.opencontainers.image.authors=Graylog, Inc. <hello@graylog.com>,org.opencontainers.image.documentation=https://docs.graylog.org/,org.opencontainers.image.licenses=SSPL-1.0,org.opencontainers.image.source=https://github.com/Graylog2/graylog-docker,org.opencontainers.image.title=Graylog Data Node,com.docker.compose.service=datanode,com.docker.compose.version=2.20.1,org.opencontainers.image.description=Container image to run the Graylog Data Node,com.docker.compose.project=graylog,com.docker.compose.project.working_dir=/volume1/docker/graylog,com.docker.compose.replace=b77679721ed70986cfb33744259723edf5f3f8b4356f8417f24126ec8e93dfd4,org.opencontainers.image.url=https://www.graylog.org/,org.opencontainers.image.version=6.2.4,org.opencontainers.image.revision=929b6d9851572af361438cb33df8d2bcf8de2b84,com.docker.compose.container-number=1,com.docker.compose.depends_on=,com.docker.compose.image=sha256:f963c45fda45f317ad85c4bd85b6d738d404163c293630f13d71d3e682fcfe62,com.docker.compose.oneoff=False,com.docker.compose.project.config_files=/volume1/docker/graylog/compose.yaml,org.opencontainers.image.created=2025-06-23T10:06:09Z,org.opencontainers.image.ref.name=ubuntu,org.opencontainers.image.vendor=Graylog, Inc.",
        "LocalVolumes": "0",
        "Mounts": "/volume1/docke…",
        "Names": "graylog-datanode",
        "Networks": "graylog_backend",
        "Ports": "",
        "RunningFor": "48 minutes ago",
        "Size": "0B",
        "State": "running",
        "Status": "Up 48 minutes"
    },
    {
        "Command": "\"/run.sh\"",
        "CreatedAt": "2025-06-18 11:34:17 -0500 CDT",
        "ID": "9fea9b9d5005",
        "Image": "grafana/grafana:latest",
        "Labels": "maintainer=Grafana Labs <hello@grafana.com>,org.opencontainers.image.source=https://github.com/grafana/grafana",
        "LocalVolumes": "0",
        "Mounts": "/volume1/docke…,/volume1/docke…",
        "Names": "grafana",
        "Networks": "host",
        "Ports": "",
        "RunningFor": "5 days ago",
        "Size": "0B",
        "State": "running",
        "Status": "Up 5 days"
    }
]

[galentx]

Update: I used docker-compose at the command line to stop the project (rather than the individual containers):

sudo docker-compose --file /volume1/docker/graylog/compose.yaml stop

Then in the UI, I was able to do Container Manager > Project > graylog > Action > build to clean up the mangled container names in the UI. Merely performaing docker-compose stop/start at the CL was not enough to fix the UI. I should have tried docker-compose build to see if that could be a tactic in dockcheck, but I will have to wait until the next update to test this.

I will say that the Synology UI seems to have some additional layers beyond just wrapping the docker-compose commands as using the CL to stop the service generates a "container unexpectly stopped" notification for each of the containers. I'd like to find the wrapping commands the UI uses to make things play along nicer with the Synology.

[mag37]

Thank you for a thorough report and examination!

I don't have any experience with the Synology myself but have placed my trust fully in the hands of kind contributors like @yoyoma2 and @firmlyundecided .

But from what I've understood from the discussions the DSM UI does some odd layering/naming (maybe similar to Portainer?) that messes with how things usually work in the CLI.

As they put it in the README.md

Dockcheck cannot directly update containers managed in the Container Manager GUI, but it can still be used to notify you of containers with updates available.

There might be ways around and forward with this and I'm very glad you're willing to troubleshoot and help! But I don't have a way to personally test or validate things.

[galentx]

Thanks for responding. I'll continue to dig. What I've learned so far is that the executable /usr/syno/bin/synowebapi seems to process most of the UI commands. I'm closing in on the commands that will be needed to stop and start the compose project. Then I'll need to study how to fit that into the script. I can probably use the existance of /usr/syno/bin/synowebapi as a clear indication that it's running in a synology environment, though I may want to test the OS version because the API has changed a lot in the last couple of years and any solution I come up with will probably fail on previous releases.

I'll follow up when I have more.

[yoyoma2]

You can see what was previously discussed here. It appears DSM separates user managed and web GUI managed compose projects. Even if we got dockcheck.sh to work with the web managed compose projects now, synology can change things between releases and break dockcheck.sh as you have already mentioned about previous releases.

If I really wanted to use dockcheck.sh to reliably handle the updates on DSM (notifications work great) I would avoid the GUI and only use the command line like on all my other platforms. It is very interesting to see what you discover about the behind the scenes stuff DSM is doing with compose projects.

[galentx]

Thank you @yoyoma2 for pointing me to the previous discussion. I'm embarrassed that I did not research enough to find it myself.

I have not been completely idle on this issue, but haven't found enough time to fully work out a solution. I'm going to be busy with other things for a while and thought I would capture my progress to date for everyone's reference, including my own.

I have determined that UI actions can be executed at the Synology command line. The synowebapi executable (located in /usr/syno/bin/) processes API commands received through the web UI. I believe it must be run as root. Without parameters, it yields some concise usage information:

bash-4.4# synowebapi
Copyright (c) 2003-2023 Synology Inc. All rights reserved.

Usage: synowebapi
        --send cred_id <api=x> <method=x> <version=x> [<key=json_value> ...]
        --exec <api=x> <method=x> <version=x> [<runner=username> <outfile=outfile> <key=json_value> ...]
        --exec-fastwebapi <api=x> <method=x> <version=x> [<runner=username> <outfile=outfile> <key=json_value> ...]
        --emit <api=x> <method=x> <version=x> <runner=username> [<custom_event=value> <key=json_value> ...]
        --exec-emit <api=x> <method=x> <version=x> <runner=username> [<custom_event=value> <key=json_value> ...]
        --enable-lib lib1 lib2 lib3 ...
        --disable-lib lib1 lib2 lib3 ...
        -s, --slient
        --help

Executing

synowebapi -s --exec api="SYNO.Docker.Project" method=list version=1

returns json with information on all the projects (docker compose) managed through the UI:

{
   "data" : {
      <snip>
      "5403f717-fb59-44f5-8d5b-11d840e20032" : {
         "containerIds" : [ "7c39d56ce8835f59b4cb0365b4dfd816cd209ec73ca2d1976c60bbb1847981f6" ],
         "created_at" : "2025-04-30T15:22:22.187813Z",
         "enable_service_portal" : false,
         "id" : "5403f717-fb59-44f5-8d5b-11d840e20032",
         "is_package" : false,
         "name" : "diun",
         "path" : "/volume1/docker/diun",
         "service_portal_name" : "",
         "service_portal_port" : 0,
         "service_portal_protocol" : "",
         "services" : null,
         "share_path" : "/docker/diun",
         "state" : "",
         "status" : "RUNNING",
         "updated_at" : "2025-07-12T04:32:45.289797Z",
         "version" : 2
      },
      <snip>
   },
   "httpd_restart" : false,
   "success" : true
}

And the command (Note the escaped quotes on the type parameter. It is expecting json-formatted content, in this case, a string which should be in quotes.)

synowebapi -s --exec api="SYNO.Docker.Container" method=list version=1 limit=-1 offset=0 type="\"all\"" 

returns json describing all containers, whether part of a project or directly created through the UI.

{
   "data" : {
      "containers" : [
         <snip>
         {
            "Image" : "crazymax/diun:latest",
            "ImageID" : "sha256:d404f13e22b537b00d034b4719e0dcd4abcb191b1dcf35c22bc357ad7d3fde79",
            "Labels" : {
               "com.docker.compose.config-hash" : "ebc4cbaafe7ffe6591d1f470a42a9559bd69069c502eae6b963b21a2d7c5fe5d",
               "com.docker.compose.container-number" : "1",
               "com.docker.compose.depends_on" : "",
               "com.docker.compose.image" : "sha256:d404f13e22b537b00d034b4719e0dcd4abcb191b1dcf35c22bc357ad7d3fde79",
               "com.docker.compose.oneoff" : "False",
               "com.docker.compose.project" : "diun",
               "com.docker.compose.project.config_files" : "/volume1/docker/diun/compose.yaml",
               "com.docker.compose.project.working_dir" : "/volume1/docker/diun",
               "com.docker.compose.service" : "diun",
               "com.docker.compose.version" : "2.20.1",
               "diun.enable" : "true",
               "org.opencontainers.image.created" : "2024-12-19T17:20:18.783Z",
               "org.opencontainers.image.description" : "Docker image update notifier",
               "org.opencontainers.image.licenses" : "MIT",
               "org.opencontainers.image.revision" : "1ca5d37370a57965fa55979d9e9aa4e177ddf193",
               "org.opencontainers.image.source" : "https://github.com/crazy-max/diun",
               "org.opencontainers.image.title" : "Diun",
               "org.opencontainers.image.url" : "https://github.com/crazy-max/diun",
               "org.opencontainers.image.vendor" : "CrazyMax",
               "org.opencontainers.image.version" : "4.29.0"
            },
            "NetworkSettings" : {
               "Networks" : {
                  "diun_default" : {
                     "Aliases" : null,
                     "DriverOpts" : null,
                     "EndpointID" : "2dd71f8a0f03bbd01129b84fe7e1774193c59d1875c8802840a667837d3caf1a",
                     "Gateway" : "172.23.0.1",
                     "GlobalIPv6Address" : "",
                     "GlobalIPv6PrefixLen" : 0,
                     "IPAMConfig" : null,
                     "IPAddress" : "172.23.0.2",
                     "IPPrefixLen" : 16,
                     "IPv6Gateway" : "",
                     "Links" : null,
                     "MacAddress" : "02:42:ac:17:00:02",
                     "NetworkID" : "fa11bb76b788e847fe99f1b358df48ae3f54644a5704f7a5fad0d6984dabd62d"
                  }
               }
            },
            "State" : {
               "Dead" : false,
               "Error" : "",
               "ExitCode" : 0,
               "FinishedAt" : "2025-07-12T04:32:29.808377438Z",
               "OOMKilled" : false,
               "Paused" : false,
               "Pid" : 27433,
               "Restarting" : false,
               "Running" : true,
               "StartedAt" : "2025-07-12T04:32:46.502338695Z",
               "Status" : "running"
            },
            "cmd" : "diun serve",
            "created" : 1747170944,
            "enable_service_portal" : false,
            "exporting" : false,
            "finish_time" : null,
            "id" : "7c39d56ce8835f59b4cb0365b4dfd816cd209ec73ca2d1976c60bbb1847981f6",
            "image" : "crazymax/diun:latest",
            "is_ddsm" : false,
            "is_package" : false,
            "name" : "diun",
            "services" : null,
            "status" : "running",
            "up_status" : "Up 18 minutes",
            "up_time" : null
         },
         <snip>
      ],
      "limit" : 15,
      "offset" : 0,
      "total" : 15
   },
   "httpd_restart" : false,
   "success" : true
}

I think the above can provide enough information to identify containers that are being managed through the UI. The next step would be to substitute Synology-UI-aware commands for docker compose stop and docker compose up. I've got a bead on this as well.

The command

synowebapi -s --exec api=SYNO.Docker.Project method=stop_stream version=1 id="\"5403f717-fb59-44f5-8d5b-11d840e20032\""

Stops the containers of the project and returns the status in mixed formatted/unformatted text. I think that it is a blocking call that will not return until all the containers are stopped, but haven't tested with a multi-container project yet. The stdout response for the above command was:

Content-Type: text/html

 Container diun  Stopping
 Container diun  Stopped
Exit Code: 0

{
   "httpd_restart" : false,
   "success" : true
}

There is a similar start_stream method, which works the same way.

Finally, the closest equivalent of docker compose up in the UI is the project Build action. The manual says it is equivalent to docker-compose up --build --no-start, but I have found that it starts the containers, too.

Executing

synowebapi -s --exec api=SYNO.Docker.Project method=build_stream version=1 id="\"5403f717-fb59-44f5-8d5b-11d840e20032\""

yields

Content-Type: text/html

 Container diun  Created
 Container diun  Starting
 Container diun  Started
Exit Code: 0

{
   "httpd_restart" : false,
   "success" : true
}

I am beginning to agree with sentiments others have already expressed that implementing Synology-specific handling in dockcheck may be too specific a use case and open up a Pandora's box of other platforms clamoring for special logic. That said, nothing else is doing a good job of telling me that updates are even available; neither Synology's own image update checker nor diun finds all the updates that dockcheck does. The only way to force the Synology UI to update projects that itself has not found updatable is to stop the project, delete the relevant images, and do a Build, which can leave a lot of downtime. So I may eventually come back to this issue and see whether I can implement a reasonable solution in dockcheck. Either that, or abandon the Synology Container Manager UI and work exclusively at the docker command line.

[mag37]

That's a hellofa writeup @galentx ! Thank you for coming back on the matter. And nice troubleshooting/reversing.

I think this might be out of the scope for dockcheck itself, as you were leading to. Though I'm very happy to hear that dockcheck fills your needs enough to dig this deep for a solution!

If you find a way to get this to work nicely we'll surely look at possible ways to get it to work.
Maybe there could be some wrapper script or maybe even aliasing functions.

Though in this case - wouldn't it be easier to go the non-SynoUI way of having vanilla docker compose? I've seen people mention different ways of running that on the Synology, maybe it's not always possible or too resource heavy.

[galentx]

Yes, the most direct thing would be to remove all the containers from the UI and just recreate them using the docker command line. I don't think it would be a resource issue or really any different from other linux command line environments, except that Synology has their own particular flavor of linux and leaves a lot of standard (non-docker) tools out. But I prefer to not work on the Synology's command line too much as I don't want to somehow mess up all the other good things I'm using it for.

I suspect that I could get dockcheck to work by searching the Synology container list for each updatable image and, if found, perform Synology-equivalent commands instead of the standard docker commands. (If not found, then it is probably a docker command-line container anyway.) If the Synology-unique stuff lays neatly into the architecture of dockcheck, then maybe it fits into the main project. If not, then maybe a fork might be more appropriate.

Anyway, for now I will use dockcheck just to find containers that need updating and haggle with the Synology UI to make the updates happen. Hopefully I will be able to come back and work on something better in a few months.

[yoyoma2]

As a dockcheck and synology user thank you @galentx for sharing your findings!

If there is a 1 to 1 correspondence between a small number of docker commands then dockcheck could have a platform setting to call a different version of those commands on different platforms. If the logic required is different then your fork idea would indeed be needed.

I'm not sure I would use a forked version of dockcheck with different logic as the dedication and professionalism that @mag37 brings to dockcheck is not seen on many open source projects.

[mag37]

If there is a 1 to 1 correspondence between a small number of docker commands then dockcheck could have a platform setting to call a different version of those commands on different platforms.

Yeah I'm all for building in minor tweaks to make it compatible! But if it would require a lot of rewriting that may cause issues or unwanted effects on the main project - then we need to look at a different solution.

I'm not sure I would use a forked version of dockcheck with different logic as the dedication and professionalism that @mag37 brings to dockcheck is not seen on many open source projects.

That's very kind of you @yoyoma2 ! Thank you.

[galentx]

Assignment accepted. But it may be a while...

[mag37]

Assignment accepted. But it may be a while...

There's no rush and didn't mean it as a chore or to push you - rather to give you credit for what you're doing.

No requirements! I'm just thankful for your time.

[galentx]

I didn't feel pushed--I took it exactly as you intended. It's just good project management. ;-) Thanks for the credit and especially for your time on this tool.