Portainer created container not visible in docker

[Micky]

Hi,

I've just created a new container from an image with Portainer (from my self-hosted, private registry on the same NAS) which is running fine. It can be reached using the appropriate IP-address and port. Portainer is also running containerized on the same machine.

Unfortunately this new container is not listed in the docker package in DSM unless I'm restarting docker with

synoservice --restart pkgctl-Docker

Is this sthg. others are facing, too, or is it solely my installation?

 

[one-eyed-king]

The Docker UI should pick up any created container. The Docker UI, the docker cli command, Portainer or whatever used to create containers, will use the rest-api from the docker daemon - regardless wether the tcp endpoint OR daemon socket `docker.sock` is used.

Did you by any chance remove the docker.sock endpoint while modifying the dockerd.json? When I was playing arround with the settings myself, I came ot the conclusion that the Docker UI requires it to work properly.

 

[Micky]

Do you mean the source file /var/run/docker.sock itself or the created symlink, pointing to /volume1/docker/docker.sock or the other way round.

Anyway, both parts are here and I just ran Watchtower, which is using the symlink, for updating images/container and all is fine. So the docker.sock is available.

Or did I misunderstood your question you by any chance?

 

[one-eyed-king]

I was refering to the setting in the /var/packages/Docker/etc/dockerd.json.

"hosts" : is a json array structure. I hope you didn't replace "unix:///var/run/docker.sock" with the tcp port binding, but rather added it to the list.

Iif you added the port binding, the setting for hosts should look like this:

   "hosts" : [ "tcp://{syno-ip}:2375", "unix:///var/run/docker.sock" ],

regardless, wheater you put the tcp port binding first or last.[/code]

If you didn't set the port binding, feel free to ignore the post

 

[Micky]

Hm, I did not modify dockerd.json at all at least not on the machine where Portainer is running and where I previously created the new container.

 

[one-eyed-king]

Ah, okay. Last time you asked in a different post for how to find the dockerd.json, so I thought maybee you modified it.
Well then: ignore my post in this regard

With that in mind, I have no idea what causes the Syno UI to not detect containers started from Portainer.
Hope you find a solution!

 

[Shadow]

I have to say I also experience problems with Syno Docker UI ever since I started doing more stuff via Portainer but also in particulair creating containers via SSH with sudo docker run ... commands.

