Leaderboard

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!