Hi

When I POWER-OFF my Thunderbolt monitor Unraid logs the following dmesg errors:

[1453854.908746] thunderbolt 0-1: device disconnected
[1453854.909252] udevd[406675]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: No such file or directory
[1453854.909325] udevd[406676]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: No such file or directory
[1453854.909525] udevd[406677]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: No such file or directory
[1453854.910399] udevd[406675]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/authorized} for writing: No such file or directory

When I POWER-ON the monitor Unraid lots the following (dmesg):

[1453903.569804] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1453903.569811] thunderbolt 0-1: DELL U2724DE
[1453903.660254] udevd[413098]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: Permission denied
[1453903.660598] udevd[413100]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: Permission denied
[1453903.686230] udevd[413098]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: Permission denied
[1453904.884342] thunderbolt 0-1: device disconnected
[1453904.884468] udevd[413098]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: No such file or directory
[1453904.884468] udevd[413100]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: No such file or directory
[1453904.884763] udevd[413275]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: No such file or directory
[1453904.885475] udevd[413275]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/authorized} for writing: No such file or directory
[1453908.393509] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1453908.393514] thunderbolt 0-1: DELL U2724DE
[1453908.487415] udevd[413632]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: Permission denied
[1453908.487655] udevd[413640]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: Permission denied
[1453908.513435] udevd[413632]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: Permission denied

How can I fix this?

I do not understand why after the power on the monitor flaps e.g. detected, diconnected, and detected again and then stays stable even though the error logs are the same in both cases.

