Vinney

Follow-up: workaround now confirmed stable across reboots, plus MTU data Reporting back after getting this fully persistent, in case it's useful for the fix or for anyone else hitting it. What works A udev rule on SUBSYSTEM=="net", KERNEL=="thunderbolt*" calling a script that sets the address and restarts smbd/nfsd. Survives cold boots, cable reseats and peer sleep — interface comes up addressed with services bound, no manual Apply. Three implementation details that caught me out, all worth knowing if you build something similar into the plugin: 1. The rule alone isn't enough at boot. The netdev appears before go has installed the rule, so the add event is never seen. You need udevadm trigger --subsystem-match=net --action=add after loading the rules to replay it against interfaces that already exist. Without that line it worked on hotplug but never on a cold boot. 2. FAT32 can't hold the execute bit. RUN+="/boot/config/.../script.sh" fails silently. Either invoke it as RUN+="/bin/bash /boot/..." or copy the script to /usr/local/bin first. I ended up doing the latter, which also removes the dependency on /bootbeing mounted when udev fires. 3. tbn_bring_up_ifaces() doesn't apply L3 config. I tried calling it from my script hoping to reuse your logic — the function exists and runs cleanly, but the interface stays unaddressed. Ended up with plain ip commands instead. MTU 9000 — no measurable throughput gain on this path Set on both ends (Unraid tbn0 and macOS Thunderbolt Bridge, including all three bridge0 member interfaces, which macOS does not raise automatically when you set the bridge MTU). MTU 1500 MTU 9000 Mac → Unraid 25.3 Gbit/s 25.0 Gbit/s Unraid → Mac 29.4 Gbit/s 28.3 Gbit/s Zero retransmits throughout. So your docs are right that jumbo is a CPU rather than a bandwidth win here — the single stream already saturates the path at 1500. Keeping it at 9000 for the reduced packet rate, but nobody should expect a throughput jump. One testing note: macOS ping -D -s 8972 fails with "Message too long" even when jumbo is working correctly — it's an ICMP buffer limit, not a path MTU problem. -s 8000 succeeds. Cost me a while chasing a non-issue.

Update to my earlier post — root cause found, plus a workaround Dug into the plugin source and found the mechanism behind the address instability I described. It's not just "settings don't persist" — there are three separable defects. 1. dhcpcd is never stopped when switching back to Static This is the one causing the address churn. include/tbn-lib.php ~line 2557 starts dhcpcd -n {$ife} when USE_DHCP=yes. The static branch calls tbn_iface_flush_l3() and adds the address, but never kills a dhcpcd already running on that interface. Once DHCP has been enabled even briefly, the client persists, finds no server, and keeps re-adding a rotating 169.254.x.x alongside the static IP. I had 10.255.0.x/24 and a 169.254 address stacked on the same interface, with the UI correctly showing Static the whole time — which is why it took so long to spot. dhcpcd -k thunderbolt0 clears it until next time. Suggested fix: dhcpcd -k {$ife}at the top of the static branch. 2. No boot-time reapply event/started calls tbn-dashboard-ports apply and tbn_of_apply() only — nothing applies per-interface addressing. After a reboot with the peer still cabled, 1-1 and 1-1.0 are in sysfs and thunderbolt0 exists, but it's unconfigured and services bind to the LAN address only. 3. No hotplug hook No udev rules in the package. Since the netdev is destroyed and recreated on every link drop — with a fresh MAC each time — config needs reapplying on ACTION=="add", not just at boot. Workaround for 2 and 3, in case it's useful to others: udev rule on SUBSYSTEM=="net", KERNEL=="thunderbolt*" calling a flash-resident script that sets the address and restarts smbd/nfsd, with the rule reinstalled from go since /etc/udev/rules.d is tmpfs. One gotcha — the script must be invoked as /bin/bash /path/script.sh; FAT32 won't hold the execute bit, so RUN+= on the bare path fails silently. Also worth flagging: tbn_bring_up_ifaces() doesn't apply L3 config, so it's not a shortcut for this. I used plain ip commands instead.

