Your message dated Sun, 28 Jun 2026 04:19:01 -0400 (EDT) with message-id <[email protected]> and subject line Re: docker.io: duplicate mac address seen has caused the Debian Bug report #1138839, regarding docker.io: duplicate mac address seen to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1138839: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1138839 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: docker.io Version: 26.1.5+dfsg1-9+b13 Severity: normal Dear Maintainer, * What led up to the situation? I encountered on some systems duplicate mac addreses for docker containers. * What exactly did you do (or not do) that was effective (or ineffective)? Removing both containers (that are involved in the conflict) helps (workaround) ENvironment where this occurs: debian trixie, docker from debian (26.1.5) docker compose from debian (2.26.1-4) no static mac address or static ip address assignments in docker. single host deployment / no docker swarm containers are setup using multiple docker compose files; containers are connected to eachother via an external network definition. see also: moby github discussion: https://github.com/moby/moby/discussions/52740 I have not found a common method to reproduce this issue, but luckily I did find the issue on a testing system so I am capturing some debug logs that I can attach to this bug report later on. I would be very curious to what the cause of the issue is and what would be recommended to do to handle this issue thanks again. tobias -- System Information: Debian Release: 13.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.12.85+deb13-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages docker.io depends on: ii adduser 3.152 ii containerd 1.7.24~ds1-6+deb13u1 ii init-system-helpers 1.69~deb13u1 ii iptables 1.8.11-2 ii libc6 2.41-12+deb13u3 ii libsystemd0 257.13-1~deb13u1 ii runc 1.1.15+ds1-2+b4 ii sysvinit-utils 3.14-4 ii tini 0.19.0-3+b7 Versions of packages docker.io recommends: ii apparmor 4.1.0-1 ii ca-certificates 20250419 ii dbus-user-session 1.16.2-2 ii docker-cli 26.1.5+dfsg1-9+b13 ii git 1:2.47.3-0+deb13u1 ii needrestart 3.11-1 ii xz-utils 5.8.1-1 Versions of packages docker.io suggests: pn aufs-tools <none> pn btrfs-progs <none> pn cgroupfs-mount <none> pn debootstrap <none> pn docker-doc <none> ii e2fsprogs 1.47.2-3+b11 pn rinse <none> pn rootlesskit <none> ii xfsprogs 6.13.0-2+b1 pn zfs-fuse | zfsutils-linux <none> -- no debconf information
--- End Message ---
--- Begin Message ---Version: 28.5.2+dfsg1-1 merge 1138839 1138645 thanks Hi Tobias, Thank you for reporting this issue. The behavior you've encountered -- duplicate MAC addresses being assigned to containers on a bridge network -- is a known architectural quirk in older versions of Docker. In versions prior to 28.0, the Docker daemon (moby) derived a container's MAC address directly from its allocated IPv4 address. Under certain edge cases (such as rapid container recreation cycles, or interactions with third-party tools like Portainer), the IPAM allocator could race or reuse IPs in a way that resulted in duplicate MAC assignments on the bridge network. As noted by the maintainers in the upstream moby discussion you linked, they fundamentally resolved this starting in Docker 28.0 by dropping the IP-to-MAC derivation logic entirely. All container MAC addresses are now generated purely randomly. Since Debian has recently packaged the 28.5.x series, this bug is fixed in newer versions of the package (such as 28.5.2+dfsg1-1 and later). Once these newer versions migrate to Debian testing (Forky), this issue will be automatically resolved for you on that release. In the meantime, regarding your proposed workaround: yes, explicitly moving to static IP configurations on your Docker networks will prevent the IPAM allocator race conditions and is a solid workaround for the 26.1.5 branch in Trixie. I indeed do not feel comfortable backporting the upstream fix (https://github.com/moby/moby/pull/48808) to Trixie, as the changes are too invasive for a stable release. If you would like to try the newer version containing the fix immediately, I suggest using debian/testing, possibly in a VM. For now, I am merging your two reports and marking this as closed in the 28.x branch. Best regards, -rt
--- End Message ---
