Your message dated Mon, 01 Dec 2025 06:40:13 -0500
with message-id <[email protected]>
and subject line Re: Bug#1118056: podman: `podman network create` refuses
network range if in use by the host
has caused the Debian Bug report #1118056,
regarding podman: `podman network create` refuses network range if in use by
the host
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.)
--
1118056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1118056
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: podman
Version: 5.4.2+ds1-2+b1
Severity: normal
Dear Maintainer,
Prior to Trixie/5.4.2, I had Podman bridged network defined as a subset
of the IP range of my local physical network. This was configured via
the CNI backend (following [1], my write-up was [2]). With the upgrade
to Trixie, my CNI-backed network definitions were removed and my
containers would not start.
In repairing this, I discovered that 5.4.2 (with the Netavark backend)
detects and prevents you configuring a Podman network that uses a subnet
already available on the host. Assuming local network 192.168.1.0/24:
$ podman network create --opt mode=unmanaged --interface-name=br0 --subnet
192.168.1.0/24 podbr0
Error: subnet 192.168.1.0/24 is already used on the host or by another config
A workaround is to define it with a temporary subnet and then edit the
JSON in /etc/containers/networks afterwards.
This has been fixed by 5.6.2 (sid's package).
I'm reporting it because I think it's useful to record the versions that
are broken/fixed (I haven't found this reported upstream yet) but also
because I would like to suggest backporting a fix (once
identified/isolated) should be considered.
[1]
https://blog.carroarmato0.be/2020/05/08/exposing-podman-container-on-the-network/
[2] https://jmtd.net/log/podman_network/
-- System Information:
Debian Release: 13.0
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500,
'stable-security'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, ppc64el
Kernel: Linux 6.12.38+deb13-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages podman depends on:
ii conmon 2.1.12-4
ii golang-github-containers-common 0.62.2+ds1-2
ii init-system-helpers 1.68
ii libc6 2.41-12
ii libgpgme11t64 1.24.2-3
ii libseccomp2 2.6.0-2
ii libsqlite3-0 3.46.1-7
ii libsubid5 1:4.17.4-2
ii netavark 1.14.0-2
ii runc 1.1.15+ds1-2+b4
Versions of packages podman recommends:
ii buildah 1.39.3+ds1-1+b6
ii ca-certificates 20250419
ii containers-storage 1.57.2+ds1-1+b2
ii criu 4.1.1-1
ii dbus-user-session 1.16.2-2
ii libcriu2 4.1.1-1
ii passt 0.0~git20250503.587980c-2
ii slirp4netns 1.2.1-1.1
ii tini 0.19.0-3+b3
ii uidmap 1:4.17.4-2
Versions of packages podman suggests:
ii containernetworking-plugins 1.1.1+ds1-3+b17
ii docker-compose 2.26.1-4
ii iptables 1.8.11-2
-- Configuration Files:
/etc/cni/net.d/87-podman-bridge.conflist [Errno 13] Permission denied:
'/etc/cni/net.d/87-podman-bridge.conflist'
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 5.6.2+ds1-1
Thank you Jonathan for reporting the below! That very useful
documentation, much appreciated.
I'd like to close this issue as this doesn't seem like something we
would change in a stable debian release. Let me know if there is a
better way to work with this in debbugs.
Best,
-rt
Jonathan Dowland <[email protected]> writes:
> Package: podman
> Version: 5.4.2+ds1-2+b1
> Severity: normal
>
> Dear Maintainer,
>
> Prior to Trixie/5.4.2, I had Podman bridged network defined as a subset
> of the IP range of my local physical network. This was configured via
> the CNI backend (following [1], my write-up was [2]). With the upgrade
> to Trixie, my CNI-backed network definitions were removed and my
> containers would not start.
>
> In repairing this, I discovered that 5.4.2 (with the Netavark backend)
> detects and prevents you configuring a Podman network that uses a subnet
> already available on the host. Assuming local network 192.168.1.0/24:
>
> $ podman network create --opt mode=unmanaged --interface-name=br0 --subnet
> 192.168.1.0/24 podbr0
> Error: subnet 192.168.1.0/24 is already used on the host or by another
> config
>
> A workaround is to define it with a temporary subnet and then edit the
> JSON in /etc/containers/networks afterwards.
>
> This has been fixed by 5.6.2 (sid's package).
>
> I'm reporting it because I think it's useful to record the versions that
> are broken/fixed (I haven't found this reported upstream yet) but also
> because I would like to suggest backporting a fix (once
> identified/isolated) should be considered.
>
>
> [1]
> https://blog.carroarmato0.be/2020/05/08/exposing-podman-container-on-the-network/
> [2] https://jmtd.net/log/podman_network/
--- End Message ---
