CAUTION: don't add vb-docker to br0 ! I had to reboot to fix this

TrueNAS General
1

While looking at the Netowrking tab, I had the (not so) brilliant idea of making vb-docker a member of br0.

that in itself didn’t break anything, but when I used dockge to create a new container, I was greeted with:

Error response from daemon: failed to create endpoint debian-debian-1 on network debian_default: adding interface vethb7d8899 to bridge br-78f70e66f3ba failed: Device does not exist

I set everything back and did a jlmkr restart docker and things were still broken.

Reboot fixed it.

Here’s what ChatGPT said about this:

In your setup, where you created a bridge (br0) in TrueNAS SCALE so that VMs can communicate with the TrueNAS host, adding the Docker virtual bridge (vb-docker) as a member of br0 may or may not be necessary depending on your networking goals. Let’s walk through some considerations.

1. What You’ve Done So Far:

  • br0: A bridge interface that allows your VMs to communicate with each other and the TrueNAS host. It has the physical Ethernet interface (e.g., enp3s0) as a member.
  • VMs: Connected to br0, allowing them to access the LAN and potentially the TrueNAS host.

2. Adding vb-docker to br0:

If your goal is to let Docker containers talk to the TrueNAS host and VMs via br0, adding vb-docker to the bridge may be a reasonable approach. Here’s what you need to consider:

  • Docker Networking Default Behavior: By default, Docker uses its own bridge (docker0 or in your case, vb-docker) for container networking. This bridge is typically isolated from other networks, which means containers may not be able to communicate directly with br0, the VMs, or even the TrueNAS host (except through port forwarding or NAT).

  • Combining vb-docker and br0:

    • If you add vb-docker as a member of br0, Docker containers will be able to communicate directly with the TrueNAS host, VMs, and other devices on the same network segment (without needing port forwarding or NAT).
    • The downside is that Docker might not fully control the networking stack for the containers, which could lead to issues with Docker’s network isolation, port management, or conflicting IP assignments.

3. Alternative: Use Docker’s Macvlan Network

Instead of adding vb-docker to br0, a more controlled approach might be to use Docker’s Macvlan driver. This allows you to assign Docker containers IP addresses on the same subnet as br0, letting them communicate with the TrueNAS host and VMs without modifying vb-docker.

Here’s how you can create a Macvlan network for Docker:

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=br0 \
  macvlan_net
  • parent=br0: Specifies that Docker should attach containers to the br0 bridge.
  • subnet and gateway: Should match the network your br0 interface is on (adjust as needed for your network setup).

This will allow Docker containers to communicate with VMs, the TrueNAS host, and other devices on your LAN, while still maintaining Docker’s control over the network isolation for containers.

4. When to Add vb-docker to br0:

You might want to add vb-docker to br0 if:

  • You don’t need network isolation between Docker containers, VMs, and the TrueNAS host.
  • You want all network devices to be part of the same bridge, allowing direct communication between containers, VMs, and the host without any Docker-specific networking complexities.

5. When to Use Docker’s Macvlan or Stick to vb-docker:

  • If you need isolation or want Docker to manage its own networking, use Docker’s Macvlan network or stick with the default vb-docker configuration.
  • If your priority is simplicity and direct connectivity between all systems (containers, VMs, and host), then adding vb-docker to br0 might work, but be mindful of potential network conflicts.

Conclusion:

  • If you want all devices (VMs, containers, and TrueNAS host) to communicate seamlessly, adding vb-docker to br0 might be a simple solution, but it reduces Docker’s ability to manage its own networking.
  • For better network management and isolation, consider using Docker’s Macvlan network, which allows containers to have their own IP addresses on the same subnet as br0, without losing Docker’s networking features.

Let me know which approach you prefer or if you need further details!

2

And then it proceeded to convincingly bullsh#t you.

1 Like
3

Just how many times do people need to fuck up perfectly well working systems to realise that ChatGPT, no matter the version, is NOT a replacement for doing some basic searches, or asking the community?

LLMs hallucinate. It’s their PRIMARY FUNCTION. DO NOT use them for technical documentation or to answer arbitrary technical questions.

This is a perfect example of such hallucinations. The vb-docker bridge is created so that the containers on the (main) docker network can communicate with each other (Docker by default creates a network for all containers that do not specify a separate network or host mode).

The host, however, will always be able to talk to these devices, as it is part of the network (it essentially acts like the router of your home network). Adding it to br0 is the stupidest idea you can do, and you’re hella lucky you only needed a reboot - it could’ve screwed up your networking settings so bad, you would’ve needed a complete reinstall of TrueNAS just to get things back in order.

Docker already provides a pretty solid networking setup, you don’t need to reinvent the wheel, especially not using ChatGPT. Just RTFM. It’s worth ten times more than the hardware your average ChatGPT instance needs to run on.

4

I think, you’re using jailmaker.

When you setup an nspawn sandbox with a bridge interface it creates a vb-SANDBOXNAME virtual bridge (vb) connected to the parent interface (br)

One is temporary, and I guess you created a loop

1 Like
5

yup. exactly.

6

I reset everything back, then rebooted. problem solved.