I run roughly 11 different docker containers on my Unraid (now 6.8.2) installation.  

 

Since the beginning I've always had the same issue, that the Medusa container after a reboot doesn't start, and when attempting to start it manually I get the error "no such container".

 

To fix this, I always just go to container -> edit, edit a field so the "apply" button becomes available, and then click it. After this, the container works perfectly fine again.

I also tried deleting the container and re-installing it, but the same issue keeps happening.

 

Would appreciate some help in diagnosing this problem.

Not sure that will help but, as far as I have seen, deleting the container does not mean its parameters are deleted.

To be sure you are on a clean basis you should ssh and delete the "appdata/Medusa" folder after deleting the container.

Of course you will have to configure it again ... but hopefully for the last time.

21 minutes ago, whitedwarf said:

Not sure that will help but, as far as I have seen, deleting the container does not mean its parameters are deleted.

To be sure you are on a clean basis you should ssh and delete the "appdata/Medusa" folder after deleting the container.

Of course you will have to configure it again ... but hopefully for the last time.

That's the thing I thought of at first too, but after deleting the container, and re-installing it, the configuration screen was reset completely to it's default values.
No added ports, default docker network, default system paths, etc.

 

So all that it gets from the appdata folder is the medusa app configuration, but that shouldn't have any impact on the container itself, as it's just a mounted folder.

Post the docker run command. That'll help identify the problem. Not much we can do with just guessing at it.

Usually I see this with my custom network docker containers that connect to another docker as their network (I have a VPN docker, which other dockers use as their network) And the solution is also identical: edit the docker, change something and hit apply.

To fix this for startup:
Make the medusa container start after the container it depends on. This can be achieved by dragging it LOWER on the list in the WebUI (the order they are shown in is the order they start in)
 

5 minutes ago, Xaero said:

Post the docker run command. That'll help identify the problem. Not much we can do with just guessing at it.

Usually I see this with my custom network docker containers that connect to another docker as their network (I have a VPN docker, which other dockers use as their network) And the solution is also identical: edit the docker, change something and hit apply.

To fix this for startup:
Make the medusa container start after the container it depends on. This can be achieved by dragging it LOWER on the list in the WebUI (the order they are shown in is the order they start in)
 

That sounds like the same kind of setup I have. I also have 2 other docker containers on the same vpn docker-network which start before medusa, and those always start just fine.

This is the run command:

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='medusa' --net='vpn' --ip='10.10.0.5' --cpuset-cpus='0,1,4,5' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -v '/mnt/user0/Media/Series/':'/tv':'rw' -v '/mnt/cache/Downloads/':'/downloads':'rw' -v '/mnt/disks/system_ssd/appdata/medusa':'/config':'rw' -h medusa --cap-add=NET_ADMIN 'linuxserver/medusa' ;/mnt/disks/system_ssd/docker_post_startup/medusa.sh

 

2 minutes ago, xorinzor said:

That sounds like the same kind of setup I have. I also have 2 other docker containers on the same vpn docker-network which start before medusa, and those always start just fine.

This is the run command:

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='medusa' --net='vpn' --ip='10.10.0.5' --cpuset-cpus='0,1,4,5' -e TZ="Europe/Berlin" -e HOST_OS="Unraid" -e 'PUID'='99' -e 'PGID'='100' -v '/mnt/user0/Media/Series/':'/tv':'rw' -v '/mnt/cache/Downloads/':'/downloads':'rw' -v '/mnt/disks/system_ssd/appdata/medusa':'/config':'rw' -h medusa --cap-add=NET_ADMIN 'linuxserver/medusa' ;/mnt/disks/system_ssd/docker_post_startup/medusa.sh

 

--net='vpn'

Indeed;

whatever container is defined as 'vpn' needs to be started before Medusa. 
If that network isn't ready medusa might be failing to start properly. If that's the case you might start it using a user script with a delay.

Edited January 27, 20206 yr by Xaero

Just now, Xaero said:

--net='vpn'

Indeed;

whatever container is defined as 'vpn' needs to be started before Medusa.

There is no container defined as 'vpn', it's a separate docker network that I created, in which I configured a docker container as the gateway.

This way, I don't require any order in which to start the containers. Either way, the "gateway container" is ordered to start first, with 2 other containers starting after it, after which the medusa container is launched.

 

So I don't think this is the cause of the problem. I have multiple docker networks configured, none of my other containers show this issue.

1 minute ago, Xaero said:

--net='vpn'

Indeed;

