Skip to content

Thunderbolt Bridge: File Transfers Stall and Final Cut Pro Libraries Fail to Open When Wi-Fi or Ethernet Is Also Active #564

Closed

Description

@alloffroadau-netizen

Apple Feedback Assistant ID: 103015187181

DESCRIBE THE BUG:

File transfers and remote Final Cut Pro library access fail when Thunderbolt Bridge and another network connection are active simultaneously between two Mac Studio computers.

Thunderbolt Bridge works correctly on its own. Without Thunderbolt Bridge, remote libraries also open correctly over Wi-Fi, Ethernet, or both together. The problem occurs specifically when Thunderbolt Bridge is active alongside Ethernet, Wi-Fi, or both.

In the affected configurations:

  • The remote Mac and its shared volumes appear in Finder’s sidebar as expected.
  • The shared volumes can be mounted and browsed.
  • File copying starts but stops partway through, without displaying an error number.
  • Remote Final Cut Pro libraries do not finish opening.
  • After an unsuccessful library-opening attempt, Final Cut Pro on the host Mac reports that the library is in use by the client Mac.
  • Interrupted copies have left greyed-out, incomplete destination folders that I could not delete through Finder at the time.

This is not isolated to Final Cut Pro. General file copying between the two Macs is also affected.

TO REPRODUCE:

  1. Connect the two Mac Studio computers using a Thunderbolt cable and establish a Thunderbolt Bridge connection.
  2. Disable Ethernet and Wi-Fi on both computers, leaving Thunderbolt Bridge as the only active network connection.
  3. Select the automatically discovered remote Mac in Finder’s sidebar and mount its shared volume.
  4. Copy files and open a remotely stored Final Cut Pro library. Both operations work.
  5. Quit Final Cut Pro before testing the next configuration.
  6. Enable Ethernet while leaving Wi-Fi disabled and Thunderbolt Bridge active.
  7. Attempt to copy files or open the remote library. Copying starts but stops partway through, and the library does not finish opening.
  8. Repeat with Thunderbolt Bridge plus Wi-Fi only, then with Thunderbolt Bridge plus both Ethernet and Wi-Fi. The same failures occur in each configuration.
  9. As a separate control test, shut down and restart without the Thunderbolt connection. Access the shared library using Wi-Fi only, Ethernet only, or both together. The library opens successfully in all three configurations.

EXPECTED BEHAVIOUR:

File transfers and remote Final Cut Pro library access should continue to work reliably when multiple network connections are active.

Enabling Ethernet or Wi-Fi alongside Thunderbolt Bridge should not cause file transfers to stop or prevent libraries from opening.

SCREENSHOTS:

Not attached.

SPECS:

Host Mac:

  • M1 Ultra Mac Studio.
  • 128GB RAM.
  • 8TB internal SSD.
  • Test library stored on a partition of the internal SSD.

Client Mac:

  • M5 Ultra Mac Studio, as reported; exact model designation to be confirmed.
  • 96GB RAM.
  • 2TB internal SSD.

Software:

  • Tested under macOS 26.7.1 and macOS 27, with the same issue on both.
  • Final Cut Pro 12.4.

Connection and access:

  • Direct Thunderbolt Bridge connection.
  • Multiple Thunderbolt cables tested.
  • Shared volume mounted by selecting the automatically discovered remote Mac in Finder’s sidebar, rather than manually entering an IP address.

ADDITIONAL COMMENTS:

I tested this extensively with Apple Support. Multiple Thunderbolt cables produced the same result.

Configurations tested:

  • Thunderbolt Bridge only: file transfers and remote Final Cut Pro library access work.
  • Wi-Fi only, without Thunderbolt Bridge after restart: remote Final Cut Pro libraries open successfully.
  • Ethernet only, without Thunderbolt Bridge after restart: remote Final Cut Pro libraries open successfully.
  • Wi-Fi and Ethernet together, without Thunderbolt Bridge after restart: remote Final Cut Pro libraries open successfully.
  • Thunderbolt Bridge plus Ethernet, with Wi-Fi disabled: file transfers stop partway through, and remote libraries do not finish opening.
  • Thunderbolt Bridge plus Wi-Fi, with Ethernet disconnected: file transfers stop partway through, and remote libraries do not finish opening.
  • Thunderbolt Bridge plus Ethernet and Wi-Fi: file transfers stop partway through, and remote libraries do not finish opening.

The original library opens normally on the host M1 Mac Studio.

These tests narrow the issue to configurations where Thunderbolt Bridge is active alongside another network connection. Neither Thunderbolt Bridge alone nor ordinary network access without Thunderbolt Bridge reproduces the library-opening problem.

Because the share is mounted through Finder’s automatically discovered sidebar entry, the actual network interface used by the mounted share when multiple connections are active has not yet been verified. The underlying cause remains undetermined.

Sources

Activity

  1. latenitefilms commented on Nov 1, 2026

    @latenitefilms
    Contributor

    Is the Thunderbolt network on a different IP range than the Ethernet and Wifi?

  2. self-assigned this
    on Nov 1, 2026
  3. alloffroadau-netizen commented on Nov 1, 2026

    @alloffroadau-netizen
    Author

    Good question did't look in to that just used what Apple used by default, and Apple senior advises did not ask me to check when connecting macs but I would think if the IP address range was wrong the HD's would not show up and I could not connect to drives or mac at all

  4. latenitefilms commented on Nov 1, 2026

    @latenitefilms
    Contributor

    Strange things can happen if you have two different networks on the same IP range on two separate network devices.

    Generally speaking when doing a Thunderbolt bridge you should always use static IP's on both machines on a different IP range from your main network connection.

    For example, make Mac 1, 10.0.10.100/255.255.255.0 and make Mac 2 10.0.10.200/255.255.255.0 for Thunderbolt.

  5. alloffroadau-netizen commented on Nov 1, 2026

    @alloffroadau-netizen
    Author

    ok may check that from memory it said static IP address which apple did automatically but did not check range

  6. alloffroadau-netizen commented on Nov 1, 2026

    @alloffroadau-netizen
    Author

    Very good catch, Chris. After changing the Network address to the same IP address, which to be honest, Apple should really get the IP address from and not choosing some random stuff. It seems to work now. Sade that Apple level 2 support I spent over an hour with on the phone with didn't come up with that. But to be honest, even the level 2 support has hardly a clue about anything a little bit out of the ordinary. Another strange issue though is that it logs me in to the host computer by default with the secondary admin user test username and password automatically instead of the user which is logged in on the actual machine. I every time have to log out as a test user and then log in with the same user which is logged in to the host computer.

  7. alloffroadau-netizen commented on Nov 1, 2026

    @alloffroadau-netizen
    Author

    I still would say this is a bug though, as Apple's documentation does not say anything that It will not work with different network selected

  8. latenitefilms commented on Nov 1, 2026

    @latenitefilms
    Contributor

    I'm not sure this is a bug really - if you're creating a Thunderbolt network (or any direct machine-to-machine network), you should really always use static IP addresses. The only time you don't need static IP addresses is if your network has a DHCP server allocating them. Giving this, I'll close this issue for now, but feel free to re-open if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions