NetworkMode parameter uses container ID instead of name

[ryester19]

Bug description

In the Network tab underneath the Advanced Container Settings section of a created container, if you're using the "container" Network, the chosen Container sub-option reverts to "Select a container" when you save and view/edit the container settings again.

As far as I have seen, this is only a cosmetic issue, and the container is still properly configured to use the network of another container.

An additional issue that this causes is that when editing a container, you receive a "Failure Invalid network mode: invalid container format container:" error when trying to deploy. The error vanishes when you select the proper Container sub-option again.

Expected behavior
The chosen Network Container sub-option sticks between edits

Steps to reproduce the behavior:

1. Create container using the "container" network
2. Deploy
3. Edit created container
4. See error

Technical details:

• Portainer version: 1.20.0
• Docker version (managed by Portainer): 18.09.1
• Platform (windows/linux): linux x86_64 Debian GNU/Linux 9 (stretch)
• Command used to start Portainer (docker run -p 9000:9000 portainer/portainer): docker run -p 9000:9000 portainer/portainer --no-auth
• Browser: Chrome 72

[ryester19]

I have some more insight on this issue.

When creating/recreating a container in Portainer, the NetworkMode parameter in the container's hostconfig.json file is always saved to use the container ID, instead of the name (e.g. "NetworkMode": "container:543hde09...." instead of "NetworkMode": "container:vpn"). If I manually edit the hostconfig.json file to use the name of the container instead, I can see the expected behavior the next time I attempt to edit the container in Portainer.

This also solves a separate issue I was having where I wasn't able to start/restart a container that used --net=container:vpn if that 'vpn' container was recreated prior. Probably due to the fact that the container ID doesn't exist anymore

So I guess the simple(?) solution to this is to make sure that the NetworkMode parameter always saves using the container name, instead of the ID.

[ndpete]

I'm seeing this same behavior with portainer 1.22
Is there a workaround or should I be doing this a different way?

[musabgultekin]

Using "container" as network name causes issues. Docker thinks its a network_mode configuration. See: https://docs.docker.com/compose/compose-file/#network_mode . It can be a bug or undocumented restriction on docker, i don't know exactly

[ryester19]

Just tested with 1.23.0, and I don't believe the main issue has been fixed yet. I apologize that my issue description only focused on the cosmetic problems.

When editing a container immediately after creating it, the correct network container is selected in the UI by default now. However, containers are still being deployed using the ID of the network container, instead of the name. This still causes issues if the parent network container is ever recreated.

For example:

1. Create container called 'vpn'
2. Create container called 'torrent', configured to use the network of the 'vpn' container
3. Immediately recreate the 'vpn' container. Container ID changes.
4. Edit the 'torrent' container. Network Container drop-down is blank again
5. Try and recreate the 'torrent' container. You get a "Failure: no Such Container" error that references the old ID of the 'vpn' container.

[deviantony]

cc @itsconquest

[ghost]

Thanks for reporting this @ryester27 I have confirmed this behaviour, are you able to open a separate bug report for this?

[gausie]

This bug is still not fixed - recreating a container used for networking will cause all the containers using it to lose access because the id of the recreated container has changed.

[weirlive]

sooo.. this one ever getting fixed?