Feature Request: Allow configuration of Docker network pool (and consider changing the default)

[kachunkachunk]

To start, Docker is behaving correctly. But in HexOS, I'm seeing that the configured base 172.17.0.0/12 is technically invalid as a /12 network boundary, which is being normalized to 172.16.0.0/12.
This results in automatic allocation of 172.16.x.0/24 networks. If the intention is to allocate only from 172.17.x.x, the base should be changed to 172.17.0.0/16.

Practically speaking, when a user deploys apps, they typically appear to end up on new Docker bridge networks, which can quickly create IP conflicts for the few users out there using 172.16.x.x/16 networks.
I noticed this after the TrueNAS login page was showing up unexpectedly for one of my unrelated endpoints.

I'd suggest surfacing some configuration parameters somewhere in the UI, namely the Docker network pool config.

As a more immediate fix: To reconfigure my HexOS deployment to use the 172.17.0.0/16 network ranges instead, I ran:

root@HexOS[~]# midclt call docker.update '{
  "address_pools": [
    {
      "base": "172.17.0.0/16",
      "size": 24
    },
    {
      "base": "fdd0::/48",
      "size": 64
    }
  ]
}'

[mill3000]

Hello. Thanks for taking the time to write this. We did see the point of this and will roll it in to HexOS. Not sure when it will be releasaed but it will do this on new installs going forward once it's implimented. We don't want to cause any issues for anyone that's not currently affected. 

[eschultz]

Following up on this — the fix is implemented and will ship in an upcoming release.

You were exactly right about the root cause: the stock 172.17.0.0/12 base isn't a valid /12 boundary, so Docker canonicalizes it to 172.16.0.0/12 and allocates from 172.16.0.0/24 upward. On new installs going forward, HexOS now checks the subnets in use on the box during setup and picks the first /16 in the 172.17–172.31 range that doesn't overlap any of them, instead of leaving the stock default in place.

A few notes on scope:

• Existing installs are deliberately left as-is. Changing the address pool on a system with deployed apps renumbers container networks and forces a redeploy of everything, so we won't touch it automatically.
• Your midclt call docker.update workaround is the right fix for an existing system, and it's safe to keep — HexOS only replaces the pool when it's still the untouched stock default, so a customized pool like yours won't be overwritten.
• One limitation of the automatic pick: it can only avoid subnets the NAS actually has an interface on. A 172.x VLAN or VPN range elsewhere on your network is invisible to it — that's the case a UI setting for the pool config covers, which is still on our list as a follow-up.

Thanks again for the detailed diagnosis — it made this a straightforward fix!