Review TrueNAS bridge address ownership before a single-NIC cutover

Bottom line: Treat manual bridge creation as an address-ownership cutover, not simply another guest NIC. Preserve the existing interface settings and plan the stopped workloads and service bindings before changing the management path.

Source fact: what the authority says

The TrueNAS guest-to-NAS guide offers a default automatic bridge, a manually created single-interface bridge or a separate physical NIC. Before interface changes it calls for stopping apps, powering off VMs and containers and removing their active NIC devices. The manual procedure removes the physical interface’s static address and configures that address on the bridge with the original interface as a member. Its troubleshooting path reviews running workloads and services bound to the bridge address; without a timely Save Changes check-in, unsaved network changes revert.

What the source does not establish

This article concerns the manual single-interface cutover in the versioned guide, rather than a universal recommendation to replace the default automatic bridge. It does not qualify every VM network, service binding or storage permission in an existing system.

Applicability questions

• Is a manual bridge required, or does the documented default meet the need?
• Which address and netmask are currently assigned to the physical interface?
• Which apps, guests and services depend on that address?
• Who has independent console access and authority to abandon the cutover?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends an address-transition card showing the original physical interface and the proposed bridge as separate objects. Identify the one intended owner of the management address at each step. Preserve the interface and global configuration views before touching the current address.

Inventory the running workloads and review the approved stop and restart order with their owners. Name any sharing service bound to the affected address. Do not discover those dependencies by repeatedly submitting the same failing network change during normal service hours.

Prepare the timed test as a specific cutover step with a named observer and recovery contact. Review how management access will be checked and who will save the intended configuration. Keep the earlier state available through an independent access path rather than relying on the connection being changed.

Use a proposed test guest and harmless NAS data after the interface transition is accepted. Keep guest attachment, NAS service access and application permissions as separate checklist items. Avoid changing file permissions merely because the initial network test did not complete.

Verification and evidence

Proposed verification: compare the effective physical-interface and bridge address ownership with the transition card, then check management reachability and the intended guest-to-NAS path. Observe the actual save or revert outcome within the selected test window and retain its timing.

If the test fails, investigate the exact bound address, running workload and saved interface state before another attempt. After recovery or acceptance, restore approved services and guests in the planned order and confirm their named operations. Record the network result separately from successful authentication and data access.

Official references

• TrueNAS — Accessing NAS from VMs and Containers — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.