TL;DR:

• Defer contribution to our docs to share with other users (Dockerfile edits + user-patches.sh), rather than maintain legacy support via ENV. If more users express a need for this support, we can consider the ENV approach then.
• Problem is likely due to NAS products (even those released last year) shipping kernels that are known to be 5 years old. Customers should engage with the product vendors to resolve that.

---

Looking at the PR that swapped iptables to nftables for v11, the fail2ban debug setup.sh command for debugging had this iptables specific logic, which may be helpful context if your setup would run into the issue?

Otherwise this mostly looks like it covers the relevant changes from that PR, our tests don't however, and there was quite a bit of difference there in syntax.

I'm not sure if other maintainers would want to carry this legacy support even if equivalent test support was added. As the PR shows, you could extend the image to add the relevant Dockerfile lines, and use user-patches.sh script to apply the single sed edit to /etc/fail2ban/jail.local?

While your time spent looking into the support and creating a PR is appreciated, the contribution may be better served as docs only contribution for how to solve this problem. We're trying to avoid adding more niche-case (and especially legacy support related ones) features when possible, and since the required changes to support this are small, the other maintainers likely share this opinion to defer to docs only.

I do understand that's probably frustrating, since needing to extend the image is more bothersome than carrying around user-patches.sh alone and maintaining compatibility with upstream over time. I believe we're more open to accepting this support when there's enough demand expressed for it, otherwise the preference is to defer to documenting it for others until then.

---

I will note that the PR which switched us to nftables had a discussion stating a iptables host + nftables container worked fine, and presumably the other way around as we've had no complaints since.

So I'm not sure why that differs with your QNAP host? Another docker project has this issue too, the users affected are QNAP and DSM (both NAS products), where at the end it's said that at least DSM 7 (released June 2021) was found to be using an extremely old kernel (4.4, Jan 2016)... that is not encouraging, and probably applies to your QNAP system? You should probably raise a complaint as a customer if you're on a kernel that old as well..