Docker 25.0.0

Adam

If all your containers are running, there's nothing to worry about.

Adam

It seems like this problem might be exacerbated by having additional custom containers (created outside of Enhance) within the enhance-network docker network. If you have any such containers, consider stopping them before upgrading docker. Then run them again after the upgrade.

DracoBlue

Therefore, I proposed updates controlled through the Enhance panel with individual package security enabled. After testing these packages through Enhance, they can be released for updating. Consider this, Adam.

Plesk have option:
Safe Updates
Plesk makes sure that system package updates are installed from the same repository that the packages were initially installed from. Such updates are considered safe. If you disable safe updates, your system packages manager might install updates from any repository in the system.

We recommend that you leave safe updates enabled unless you are an advanced user. Indiscriminate updates of system packages from different repositories can negatively affect the functioning of your server.

MediaServe

I've updated a couple servers so far, mainly for the OLS auto-restart. I've been seeing roles down in the server list after that for some reason. Both the two that have been updated but also others. They seem to be false positives. I had restarted orchd a couple times which didn't stop it. Once I updated the controller fully it seems to have stopped (so far at least.) Otherwise I had no additional foreign containers.

twest

MediaServe I updated control panel and didn't have any issues, and rolled out a new server that's fully updated without issues. Maybe having control panel updated saves from issues... Though I don't have any non-enhance containers running, like Adam mentioned.

Adam

The Docker team have acknowledged the issue. There is already a pull request open to fix it. Once it's released, it will be safe to upgrade Docker.

https://github.com/moby/moby/issues/47146

FabioP

Adam

Hi Adam,

Great news and thank you very much for your support which is as always exceptional and very fast, thank you.

DracoBlue

Docker 25.0.1 relased

mendozal

DracoBlue I updated today to 25.0.1, and afterwards clients started getting SMTP login errors. Even I got the same message in Roundcube when I tested it.

I double-checked everything, and it all seemed ok. Finally, a server reboot fixed the situation.

Could be just a weird coincidence, but might be worth testing this after the update.

DracoBlue

mendozal Updating isn't quite enough, you have to stop the containers then let controld restart them. If you run:

docker stop filerd ftpcd screenshotd mtacd imapcd spamcd authd authd-postgres orchd orchd-postgres

That should do it. If not, run:

docker ps | awk '{print $1}' | xargs -i docker inspect -f '{{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}} {{.Name}}' {} | sort

Each container should have a unique mac address. If any do not, stop then start that container.

Dan

mendozal Were you on 24 or 25.0 previously?

mendozal

DracoBlue All of my containers show different mac addresses, sadly I didn't check before the update.

xyzulu

mendozal All of my containers show different mac addresses,

That is normal as far as I know.

MarkD

Dan Were you on 24 or 25.0 previously?

We had the same problem this morning as @mendozal where our SMTP clients were unable to connect.
Yesterday our Docker versioin was running 25.0.0 and we did not have a problem but last night they updated to 25.0.1 and thats when the problem started.

Thanks to @DracoBlue to fix it we did not have to restart the whole server, we just restarted all of the running containers with:

docker restart $(docker ps -q)

mendozal

Dan went from 25.0 to 25.0.1

MarkD great. I wonder if it might be a good practice to do this every time docker updates, just in case.

This SMTP Issue was hard to troubleshoot at first, I thought the client had forgotten their password.

Adam

The bug is in Docker 25.0.0, it was fixed in 25.0.1. However, when Docker is updated, this might actually trigger the issue caused by 25.0.1 since all the containers would restart. The solution is to stop and then start the affected containers, one by one. This should permanently resolve the issue as they will be assigned new MAC addresses based on the container IP which ensures uniqueness.

mendozal

Adam Does a server restart also restart Docker containers? I mean, if I reboot the server, should this be taken care of?

Adam

mendozal

I could be wrong but I think you might need to explicitly stop the container for it to "forget" the old MAC address. If rebooting the server fixed it, nothing else is needed.