dockerd: boot() calls uciadd() triggering reload_config which causes fw4 "redefinition of symbol 'docker_devices'" error on every boot

[gercogoge]

Package Name

dockerd

Maintainer

Gerard Ryan (G.M.Ryan) gerard@ryanr.co.uk

OpenWrt Version

25.12.4

OpenWrt Target/Subtarget

rockchip/armv8

Steps to Reproduce

1. Install dockerd and configure iptables=0 in /etc/config/dockerd
2. Ensure a firewall zone named docker already exists in /etc/config/firewall (created by uciadd() on first install)
3. Reboot OR run /etc/init.d/firewall stop && /etc/init.d/firewall start
4. Observe error: Error: redefinition of symbol 'docker_devices' during fw4 start

Actual Behaviour

After power loss or manual restart, fw4 fails to apply rules due to docker_devices symbol redefinition. The firewall remains active with no instances. Running /etc/init.d/dockerd boot triggers uciadd() → reload_config → fw4 tries to redefine already-existing nftables symbol, which fails. Removing and reinstalling dockerd packages temporarily "fixes" it because pre/post scripts recreate the firewall zone, but the issue returns after the next reboot.

Root cause: boot() in /etc/init.d/dockerd unconditionally calls uciadd(), which calls reload_config. Since dockerd starts after fw4 (S99 vs S19), fw4 already has its rules loaded. reload_config triggers fw4 to re-apply its ruleset incrementally, but fw4 uses nft -f (not nft flush ruleset first), causing redefinition of symbol 'docker_devices' because docker_devices is already defined by the previously applied ruleset.

When iptables=0, the iptables management is skipped, but uciadd() still runs unconditionally in boot(), still calling reload_config, still triggering the fw4
reload, causing the same error.

Workaround: Commenting out uciadd in boot() and cleaning up duplicate firewall zones resolves the issue.

Expected Behaviour:

boot() should either:

• Not call uciadd() if the docker firewall zone already exists, OR
• Check iptables config option before calling uciadd(), OR
• Move uciadd() to start_service() and only call it on first install, not on every boot

Confirmation Checklist

• The package is maintained in this repository.
• I understand that issues related to the base OpenWrt repository or LuCI repository will be closed.
• I am reporting an issue for OpenWrt, not an unsupported fork.

[brada4]

Lets clear some misconceptions and red herrings about fw4 and nftables....

fw4 fails to apply rules due to docker_devices symbol redefinition.

Does it disable firewall (run fw4 check) or just skips 2nd occurrence of the rule?

The firewall remains active with no instances.

That is normal with procd, there is no persistent process in fw4

fw4 to re-apply its ruleset incrementally
but fw4 uses nft -f (not nft flush ruleset first),

Nope, it always atomically wipes and recreates fw4 table, and does not touch rest of ruleset (see the first screen of ruleset.uc)

uciadd() still runs unconditionally

Yes, that is the logic problem, and your fix seems to the point here. While at it set default forward to drop in zone because 1/ there are no 2 interfaces in zone and it would not do anything 2/ if there are docketr manages any xNAT translations if at all

[gercogoge]

Thank you for the detailed explanation. Let me address your points:

Does it disable firewall or just skip?

The firewall is not fully disabled, but LAN clients lost internet access and there is blank page in LUCI (/cgi-bin/luci/admin/status/nftables). The logread showed active with no instances and the user had to remove/reinstall dockerd packages to restore connectivity. After fw4 stop && fw4 start, the error appears in stderr but nft list ruleset shows the fw4 table is present. The root cause seems to be that after unclean shutdown, nftables state is inconsistent, and uciadd() → reload_config triggers fw4 reload which fails to fully restore the ruleset due to the docker_devices conflict.

Where does define docker_devices persist if fw4 atomically recreates its table?

That's the key question. After fw4 stop, nft list ruleset still showed the docker_devices definition. Since fw4 only touches its own table (inet fw4), this definition must reside outside the fw4 table. Our setup has kmod-nft-compat installed (and iptables=0 in dockerd config). Could kmod-nft-compat or another module be injecting this definition into a global nftables scope? Or does fw4 generate define docker_devices based on the device='br-docker0' or network='docker' in the firewall zone? In our case, the firewall had a zone docker with list device 'br-docker0' — could fw4 itself define docker_devices from device names containing "docker"?
Commenting out uciadd in boot() and cleaning up the duplicate firewall zones resolved the issue completely across multiple reboots.

Here is log from my router after reboot (LAN clients lost internet already):

`root@r3s:# logread | grep -i 'firewall|fw4|docker_devices|redefinition'
Fri Jul 10 11:42:10 2026 kern.notice kernel: [ 22.254005] Bridge firewalling registered
Fri Jul 10 11:42:13 2026 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Fri Jul 10 11:42:14 2026 user.notice ucitrack: Setting up /etc/config/luci-splash reload dependency on /etc/config/firewall
Fri Jul 10 11:42:14 2026 user.notice ucitrack: Setting up /etc/config/qos reload dependency on /etc/config/firewall
Fri Jul 10 11:42:14 2026 user.notice ucitrack: Setting up /etc/config/miniupnpd reload dependency on /etc/config/firewall
Fri Jul 10 11:42:15 2026 user.notice dockerd-init: Adding firewall zone 'docker' to firewall config
Fri Jul 10 11:42:16 2026 user.notice firewall: Reloading firewall due to ifup of wan (eth0)
root@r3s:# grep -n 'docker' /etc/config/firewall
202: option src 'docker'
206: option name 'docker'
210: list device 'br-docker0'
213: option src 'docker'
216:config zone 'docker'
220: option name 'docker'
221: list network 'docker'
root@r3s:~# uci show firewall | grep -E 'zone|device|network' -A2 | grep -B2 docker

firewall.@zone[2]=zone
firewall.@zone[2].name='docker'

firewall.@zone[2].forward='REJECT'
firewall.@zone[2].output='ACCEPT'
firewall.@zone[2].device='br-docker0'
firewall.@forwarding[2]=forwarding
firewall.@forwarding[2].src='docker'

firewall.docker=zone
firewall.docker.input='ACCEPT'
firewall.docker.output='ACCEPT'

firewall.docker.network='docker'
root@r3s:# uci show firewall | grep -c "name='docker'"
2
root@r3s:# nft list ruleset | grep -n 'docker_devices'
root@r3s:# uci get dockerd.globals.iptables
0
root@r3s:# /etc/init.d/firewall status
active with no instances
root@r3s:# nft flush ruleset
root@r3s:# /etc/init.d/firewall status
active with no instances
root@r3s:# /etc/init.d/firewall start
The fw4 firewall appears to be already loaded.
root@r3s:# /etc/init.d/firewall status
active with no instances
root@r3s:# /etc/init.d/firewall stop
root@r3s:# /etc/init.d/firewall start
/dev/stdin:18:9-22: Error: redefinition of symbol 'docker_devices'
define docker_devices = { "docker0" }
^^^^^^^^^^^^^^
`

I found these workarounds for this issue:

1. Reinstall docker packages:
   apk del dockerd docker luci-app-dockerman luci-i18n-dockerman-ru docker-compose
   apk add dockerd docker luci-app-dockerman luci-i18n-dockerman-ru docker-compose
2. Disable uciadd in boot() of dockerd
   sed -i '/^boot()/,/^}/s/uciadd/# uciadd/' /etc/init.d/dockerd

[brada4]

formatting went a bit @!#€$%^&*

it does "flush table" on stop which sux. If you inject a bulletproof chain ( policy drop) that disables traffic...
openwrt/firewall4#96

define docker_devices = { "docker0" }
^^^^^^^^^^^^^^

This is VERY BAD disables firewall (on 2nd boot fw starts, then docker jucks it up and due to atomicity does not reload bad config) On the 3rd reboot no fire wall.

please polish up your pr asap, with other hand i will "increase robustness" of fw4

[brada4]

--- /rom/usr/share/firewall4/templates/ruleset.uc
+++ /usr/share/firewall4/templates/ruleset.uc
 {% for (let zone in fw4.zones()): %}
-       define {{ replace(zone.name, /^[0-9]/, '_$&') }}_devices = {{ fw4.set(zone.match_devices, true) }}
-       define {{ replace(zone.name, /^[0-9]/, '_$&') }}_subnets = {{ fw4.set(zone.match_subnets, true) }}
+       redefine {{ replace(zone.name, /^[0-9]/, '_$&') }}_devices = {{ fw4.set(zone.match_devices, true) }}
+       redefine {{ replace(zone.name, /^[0-9]/, '_$&') }}_subnets = {{ fw4.set(zone.match_subnets, true) }}
 
 {% endfor %}

[G-M0N3Y-2503]

What even changed to cause this issue?
If I recall correctly when Docker has the iptables feature enabled it expects a table to insert rules into. The addition of the table was idempotent previously if I recall correctly and was separate from other tables so never effective the others.
I remember without the table and the default rule Docker subverted all firewall and everything was open.

[brada4]

I am as puzzled as you, same code (unconditionally add device - interface - zone and fw4 not loading after with duplicate zones) is there since OpenWRT 22.