Unraid 7.3.2 · TB4 (Alder Lake-P) · macOS peer (Apple Silicon, Mac17,6) First off — thanks for this. Getting host-to-host working manually was fiddly, and having the tbn tab handle the interface plus the services include list is a big improvement. Working well: peer detection and naming, trained rate reporting (20 Gb/s full-duplex, 2-lane), and the "Include listening interface" option — Samba rebinds to the TB IP on Apply without me touching rc.samba. Measured 25.3 Gbit/s Mac→Cube and 29.4 Gbit/s Cube→Mac with iperf3, zero retransmits, MTU 1500 both ends. Direct cable. Through a Dell SD25TB4 dock it caps hard at 9.85 Gbit/s, consistent with your note about docks not being TB switches. Issue: config not reapplied after reboot or link drop. Steps: set static IPv4 on tbn0, Apply — works, interface UP with address, services bound. Reboot the server with the Mac still cabled. After boot, 1-1 and 1-1.0 are both present in /sys/bus/thunderbolt/devices/, and thunderbolt0 exists — but it's DOWN with no address, and Samba binds only to the LAN IP. A manual Apply on the tbn0 tab fixes it every time. Same thing happens on any link drop — changing the peer's IP config, or unplugging and reconnecting. One possibly relevant detail: the interface MAC is regenerated on each link establishment (I've seen 02:e3:0a:90:38:61, 02:e2:02:28:f5:9d, 02:f3:08:39:98:71, 02:fd:da:8b:66:41 across sessions). If known-peer matching keys on the local MAC, that might explain why the saved config isn't reapplied. Also saw the address field revert to the plugin default (10.255.0.x) after a reboot rather than keeping what I'd entered, though I may have caught it mid-apply. Happy to pull diagnostics if useful.

Unraid 7.3.2 · TB4 (Alder Lake-P) · macOS peer (Apple Silicon, Mac17,6) First off — thanks for this. Getting host-to-host working manually was fiddly, and having the tbn tab handle the interface plus the services include list is a big improvement. Working well: peer detection and naming, trained rate reporting (20 Gb/s full-duplex, 2-lane), and the "Include listening interface" option — Samba rebinds to the TB IP on Apply without me touching rc.samba. Measured 25.3 Gbit/s Mac→Cube and 29.4 Gbit/s Cube→Mac with iperf3, zero retransmits, MTU 1500 both ends. Direct cable. Through a Dell SD25TB4 dock it caps hard at 9.85 Gbit/s, consistent with your note about docks not being TB switches. Issue: config not reapplied after reboot or link drop. Steps: set static IPv4 on tbn0, Apply — works, interface UP with address, services bound. Reboot the server with the Mac still cabled. After boot, 1-1 and 1-1.0 are both present in /sys/bus/thunderbolt/devices/, and thunderbolt0 exists — but it's DOWN with no address, and Samba binds only to the LAN IP. A manual Apply on the tbn0 tab fixes it every time. Same thing happens on any link drop — changing the peer's IP config, or unplugging and reconnecting. One possibly relevant detail: the interface MAC is regenerated on each link establishment (I've seen 02:e3:0a:90:38:61, 02:e2:02:28:f5:9d, 02:f3:08:39:98:71, 02:fd:da:8b:66:41 across sessions). If known-peer matching keys on the local MAC, that might explain why the saved config isn't reapplied. Also saw the address field revert to the plugin default (10.255.0.x) after a reboot rather than keeping what I'd entered, though I may have caught it mid-apply. Happy to pull diagnostics if useful.

zfs mount -a worked for me too glad we where able to get to the bottom of this./

Ive had to downgrade to resolve this issue. Post downloading in SAB, i am getting the following error: Traceback (most recent call last): File "/usr/lib/sabnzbd/sabnzbd/filesystem.py", line 742, in create_all_dirs os.mkdir(path_part_combined) ~~~~~~~~^^^^^^^^^^^^^^^^^^^^ OSError: [Errno 22] Invalid argument: '/plex/tv/' 2025-10-08 02:29:16,939::INFO::[notifier:165] Sending notification: Error - Cannot create final folder /plex/tv/folder (type=error, job_cat=None) 2025-10-08 02:29:16,939::ERROR::[postproc:737] Cannot create final folder /plex/tv/folder 2025-10-08 02:29:16,939::INFO::[notifier:165] Sending notification: Error - Post Processing Failed for folder (see logfile) (type=error, job_cat=None) 2025-10-08 02:29:16,939::ERROR::[postproc:620] Post Processing Failed for folder (see logfile) 2025-10-08 02:29:16,939::INFO::[postproc:621] Traceback: Traceback (most recent call last): File "/usr/lib/sabnzbd/sabnzbd/postproc.py", line 445, in process_job tmp_workdir_complete, workdir_complete, file_sorter, one_folder, marker_file = prepare_extraction_path( ~~~~~~~~~~~~~~~~~~~~~~~^ nzo ^^^ ) ^ File "/usr/lib/sabnzbd/sabnzbd/postproc.py", line 738, in prepare_extraction_path raise IOError OSError

Hi when i try and change the file association, its doesn't keep and the dialog box continues to pop up. How do i fix this please?

Hi when i change the open with association - its doesn't save and the dialogue box continues to pop up? any ideas how i fix this?

Any progress on this?

Hi, I've seriously screwed up and dont know how to fix what i've done. Having run the new permission tools, i can not longer run any of my docker containers. When doing so, i get the following error@ ocker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/usr/bin/dumb-init": permission denied: unknown. Please is there a way to fix this??

Can we see this implemented please?

anyone had any success?

yes Sir .... had to power it up again ... but nothing in the logs as to why it shut off in the 1st place.

Hi, I'm needing a bit of help diagnosing a random shut down. I have syslog enabled but can't see anything Anyone kindly give me a steer please? Thanks in advance. cube-diagnostics-20240924-1939.zip