netavark: cannot start second container: iptables: Chain already exists
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug Description
I can start only one root container.
When I create or start the second root container I get this error message:
ERRO[0000] Starting some container dependencies
ERRO[0000] "netavark: code: 1, msg: iptables: Chain already exists.\n"
Error: error starting some containers: internal libpod error
I use nftables. When I restart nftables and all this extra stuff which podman puts into the firewall is gone I can create the second container.
My current /etc/containers/network/podman1.json looks like this:
{
"name": "podman1",
"id": "85ab0240733e50b6c3c1d497f5c882501bbb6d7476f66f5fa4cc9a4a0d11bc04",
"driver": "bridge",
"network_interface": "podman1",
"created": "2022-04-02T14:39:19.181441699+02:00",
"subnets": [
{
"subnet": "10.90.0.0/16",
"gateway": "10.90.0.1"
},
{
"subnet": "fdc2:4ba9:85d4:f3c1::/64",
"gateway": "fdc2:4ba9:85d4:f3c1::1"
},
{
"subnet": "2a02:xxx::/96"
}
],
"ipv6_enabled": true,
"internal": false,
"dns_enabled": true,
"ipam_options": {
"driver": "host-local"
}
}
Steps to reproduce the issue:
see above
Describe the results you received: I get the described error message from netavark regarding an already existing iptables chain.
Describe the results you expected: I expect to be able to start more than one root container.
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version:
Client: Podman Engine
Version: 4.0.2
API Version: 4.0.2
Go Version: go1.18beta2
Built: Thu Mar 3 15:56:09 2022
OS/Arch: linux/amd64
Output of podman info --debug:
host:
arch: amd64
buildahVersion: 1.24.1
cgroupControllers:
- cpuset
- cpu
- io
- memory
- hugetlb
- pids
- misc
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.0-2.fc36.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.1.0, commit: '
cpus: 8
distribution:
distribution: fedora
variant: silverblue
version: "36"
eventLogger: journald
hostname: bat.localdomain
idMappings:
gidmap: null
uidmap: null
kernel: 5.17.1-300.fc36.x86_64
linkmode: dynamic
logDriver: journald
memFree: 3739787264
memTotal: 8211226624
networkBackend: netavark
ociRuntime:
name: crun
package: crun-1.4.4-1.fc36.x86_64
path: /usr/bin/crun
version: |-
crun version 1.4.4
commit: 6521fcc5806f20f6187eb933f9f45130c86da230
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
path: /run/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: false
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.2.0-0.2.beta.0.fc36.x86_64
version: |-
slirp4netns version 1.2.0-beta.0
commit: 477db14a24ff1a3de3a705e51ca2c4c1fe3dda64
libslirp: 4.6.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.3
swapFree: 16800276480
swapTotal: 16800276480
uptime: 1h 16m 24.72s (Approximately 0.04 days)
plugins:
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- docker.io
- quay.io
store:
configFile: /etc/containers/storage.conf
containerStore:
number: 4
paused: 0
running: 4
stopped: 0
graphDriverName: overlay
graphOptions:
overlay.mountopt: nodev,metacopy=on
graphRoot: /var/mnt/data/containers/storage
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "false"
Supports d_type: "true"
Using metacopy: "true"
imageCopyTmpDir: /var/tmp
imageStore:
number: 40
runRoot: /var/run/containers/storage
volumePath: /var/mnt/data/containers/storage/volumes
version:
APIVersion: 4.0.2
Built: 1646319369
BuiltTime: Thu Mar 3 15:56:09 2022
GitCommit: ""
GoVersion: go1.18beta2
OsArch: linux/amd64
Version: 4.0.2
Package info (e.g. output of rpm -q podman or apt list podman):
podman-4.0.2-1.fc36.x86_64
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
Yes/No
Additional environment details (AWS, VirtualBox, physical, etc.):
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 17 (4 by maintainers)
I still use my workaround. I could not find any other way to disable the rules which netavark brings in.
A good solution would be like in docker where the user can disable any firewall changes by docker completely.