whatever container is defined as 'vpn' needs to be started before Medusa.

On that basis it is worth pointing out that docker start order can be changed by dragging them into order on the Dockers tab.   In advanced view you can also add a delay before starting the next docket

2 minutes ago, itimpi said:

On that basis it is worth pointing out that docker start order can be changed by dragging them into order on the Dockers tab.   In advanced view you can also add a delay before starting the next docket

I am aware of that

EDIT:
That wouldn't make sense. I forgot that you are getting a "No Such Container" message.

Edited January 27, 20206 yr by Xaero

7 minutes ago, Xaero said:

On a failed start attempt, is there anything in the log for the Medusa container? Perhaps its trying to reach the internet, but the VPN connection hasn't been established in the VPN container?

Unfortunately not  I checked the entire syslog file, but this is the only line that stands out (anything from before the reboot has wiped itself since it's loaded in RAM).

 

Apparently the error in the log file is different then the error the WebGUI gives. The WebGUI always says "no such container", but the log file seems to say the network doesn't exist.

Jan 27 16:58:13 STORAGE rc.docker: medusa: Error response from daemon: network a2603ce63d6661af7f33861e9092ad3ac52d3ed21bf5774e1632c0f00caa3275 not found
Jan 27 16:58:13 STORAGE rc.docker: Error: failed to start containers: medusa

Which seems odd to me, because this same "--net='vpn'" parameter is used in the 2 docker containers before it, without error.

If medusa required an internet connection, the error message should be different I assume?

 

At least we're 1 step further haha.

EDIT: these are my networks.

 

NETWORK ID          NAME                DRIVER              SCOPE
2679778bf026        br0                 macvlan             local
c13b7c638210        bridge              bridge              local
5f6a3251a135        efkstack            bridge              local
ded1db5fe48f        host                host                local
9600105bc546        none                null                local
187af992fc33        vpn                 bridge              local
7e1e3d9bd667        webhost             bridge              local

 

Edited January 27, 20206 yr by xorinzor

If you move the medusa container to start before the other two containers, does it work? I'm curious to know if this is a timing thing, or if the network is getting re-created over and over with a new ID each time a docker joins the network? I'm still learning docker stuff myself haha.

7 hours ago, Xaero said:

If you move the medusa container to start before the other two containers, does it work? I'm curious to know if this is a timing thing, or if the network is getting re-created over and over with a new ID each time a docker joins the network? I'm still learning docker stuff myself haha.

the name "vpn" is just an alias that it resolves within the run command to the ID of the network. If the network were to change after the earlier 2 containers initialized I would run into the problem of those 2 not having a network connection, but they run completely fine.

 

Took me a while to learn these things about docker too, no worries  it's why I enjoy working with Unraid so much

Each time the docker service is started, it will create a new ID for each network it knows.

In the script used by Unraid the containers are automatically updated for any custom (macvlan) networks, but this does not happen for user created networks (such as your VPN network).

 

Hence the container fails to start (the message in the GUI is a bit misleading here).

When you edit the container and change/undo a setting, it will force the container to update itself and learn the new network ID.

 

43 minutes ago, bonienl said:

Each time the docker service is started, it will create a new ID for each network it knows.

In the script used by Unraid the containers are automatically updated for any custom (macvlan) networks, but this does not happen for user created networks (such as your VPN network).

 

Hence the container fails to start (the message in the GUI is a bit misleading here).

When you edit the container and change/undo a setting, it will force the container to update itself and learn the new network ID.

 

I understand that the networks and containers get new ID's, that's why they're configured using the name of the network (ie: alias) rather then ID.

 

If this however would be the reason of the problem, not just this single container should fail to start every time, but 7 others too. Since I have quite a few containers utilizing these networks, including 2 other containers using the "vpn" network, and starting at boot just fine.

Edited January 28, 20206 yr by xorinzor

I have the same issue and I didn't realize you can just modify and apply to fix it. What I was used to do is, go to settings and disable the docker and re-enable it. This might help with your 7+ containers. I only have issues with one container that requires br0 accesses. 

3 hours ago, Hans said:

I have the same issue and I didn't realize you can just modify and apply to fix it. What I was used to do is, go to settings and disable the docker and re-enable it. This might help with your 7+ containers. I only have issues with one container that requires br0 accesses. 

Disabling and re-enabling doesn't work for me, I've done that in the past for some other reasons, but this container always has had the same problem.
Still unresolved, I don't believe it has anything to do with the custom networks since all of my other containers work with custom networks just fine.