[BUG] After applying IPTables and restart of Synology - no container will start

[gerstemann]

After updateing to 29.0.1 of docker and applying new iptables, no container will get back online. I do get the following error messagen:

Start container speedtest-tracker-dsl failed: {"message":"failed to set up container networking: failed to create endpoint speedtest-tracker-dsl on network speedtest-tracker-dsl_default: Unable to enable DIRECT ACCESS FILTERING - DROP rule:  (iptables failed: iptables --wait -t raw -A PREROUTING -d 172.18.0.2 ! -i docker-41d47e9e -j DROP: iptables v1.8.3 (legacy): can't initialize iptables table `raw': Table does not exist (do you need to insmod?)\nPerhaps iptables or your kernel needs to be upgraded.\n (exit status 3))"}. --

Any help?

[telnetdoogie]

This error means the iptables_raw modules aren't loaded. you can try to run sudo install_iptables_modules.sh on its own to resolve this. If it continues to fail after a system reboot, then you may have a problem that several others have seen where the kernel modules aren't correctly loading on service startup. You can try to load them in a scheduled task, or you can modify the dockerd.json and add iptables: false , however you won't have the same isolation or networking protection that docker normally provides.

[gerstemann]

Is it somehow possible to restore the old iptables?

[telnetdoogie]

Is it somehow possible to restore the old iptables?

Not sure I totally understand the question. There are no 'old versions' of the modules, and iptables itself is still the same. Somewhere at docker v28.x it began depending on 'raw' tables in iptables, which isn't present on synology without the modules being added.

You can remove the additional iptable_raw kernel modules that were placed in:

/lib/modules/iptable_raw.ko
/lib/modules/ip6table_raw.ko

...but based on your errors, these modules aren't loaded anyway. You can see loaded / active modules by running:

sudo lsmod | grep table_raw

if those two modules don't show, then they're not loaded (I suspect this is the issue based on the error)

If they do show, you can remove them with sudo rmmod iptable_raw and sudo rmmod ip6table_raw after stopping ContainerManager.

without those modules you'd need to run an older version of docker, or disable iptables support from docker as I suggested above.

To 'start over' you can just uninstall and reinstall ContainerManager from DSM Package manager and then delete the raw modules from the above location.

[gerstemann]

It is now unfortunatelly a different issue.

I went back to 27.5.1 and now the containers are starting, but are not reachable. after restoring back to 24.0.2 the went back online.

[maartenjd]

Hello. I had been applying the update-script as my nextcloud-aio was requiring higher API-versions. I then also experienced that my containers were starting but could not be reached anymore. I spent hours trying different docker and docker-compose versions. The issue commenced as off 24.0.3. Up to 24.0.2 there was no issue. Then I realised that I had not/never enabled the firewall of my Synology NAS. Once I had enabled it, everything was OK again. Might that be the reason of your issue, @gerstemann ?

Thanks for the good work, @telnetdoogie !

DS-218+ NAS with DSM 7.3.2-86009

~$ docker version
Client:
 Version:           29.1.3
 API version:       1.52
 Go version:        go1.25.5
 Git commit:        f52814d
 Built:             Fri Dec 12 14:48:47 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.1.3
  API version:      1.52 (minimum version 1.44)
  Go version:       go1.25.5
  Git commit:       fbf3ed2
  Built:            Fri Dec 12 14:51:14 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.0
  GitCommit:        1c4457e00facac03ce1d75f7b6777a7a851e5c41
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker-compose version
Docker Compose version v5.0.1

[gerstemann]

Nope, enabled the firewall and back on 29.1.3 no success.

[telnetdoogie]

27.5.1 and now the containers are starting, but are not reachable. after restoring back to 24.0.2 the went back online.

@gerstemann in order to downgrade versions once you're on 28 or 29, you'd have to go back to the factory as you did, and then upgrade using this script to upgrade to your specific version (27.5.1 is a good choice that doesn't need new modules).

That way the script it won't do anything with iptables modules installs or downloads. You can also try --skip-iptables, however I'm 95% sure that won't fix your issue. I've seen the error many times, and it's a result of the modules not being loaded at service startup. It's making me think it's a problem with your specific start script - however some users just have this problem, and there's not been a resolution for it. It's Synology weirdness.

I don't have access to your same NAS device or installation, so once you've restored to the synology ContainerManager, please paste here the contents of your default /var/packages/ContainerManager/scripts/start-stop-status script - it's possible that your DSM has a different file, and if so I might be able to tweak the script so it'll work for you as well.

I'll be traveling internationally so I don't think I'll be able to solve this in the next week, however if you can paste the contents here, I'm sure I'll play with it while I'm traveling and make some progress during my downtime.

[telnetdoogie]

Thanks for the good work, @telnetdoogie !

Appreciated, @maartenjd !

The firewall enablement is an interesting observation. So far as I'm aware, iptables is running regardless of whether DSM firewall is enabled or not. I think enabling / disabling it just applies rules differently, but that's probably worth some investigation.

[github-actions]

This issue has been marked as stale and will be closed

[maartenjd]

Best wishes for 2026, all!

I did some investigation and executed iptables --listin various conditions.

Attached is the outcome in four files, two before rebooting, two after the reboot:

• with synology fw enabled, before rebooting the system (can connect to the containers);
• with synology fw disabled, before rebooting the system(can still connect to the containers);
• reboot;
• with synology fw still disabled, after the reboot; (can no longer connect to the containers);
• with synology fw re-enabled again (can connect again to the containers).

Maybe @telnetdoogie can see in a blink of the eye what might be happening?
I can see that, with Synology fw disabled, in the output of iptables before and after reboot, some ip-addresses have changed from .0.2 to .0.5, whereas the containers have remained running on the same addresses.

Well, as long as I have my Synology fw enabled, things work OK. But it remains curious to me.

01-fw-enabled_before-reboot.txt
02-fw-disabled_before-reboot.txt
03-fw-disabled_after-reboot.txt
04-fw-re-enabled_after-reboot.txt

[telnetdoogie]

@maartenjd I've seen this issue on other people's installs and it baffles me. Originally, early on, I was recommending people add a sudo iptables -P FORWARD ACCEPT or add that on NAS startup, however it's inconsistent.

You could try running that when it's not working and see if it fixes things, but as far as what's messing things up, it's beyond me thus far.