Zitat:Du musst deine vorhandene daemon.json nur ergänzen, nicht ersetzen. data-root und containerd-snapshotter bleiben unverändert.
so setzen:
{
  "data-root": "/volume1/@docker",
  "features": {
    "containerd-snapshotter": false
  },
  "default-address-pools": [
    {
      "base": "172.20.0.0/14",
      "size": 24
    }
  ]
}

Damit darf Docker für automatisch angelegte Netzwerke nur noch aus 172.20.0.0/14 einzelne /24-Netze vergeben, also beispielsweise:
172.20.0.0/24
172.20.1.0/24
172.20.2.0/24
...
172.23.255.0/24

192.168.x.x wird dann nicht mehr automatisch für neue Docker-Netze benutzt. Docker unterstützt default-address-pools genau für solche Fälle, um Kollisionen mit vorhandenen LAN-/VPN-Netzen zu vermeiden.
Wichtig: Das ändert bestehende Docker-Netze nicht. Es gilt erst, wenn ein neues Netzwerk erzeugt wird. Falls noch problematische 192.168.x.x-Docker-Netze existieren, müssten diese anschließend gezielt gelöscht und von Compose neu erzeugt werden.
Vor dem Neustart kannst du die JSON-Datei prüfen:
cat /etc/docker/daemon.json

Sehr sinnvoll:
dockerd --validate --config-file=/etc/docker/daemon.json

Bei korrekter Datei sollte sinngemäß kommen:
configuration OK

Dann Docker neu starten. Auf normalem Debian:
sudo systemctl restart docker

Danach zum Test ein neues Netzwerk erzeugen:
docker network create test-netz

und kontrollieren:
docker network inspect test-netz \
  --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'

Es sollte dann beispielsweise kommen:
172.20.0.0/24

Anschließend:
docker network rm test-netz

Eine Sache würde ich aber vorher auf deinem NAS prüfen: ob 172.20.0.0/14 bei dir schon anderweitig verwendet wird:
ip route | grep -E '172\.2[0-3]\.'

und:
docker network inspect $(docker network ls -q) \
  --format '{{.Name}} {{range .IPAM.Config}}{{.Subnet}} {{end}}'

Falls dort bereits viele 172.20–172.23-Netze vorhanden sind, können wir stattdessen einen anderen konfliktfreien privaten Bereich fest reservieren. Das wäre besser, als jetzt eine neue Überschneidung einzubauen.