But tbh I don't use the Syno Docker UI at all anymore as I've found out its too limited for me (eventough I'm a docker noob... ) .

Stays on 'loading' forever:

[/icode]

 

[one-eyed-king]

I darkly remember that I used to have problems with the Docker UI when I was localy building images. If I remember right, the UI had problems with dangling images (the one with the <none> tags). I remember the UI beeing working again after manually removing those dangling images... Mayee you guys are in the same situation? Though, this was ages ago.. I would expect them to have this fixed already...

You should get rid of them with the command: docker image rm --filter dangling=true or docker image prune -a. Though, it will not delete those images with <none> tag that are currently used by a container.

Or it might be bause Synology adds custom attributes. I know they modded the docker engine, docker cli and docker-compose. Maybee Containers created with Portainer lack these custom attributes? One could inspect an existing container that was created using the Docker UI and exactly recreate the same configuration with Portainer (don't forget to stop the UI created containeer before creating it in Portainer), then compare the output of docker container inspect ${container name or id} to reveal the differences (if any exist).

 

[Micky]

As already mentioned above, a restart of docker on Synology forces the newly created container to appear.

So I doubt it's sthg, Synology probably added to the attributes. But, nevertheless I will give it a try and check, maybe we'll find the magic behind.

 

[one-eyed-king]

So I doubt it's sthg, Synology probably added to the attributes

Synology has a bad habit of modifying the sources for their packages and force opinionated behavior on them. They customized the docker engine and introduced some new attributes, which can be seen in `docker container info`, but are not present for containers on a vanila docker-ce system.

Short version: Like I wrote all apps driving the docker engine need to go thru the rest-api. There are ways to create container by using containerd or runc directly, though they would be managed completly independend from docker.

Long version: trust me, you don't want to know or read about it

 

[BobW]

I’m experiencing the same problem! When I create or updating a container using portainer or cLi the newly or updated container doesn’t show up in the Docker GUI. I also have to restart Docker using synoservice --restart pkgctl-Docker and then they show up again. This is happening mostly with my containers using the macvlan network.

And for for the past few weeks I keep getting these errors and then restarting or rebuilding the container is the only option to get them started.

Start container baikal failed: {"message":"mkdir /var/run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/0a930b67fc8397e4be43d4baa7a9faf4ceba8b3f530e18f7ba6765d1df367ad4: file exists: unknown"}.
30-11-2020 08:17:20

Error
Start container baikal failed: {"message":"mkdir /var/run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/0a930b67fc8397e4be43d4baa7a9faf4ceba8b3f530e18f7ba6765d1df367ad4: file exists: unknown"}.
30-11-2020 08:16:18

Error
Start container baikal failed: {"message":"mkdir /var/run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/0a930b67fc8397e4be43d4baa7a9faf4ceba8b3f530e18f7ba6765d1df367ad4: file exists: unknown"}.

Start container baikal failed: {"message":"driver failed programming external connectivity on endpoint baikal (f42c6ced4d460be4bc8f4ffa9565a3d07e5757a6f28bc9081101685f62e37081): Bind for 0.0.0.0:44301 failed: port is already allocated"}.
30-11-2020 06:09:27
Error

Start container baikal failed: {"message":"driver failed programming external connectivity on endpoint baikal (877f2ce189f3a0a004c574f9bd0b3661ee0c8588a6e162c7c20f5d87a21565e3): Bind for 0.0.0.0:44301 failed: port is already allocated"}.
30-11-2020 06:09:22
Error

Start container piwigo-wp failed: {"message":"driver failed programming external connectivity on endpoint piwigo-wp (0a250bbdcb3f21eafa908bb6a153e7ed18ec3bb382499f61034e46eb3ad31949): Bind for 0.0.0.0:8006 failed: port is already allocated"}.
30-11-2020 00:50:31

 

[Shadow]

This is happening mostly with my containers using the macvlan network.

I think Syno Docker UI doesn't even understand a macvlan network... I also created a macvlan network, but it doesn't show at all in Syno Docker UI.

I simply stopped using Syno Docker UI. Why bother with it...

 

[BobW]

I think Syno Docker UI doesn't even understand a macvlan network... I also created a macvlan network, but it doesn't show at all in Syno Docker UI.

I simply stopped using Syno Docker UI. Why bother with it...

Yes that’s true I mostly use CLi or portainer but that doesn’t take a the problem that my containers won’t start.

 

[one-eyed-king]

If you are interessted in the cause, this german Synology forum post (and the follow up posts) Docker Port Konflikt - Port is already allocated - wie löschen? covers the issue.

 

[BobW]

If you are interessted in the cause, this german Synology forum post (and the follow up posts) Docker Port Konflikt - Port is already allocated - wie löschen? covers the issue.

The kernel bug, yes I know about the cause. But I’m looking for a solution or workaround for now until Synology update the kernel problem in DSM. It is very frustrating that everyday one of my containers won’t start because of some port conflict that isn’t really there. Sometimes simply restarting the Docker helps but on some occasions I have to change the port to something else for it to start again, very annoying!

 

[one-eyed-king]

I am currious to see how this one plays out.

So far the only effective workarround I am aware of is to restart the NAS. I can image it is not the solution you are looking for... but you can share your joy with Synology by repeatedly raising issue tickets regarding this issue They are the ones responsible to provide a permanent fix.

 

[BobW]

Maybe I should just migrate/move everything to a Debian VM Box.
As far as I know the latest Linux distro’s has already fixed the bug. And at least you can update Docker to the latest version.

 

[one-eyed-king]

The idea isn't that terrible actualy, as a bonus you would also get rid of the bug that prevents Portainer to create docker-compose stacks using the ui and the bug that effectivly makes swarm mode unusable. Just make sure to follow the official docker installation instructions, otherwise you might end up using the os packages instead.

 

[BobW]

Thanks for the tips! I will think about it and make an inventory.

Install Docker Engine on Debian

Learn how to install Docker Engine on Debian. These instructions cover the different installation methods, how to uninstall, and next steps.

docs.docker.com

 

[one-eyed-king]

one more thing: I would definitly go with a headless minimal installation to not waste any ram or cpu time on gui centric things or unncessary services.