My keyboard and mouse are connected to the monitors KVM and the monitor also has an Ethernet port (which I don't use). My Unraid server runs headless, the monitor is connected to a USB-4 port coupled with the iGPU which is passed through to a VM.

In order tho get this to work I first tried to passthrough the whole Thunderbolt controller. However this didn't work. What is working, is leaving Thunderbolt under the management of Unraid and then only passthrough the USB-port so that the VM can handle mouse and keyboard.

For Thunderbolt authentication I created the following udev rules in Unraid:

root@blackbox:~# cat /boot/config/udev/50_enable_thunderbolt.rules 
ACTION=="add", SUBSYSTEM=="thunderbolt", \ 
ATTR{iommu_dma_protection}=="1", \ 
ATTR{security}=="dponly", \ 
ATTR{authorized}=="0", \ 
ATTR{authorized}="1", \ 
RUN+="/bin/sh -c 'echo 1 > /sys/bus/thunderbolt/devices/domain0/0-0/0-1/authorized && echo 1 > /sys/bus/pci/rescan'"
root@blackbox:~# 

Here is the VM config that shows iGPU and USB passthrough:

Any help is appreciated. Thank you.

you will most likley need to make a udev rule.

Unraid has prebuilt USB rules. and thunderport falls under that for the inital /boot mopunt and load into ram for the OS.

Unraid also doen't support thuderbolt disk in teh array/pool as a usb discnet and power states break casing other errors for operation.

...

those syslog errors are basically telling you that the udevd process is trying to write to attributes that don’t exist or aren’t writable under the Thunderbolt sysfs tree

with unraid config folder one can make a udev folder and add rules.... ( I Assuem you did.... )

1. Anything in /boot/config/udev/*.rules is applied early, but Thunderbolt is hot-plug and sometimes the device path won’t match what you’ve hard-coded.

2. When the device disappears (disconnect, sleep, link flap), the kernel removes those attributes, so subsequent udev events fail with No such file or directory.

Also your udev rule is too aggressive...

ATTR{authorized}=="0",

ATTR{authorized}="1",

RUN+="/bin/sh -c 'echo 1 > …'"

That’s trying to set authorized in multiple different attribute sub-dirs (nvm_active1, nvm_non_active1, wakeup*, etc.) where it doesn’t even make sense. That’s why you get “Permission denied” and “No such file or directory”.
The only safe/writable one is typically /sys/bus/thunderbolt/devices/.../authorized.

make a safer udev rule:

# /boot/config/udev/50_enable_thunderbolt.rules
#
# Auto-authorize Thunderbolt devices safely
#
# Notes:
# - Only acts when a new Thunderbolt device is added
# - Writes to the device's own "authorized" attribute
# - Avoids touching unrelated nvm/wakeup attributes
# - No PCI rescan unless you know you need it (uncomment last line if required)
ACTION=="add", SUBSYSTEM=="thunderbolt", \
  ATTR{authorized}=="0", \
  RUN+="/bin/sh -c 'echo 1 > /sys$devpath/authorized'"
# If a PCI rescan is necessary for certain docks/GPUs, uncomment:
# ACTION=="add", SUBSYSTEM=="thunderbolt", \
#   ATTR{authorized}=="0", \
#   RUN+="/bin/sh -c 'echo 1 > /sys/bus/pci/rescan'"

Why this is safer:

• No hardcoded sysfs path → works regardless of which Thunderbolt port (0-1, 0-3, etc.) you use.

• Only sets authorized=1 on the actual device path → avoids spamming syslog with Permission denied.

• PCI rescan optional → only needed if the downstream device (like a GPU/dock PCIe bridge) doesn’t show up automatically

Thank you very much. I will try your updated udev rule and report back.

Do I have to reboot Unraid for the updated rule to take effect or can I for testing just update the runtime udev rule and power cycle my monitor?

To be honest, I have no clue about udev. This was the very first rule I created when I started with Linux and Unraid approximately 7 months ago. Once I got the monitor authenticated automatically and had access to mouse and keyboard in the VM even after power cycling I was happy.

I would reboot to update, I don't remember the triger reload command for slackware linux.

6 hours ago, Tom082 said:

Hi

When I POWER-OFF my Thunderbolt monitor Unraid logs the following dmesg errors:

[1453854.908746] thunderbolt 0-1: device disconnected
[1453854.909252] udevd[406675]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: No such file or directory
[1453854.909325] udevd[406676]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: No such file or directory
[1453854.909525] udevd[406677]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: No such file or directory
[1453854.910399] udevd[406675]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/authorized} for writing: No such file or directory

When I POWER-ON the monitor Unraid lots the following (dmesg):

[1453903.569804] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1453903.569811] thunderbolt 0-1: DELL U2724DE
[1453903.660254] udevd[413098]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: Permission denied
[1453903.660598] udevd[413100]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: Permission denied
[1453903.686230] udevd[413098]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: Permission denied
[1453904.884342] thunderbolt 0-1: device disconnected
[1453904.884468] udevd[413098]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: No such file or directory
[1453904.884468] udevd[413100]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: No such file or directory
[1453904.884763] udevd[413275]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: No such file or directory
[1453904.885475] udevd[413275]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/authorized} for writing: No such file or directory
[1453908.393509] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1453908.393514] thunderbolt 0-1: DELL U2724DE
[1453908.487415] udevd[413632]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_active1/authorized} for writing: Permission denied
[1453908.487655] udevd[413640]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/nvm_non_active1/authorized} for writing: Permission denied
[1453908.513435] udevd[413632]: error opening ATTR{/sys/devices/pci0000:00/0000:00:02.2/0000:18:00.0/0000:19:03.0/0000:7b:00.0/domain0/0-0/0-1/wakeup/wakeup108/authorized} for writing: Permission denied

How can I fix this?

I do not understand why after the power on the monitor flaps e.g. detected, diconnected, and detected again and then stays stable even though the error logs are the same in both cases.

My keyboard and mouse are connected to the monitors KVM and the monitor also has an Ethernet port (which I don't use). My Unraid server runs headless, the monitor is connected to a USB-4 port coupled with the iGPU which is passed through to a VM.

In order tho get this to work I first tried to passthrough the whole Thunderbolt controller. However this didn't work. What is working, is leaving Thunderbolt under the management of Unraid and then only passthrough the USB-port so that the VM can handle mouse and keyboard.

For Thunderbolt authentication I created the following udev rules in Unraid:

root@blackbox:~# cat /boot/config/udev/50_enable_thunderbolt.rules 
ACTION=="add", SUBSYSTEM=="thunderbolt", \ 
ATTR{iommu_dma_protection}=="1", \ 
ATTR{security}=="dponly", \ 
ATTR{authorized}=="0", \ 
ATTR{authorized}="1", \ 
RUN+="/bin/sh -c 'echo 1 > /sys/bus/thunderbolt/devices/domain0/0-0/0-1/authorized && echo 1 > /sys/bus/pci/rescan'"
root@blackbox:~# 

Here is the VM config that shows iGPU and USB passthrough:

Any help is appreciated. Thank you.

This may not fix you issue, but try the fix in this post. https://forums.unraid.net/bug-reports/prereleases/700-beta1-thunderbolt-drive-bay-not-detected-no-drives-visible-after-upgrade-r3056/#findComment-34784

It has been added into 7.2 as a default.

5 hours ago, bmartino1 said:

make a safer udev rule:

# /boot/config/udev/50_enable_thunderbolt.rules## Auto-authorize Thunderbolt devices safely## Notes:# - Only acts when a new Thunderbolt device is added# - Writes to the device's own "authorized" attribute# - Avoids touching unrelated nvm/wakeup attributes# - No PCI rescan unless you know you need it (uncomment last line if required)
ACTION=="add", SUBSYSTEM=="thunderbolt", \
  ATTR{authorized}=="0", \
  RUN+="/bin/sh -c 'echo 1 > /sys$devpath/authorized'"# If a PCI rescan is necessary for certain docks/GPUs, uncomment:# ACTION=="add", SUBSYSTEM=="thunderbolt", \#   ATTR{authorized}=="0", \#   RUN+="/bin/sh -c 'echo 1 > /sys/bus/pci/rescan'"

I tried modifying in the runtime environment. This seems to work. In order not to loose the keyboard and mouse I left the rescan in for now. I will experiment with that later. Here are the dmesg log I get now:

POWER-OFF

[1486828.614255] thunderbolt 0-1: device disconnected
[1486829.474582] pcieport 0000:1b:00.0: Unable to change power state from D3hot to D0, device inaccessible
[1486829.476126] pcieport 0000:1b:04.0: Unable to change power state from D3hot to D0, device inaccessible

POWER-ON

[1486847.852133] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1486847.852139] thunderbolt 0-1: DELL U2724DE
[1486848.018060] pcieport 0000:1a:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486848.018159] pcieport 0000:1b:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486848.018172] pcieport 0000:1b:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486848.018184] pcieport 0000:1b:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486848.018195] pcieport 0000:1b:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486848.018216] pcieport 0000:1b:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486848.018250] pci_bus 0000:1c: busn_res: [bus 1c] end is updated to 1c
[1486848.018282] pci_bus 0000:1d: busn_res: [bus 1d-2b] end is updated to 2b
[1486848.018312] pci_bus 0000:2c: busn_res: [bus 2c-3a] end is updated to 3a
[1486848.018341] pci_bus 0000:3b: busn_res: [bus 3b-48] end is updated to 48
[1486848.018371] pci_bus 0000:49: busn_res: [bus 49] end is updated to 49
[1486848.018377] pci_bus 0000:1b: busn_res: [bus 1b-49] end is updated to 49
[1486849.138586] thunderbolt 0-1: device disconnected
[1486849.740645] pcieport 0000:1b:04.0: Unable to change power state from D3hot to D0, device inaccessible
[1486849.742187] pcieport 0000:1b:00.0: Unable to change power state from D3hot to D0, device inaccessible
[1486852.641049] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1486852.641054] thunderbolt 0-1: DELL U2724DE
[1486852.804162] pcieport 0000:1a:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486852.804260] pcieport 0000:1b:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486852.804272] pcieport 0000:1b:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486852.804284] pcieport 0000:1b:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486852.804295] pcieport 0000:1b:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486852.804315] pcieport 0000:1b:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[1486852.804350] pci_bus 0000:1c: busn_res: [bus 1c] end is updated to 1c
[1486852.804383] pci_bus 0000:1d: busn_res: [bus 1d-2b] end is updated to 2b
[1486852.804414] pci_bus 0000:2c: busn_res: [bus 2c-3a] end is updated to 3a
[1486852.804443] pci_bus 0000:3b: busn_res: [bus 3b-48] end is updated to 48
[1486852.804473] pci_bus 0000:49: busn_res: [bus 49] end is updated to 49
[1486852.804479] pci_bus 0000:1b: busn_res: [bus 1b-49] end is updated to 49

My guess is that the disconnect reconnect cycle happens due to the rescan. Correct?

What are those power state errors I'm getting now and why did I not see them before? How can I fix those?

They are related to Thunderbolt:

root@blackbox:~# lspci | grep 1a:
1a:00.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] (rev 03)
root@blackbox:~# lspci | grep 1b:
1b:00.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] (rev 03)
1b:01.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] (rev 03)
1b:02.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] (rev 03)
1b:03.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] (rev 03)
1b:04.0 PCI bridge: Intel Corporation Thunderbolt 4 Bridge [Goshen Ridge 2020] (rev 03)
root@blackbox:~# 

Also I'm not sure if powering off the monitor will immediately invalidate the authorization or if there is some kind a timeout, meaning that if I power on before the timeout expired the monitor is still authorized and I do not test the udev rule. In case of a timeout I will have more updates tomorrow after the monitor was off over night. So far it looks much improved :-) Thank you so much @bmartino1

Edited August 23, 2025Aug 23 by Tom082

2 hours ago, SimonF said:

This may not fix you issue, but try the fix in this post. https://forums.unraid.net/bug-reports/prereleases/700-beta1-thunderbolt-drive-bay-not-detected-no-drives-visible-after-upgrade-r3056/#findComment-34784

It has been added into 7.2 as a default.

Thank you for sharing this post. I'm on 7.1.2 right now but using the 6.14.6-thor kernel (for RX9070 support). Not sure if this applies to my system. Except for the dmseg error messages it alwaysworked. Unraid always finds my Thunderbolt monitor and even my original udev rule always authorized the monitor. So in a way this is a cosmetic issue. I could have ignored the logs but I try to improve my Unraid and Linux skills and want to understand my logs and learn how to fix issues.

Edited August 23, 2025Aug 23 by Tom082

1 hour ago, Tom082 said:

Thank you for sharing this post. I'm on 7.1.2 right now but using the 6.14.6-thor kernel (for RX9070 support). Not sure if this applies to my system. Except for the dmseg error messages it alwaysworked. Unraid always finds my Thunderbolt monitor and even my original udev rule always authorized the monitor. So in a way this is a cosmetic issue. I could have ignored the logs but I try to improve my Unraid and Linux skills and want to understand my logs and learn how to fix issues.

Maybe unlikely to change your issue as the default was changed in kernel 6.12 onwards. Default in the kernel is thunderbolt.host_reset=1 but we found this to break things if the device is connected at boot. In 7.2 it is patched to reset=0. Maybe worth trying as may help/

Update:

Hah!, According to AI the rule can be simplified:

# Automatically authorize a Dell U2724DE Thunderbolt monitor (matched by device_name > cat /sys/bus/thunderbolt/devices/.../device_name)
ACTION=="add", SUBSYSTEM=="thunderbolt",
        ATTR{device_name}=="U2724DE",   # only act if device is my DELL monitor
        ATTR{authorized}=="0",          # only act if monitor is unauthorized
        ATTR{authorized}="1"            # if all the above is true, authorize it

This way I should still have some security and not blindly accept all devices. Also the run command seems to be redundant and for Display Port and USB functionality a rescan is not required as pointed out by @bmartino1

My original rule was busted because dma-protection and security requirements required for the rule to trigger are not met by the monitor. That is why the RUN part of the rule was required.

Update 2:

this brought back the errors. I'm experimenting with DEVPATH to constrain the level but so far without success.

Update 3:

rewriting the rule like this and removing comments somehow fixed it:

ACTION=="add", SUBSYSTEM=="thunderbolt", \
        ATTR{device_name}=="U2724DE", \
        ATTR{authorized}=="0", \
        ATTR{authorized}="1"

I do not understand why. Here are the logs:

[1496611.598446] thunderbolt 0-1: device disconnected


[1496624.280732] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1496624.280739] thunderbolt 0-1: DELL U2724DE
[1496625.575269] thunderbolt 0-1: device disconnected
[1496629.083819] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045
[1496629.083827] thunderbolt 0-1: DELL U2724DE

^C

root@blackbox:~# cat /sys/bus/thunderbolt/devices/0-1/device_name 
U2724DE
root@blackbox:~# cat /sys/bus/thunderbolt/devices/0-1/authorized 
1
root@blackbox:~# 

I still get this connect, disconnect, connect behavior even without the scan. My best guess is that this happens due to authorization.

Edited August 23, 2025Aug 23 by Tom082

What exatly is the issue? On unriad your just trying to pass the usb thunderbolt into a VM?

what do you mean by: POWER-OFF my Thunderbolt monitor Unraid
Did you turn off the screen? hitting the power button on the thunderbolt dock?

a Dell wd19s is what I have to test and have tested before. that power button on the dock is a signal term switch that tells the device to power off.
as a screen/monitor it self has a state when its on adn a state when its off. and when off it may read as a hid device with no input until the KVM is acvite for the reconnection.
a rescan may be need to move from powerr off to on if already connected.

? https://www.dell.com/en-us/shop/dell-ultrasharp-27-thunderbolt-hub-monitor-u2724de/apd/210-bksj/monitors-monitor-accessories

Just Need a bit more clarity of what device what button and what your trying to achieve.

Regardless, your did something that turns off something and unraid errors... It also looks like you have some solution or something else solved. if its working for you now I wouldn't worry about it.


My Question is, So, Why do you need the udev rule to begin with?

With that in mind and out of the way, Regarding info form this post as I don't mind helping to write a Udev rule.
Rescan is not always necessary this depends on what need to be reset to b e re trigered to respond and act accordingly.

As it looks like your getting a power state issue now. this can be edited both in the VM and on the host.

pcieport 0000:1b:00.0: Unable to change power state from D3hot to D0, device inaccessible

^- are usualy a pcie aspm misconfiguration with Passthorugh where its was told by the system to be in this state when the host is now saying it needs to be in this state.


We can use udev to target the dock via vendor / pcie device ID.
[1496624.280732] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045 [1496624.280739] thunderbolt 0-1: DELL U2724DE [1496625.575269] thunderbolt 0-1: device disconnected [1496629.083819] thunderbolt 0-1: new device found, vendor=0xd4 device=0xc045

With display monitors and other its more on getting the fame buffer to reset to resend the edid communication to the monitor.

This also looks like your using a type of octo link(using thunderbolt for pcie). And outside of touching the udev rule. I would recommend editing the unraid grub boot options.

Main > Flash > syslinux configuration

add more Grub options to the green section adational lines of:

kernel /bzimage
append initrd=/bzroot acpi=force acpi_osi=Linux usbcore.autosuspend=-1 pci=noaer pcie_aspm=off

To outrule a acpi sigterm and bios issues lets tell the linux system at boot to force acpi and force load a linux acpi

to fix some thunder bolt and unraid usb3 and above lets disable the autosuspend of the usb ports. (using -1 will disable the option to let usb 12 volts turn off power and enter some power states.

*This is what I think your hitting now with your udev and dock issues...

then lets fix and turn of pcie aspm power management and suppress pcie power issues in the logs to force a always on connection.

and potential the thunderbolt.host_reset=0 option per the other post.

this way we remove points of failure and issues with IOMMU and VM passthorugh.

As it looks like you have something marked as solved. Unknown if you found a workaround or a fix. But AI like chat gpt can help you rewrite or fix a udev rule.

Otherwise i'd point you to some documentation on udev for thunderbolt: https://www.kernel.org/doc/html/v5.0/admin-guide/thunderbolt.html

as it looks like you have something that is targeting the monitor only and if not the monitor you can target the pcie vendor device id for the udev rule.

Edited August 24, 2025Aug 24 by bmartino1
data / spelling

may be a continuation to post: https://forums.unraid.net/topic/193037-unraid-gui-keeps-spaming-the-following-kernel-errors-pcieport-unable-to-change-power-state-from-d3cold-to-d0-device-inaccessible/?&do=getLastComment

6 hours ago, bmartino1 said:

What exatly is the issue? On unriad your just trying to pass the usb thunderbolt into a VM?

I currently don't have issues with my setup, everything is working and is stable. But I do get error messages in the logs and I try to understand and fix them.
The first error is the one in this thread. The updated udev rule fixed those. I can now power cycle my monitor and do not get error messages anymore.

6 hours ago, bmartino1 said:

what do you mean by: POWER-OFF my Thunderbolt monitor Unraid
Did you turn off the screen? hitting the power button on the thunderbolt dock?

Yes with power cycling I mean turning the screen on and off via power button. I do not have a dock. The monitor is directly connected to my motherboard. My motherboard has only 1 HDMI and 2x USB4/TB for iGPU display output. My secondary monitor is connected via HDMI and therefore the primary monitor (incl KWM) is attached via USB4/TB.

6 hours ago, bmartino1 said:

? https://www.dell.com/en-us/shop/dell-ultrasharp-27-thunderbolt-hub-monitor-u2724de/apd/210-bksj/monitors-monitor-accessories

Yes, that is my primary monitor. The secondary is the same model but without KVM and TB (U2724D)

6 hours ago, bmartino1 said:

My Question is, So, Why do you need the udev rule to begin with?

When I did my setup all of this (Unraid and Linux) where new to me. I first tried TB Controller plus USB controller passthrough to the VM. This did not work properly and my screen remained black after power cycling the monitor. My journey is described here. At this stage I needed to authenticate the monitor manually. After a lot of trial and error by chance I figured out that there was no need to passthrough the Thunderbolt controller, only the USB controller. Since the Thunderbolt Controller is back under Unraid's control I created the original udev rule. Once all worked I did not go back to see that is really needed and what not, I was just happy that I somehow managed to get it working.

One week ago I started to improve and optimize my setup and update my documentation as preparation for my upcoming homelab expansion. I got hooked This kind of an addiction...

Thank you very much for all the other hints and recommendations. So far I have not touched my syslinux configuration. But I will certainly look in to the power saving options.

For me this issue is solved, with the updated udev rule I do not see the error message anymore and the monitor gets authenticated every time on boot as well after power cycles.

The other thread describes another error I see in my logs. Even though they are both related to Thunderbolt I don't think that they are related. I will post updates and clarification for that over there.