after running properly for a 5 days, my passed through tpm goes into an error.

2025-10-27T05:28:40.801789Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

if i stop the vm and try to start it again (without rebooting my whole unraid server) i get. (ignore the date and time stamp i took this cut and paste the previous time this happened).

rebooting (sometimes even needing a poweroff / poweron) to release the TPM seems necessary. i am unsure if this is obvious to others or not or if it only happens when it is in the error mode but '/dev/fdset/0' doesn't exist. so i don't know why the error is saying that. maybe it exists when there is not error, but i don't think so? i am currently waiting for a response before i reboot this time.

internal error: QEMU unexpectedly closed the monitor (vm='DELL-PC'): 2025-10-22T11:28:47.393672Z qemu-system-x86_64: -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/0,cancel-path=/dev/fdset/1: '/dev/fdset/0' is not a TPM device.

this is a pretty bad ongoing issue that i have been putting off making this support request for. it was happening in earlier version as well but wasn't nearly as bad. i even downgraded my version for a very long time because of it.

anyway i would very much appreciate any help.

ps. if you are wondering why .. i need to use this line(see below) in my xml so that my system is recognized as the hardware it is on. i have my original nvme drive passed through where my companies corporate image is installed. then i must passthrough my tpm, in this way i can use my companies vpn, and windows 'hello!' login/ pin, that is based on the original hardware and a certificate that it checks against that hardware.

<smbios mode='host'/>

dell-pc-diagnostics-20251027-0859.zip

Edited December 13, 2025Dec 13 by xtrap225
making more concise, add more context

anyone? i have waiting too long and must reboot the server again to get my vm going, however i am sure the issue will return. if there is anymore data i can get while things are working let me know.


or example right now the following is the error i get when trying to start the vm

virsh start DELL-PC

error: Failed to start domain 'DELL-PC'

error: Could not open TPM device /dev/tpm0: No such file or directory

and i can conffirm there is no '/dev/tpm0'

ll /dev/tpm0

ls: cannot access '/dev/tpm0': No such file or directory

after i reboot i will check again and i am pretty sure it will be there.

**** after reboot and upgrade to 7.2.0 ****

ll /dev/tpm0

crw------- 1 root root 10, 224 Nov 13 10:56 /dev/tpm0

virsh start DELL-PC

Domain 'DELL-PC' started

Edited November 13, 2025Nov 13 by xtrap225
add info after rebooting unraid server

i also just now see there is an update to 7.2.0 ; while i would normally wait a lot longer to make sure it is stable first, i think risking the early adoption is better than the current issue i face. so i will do that update prior to the reboot.

Edited November 13, 2025Nov 13 by xtrap225
correcting version number from 7.20 to 7.2.0

had the issue again (after the reboot and update), nearly immediately this time.
025-11-13T16:25:56.398047Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

2025-11-13T16:25:56.399426Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

2025-11-13T16:28:25.233206Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

2025-11-13T16:33:32.761522Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

i had to force shutdown / destroy the vm and the /dev/tpm0 is still there but the /dev/fdset issue is back again

ll /dev/tpm0

crw------- 1 root root 10, 224 Nov 13 10:56 /dev/tpm0

virsh start DELL-PC

error: Failed to start domain 'DELL-PC'

error: internal error: QEMU unexpectedly closed the monitor (vm='DELL-PC'): 2025-11-13T16:34:44.631128Z qemu-system-x86_64: -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/0,cancel-path=/dev/fdset/1: '/dev/fdset/0' is not a TPM device.

ll /dev/tpm0

crw------- 1 root root 10, 224 Nov 13 10:56 /dev/tpm0

root@DELL-PC:~# ll /dev/fdset

ls: cannot access '/dev/fdset': No such file or directory

end of log after destroy and start attempt again

-watchdog-action reset \

-device '{"driver":"vfio-pci","host":"0000:c2:00.0","id":"hostdev0","bus":"pci.5","addr":"0x0"}' \

-device '{"driver":"usb-host","hostdevice":"/dev/bus/usb/001/005","id":"hostdev1","bus":"usb.0","port":"1"}' \

-device '{"driver":"usb-host","hostdevice":"/dev/bus/usb/001/002","id":"hostdev2","bus":"usb.0","port":"2"}' \

-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \

-msg timestamp=on

2025-11-13 16:34:44.554+0000: Domain id=2 is tainted: high-privileges

char device redirected to /dev/pts/1 (label charserial0)

2025-11-13T16:34:44.631128Z qemu-system-x86_64: -tpmdev passthrough,id=tpm-tpm0,path=/dev/fdset/0,cancel-path=/dev/fdset/1: '/dev/fdset/0' is not a TPM device.

2025-11-13 16:34:44.666+0000: shutting down, reason=failed

it takes about five minutes to break. but since i am already logged in to Windows using the working pin cause and on vpn before the TPM breaks, i can keep going until windows needs a reboot.

to shutdown and restart the vm, requires a full unraid server reboot.

2025-11-13 17:29:15.296+0000: Domain id=1 is tainted: high-privileges

char device redirected to /dev/pts/1 (label charserial0)

2025-11-13T17:33:58.062906Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

i had to reboot again so i upgraded to 7.2.2 .. it didn't help. but it also didn't hurt anything further. same issue.

anyone have any ideas on this one?

anyone have any ideas on this one? or even a comment? did i do something wrong? did i ask this in the wrong location on the forum?

Edited January 2Jan 2 by xtrap225

Libvirt 11.7.0 + QEMU 9.2.3 has a regression/bug with TPM passthrough that causes the error: '/dev/fdset/0' is not a TPM device. This affects hardware TPM passthrough (both /dev/tpm0 and /dev/tpmrm0) with both tpm-tis and tpm-crb models. The issue appears to be in libvirt's file descriptor passing mechanism for TPM devices. A reboot temporarily resolves the issue, but it recurs. Could you investigate upgrading to a newer libvirt version or applying patches to fix the TPM passthrough fd handling?

so i think the issue was / is that tailscale was grabbing the tpm out from under qemu / libvirt.

i have no idea what i actually did to fix it but now, even though this was already how it was setup.

lsof /dev/tpm* 2>/dev/null

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

tailscale 21088 root 18u CHR 242,65536 0t0 398 /dev/tpmrm0

tailscale 21088 root 28u CHR 242,65536 0t0 398 /dev/tpmrm0

qemu-syst 24981 root 6u CHR 10,224 0t0 397 /dev/tpm0

qemu-syst 24981 root 23u CHR 10,224 0t0 397 /dev/tpm0

ll /dev/tpm*

crw------- 1 root users 10, 224 Jan 5 09:04 /dev/tpm0

crw------- 1 root root 242, 65536 Jan 5 09:04 /dev/tpmrm0

issue came back, just took longer

i might maybe finally have a fix in place however i am unsure and hesitant to confirm it as fixed yet.

i get the following line in red, but that is almost certainly a non-issue. it is because of using the qemu direct lines in the xml instead of working through only the libvirt.

2026-01-15 16:56:34.790+0000: Domain id=1 is tainted: custom-argv

at this time i am at 2 days 1.5 hours since last reboot, which is the longest ever since this issue started.

to be clear unraid itself is stable and doesn't require rebooting, just if i needed my work vm to you know work.

i have changed my passthrough of the tpm from tis to crb in my xml,

<tpm model='tpm-crb'>
<backend type='passthrough'>
<device path='/dev/tpm0'/>
</backend>
<alias name='tpm0'/>
</tpm>

since that change i have removed the above and changed the xml top line to.

<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>

and the bottom section to ... just above the closing line </domain>.

<qemu:commandline>
<qemu:arg value='-tpmdev'/>
<qemu:arg value='passthrough,id=tpm0,path=/dev/tpm0,cancel-path=/dev/null'/>
<qemu:arg value='-device'/>
<qemu:arg value='tpm-crb,tpmdev=tpm0'/>
</qemu:commandline>

and put the following in the /etc/libvirt/qemu.conf, now i temporarily made these changes permanent by keeping the file i want in /boot/config/qemu.conf and using the go file to rm -f that file and ln -s the kept file to the proper location(see top of go file below). this is likely not the best way of doing that as eventually that file may change in upgrades so using something like sed to add the changes on boot might be a better method.

cgroup_device_acl = [
"/dev/tpm0",
"/dev/null", "/dev/full", "/dev/zero",
"/dev/random", "/dev/urandom",
"/dev/ptmx", "/dev/kvm"
]

my 'go' file now has this in it, which also re-iterates the current method i am using for the above qemu.conf. i put this just under and unrelated fix from years ago i am unsure if it is still required but otherwise it's at the top.

#!/bin/bash

#not sure why this comes but based on cron.daily error <--unrelated and may or may not be needed still for an error i was getting after reboot daily.
touch /var/log/tinc.log

# Force correct Tailscale parameters (fix single dash bug)
cat <<EOF > /usr/local/emhttp/plugins/tailscale/custom-params.sh
TAILSCALE_CUSTOM_PARAMS="--encrypt-state=false --hardware-attestation=false"
EOF

# Ensure permissions are set so Tailscale can't 'see' the TPM to lock it
chmod 000 /dev/tpm0 /dev/tpmrm0

#fix qemu for tpm issue
rm -f /etc/libvirt/qemu.conf
ln -s /boot/config/qemu.conf /etc/libvirt/qemu.conf

i turned off auto starting of the vm, which i mostly kept off anyway. but now i start it using a user script as follows; which i run manually.

(/boot/config/plugins/user.scripts/scripts/Fix_TPM_and_Start_VM)

#!/bin/bash
# 1. Reset the device permissions just in case
chown root:root /dev/tpm0
chmod 660 /dev/tpm0
# 2. Start the VM
virsh start DELL-PC
# 3. Wait 10 seconds for the VM to claim the hardware
sleep 10

if this repair survives another week or so i will call it fixed and mark this as solved.

Edited January 17Jan 17 by xtrap225

# Force correct Tailscale parameters (fix single dash bug)

FYI, there's no bug there -- single or double dashes are OK. That fix also won't work since custom-params.sh is rewritten every time Tailscale is started.

it came back at nearly quarter after 4am this morning. so that is an approximate record uptime of 4 days and 16 hours (about), before reoccurrence.

2026-01-20T04:11:39.899988Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

i am going to try to fix it, using the same concept as the previous fix but this time just stopping the tailscale service and starting it again without read permissions to the tpm. no rebooting.

if i can get it to work i can maybe create another user script to 'fix' as needed while not rebooting. but i have my doubts, and even if it does work, i don't know if i can call that a 'fix'.

probably something in the tailscale that can be changed to NOT use the tpm but i thought it was already set.

Edited January 20Jan 20 by xtrap225

i have changed /added to my /boot/config/go

rm -f /dev/tpmrm0

the idea here is that this will prevent tailscale or anything from messing around with tpmrm0 and still allow the vm to interact with tpm0 which is necessary.

otherwise i have the vm starting automatically via GUI slider again, and NOT changed back other customization in go file or xml.

so far so good, for a bit there the error was coming up nearly immediately again in the vm's log .. so far it hasn't but need to wait for as long as a week or two to make sure it doesn't come back again.

On 1/17/2026 at 9:40 PM, EDACerton said:

# Force correct Tailscale parameters (fix single dash bug)

FYI, there's no bug there -- single or double dashes are OK. That fix also won't work since custom-params.sh is rewritten every time Tailscale is started.

thanks i did notice that, both it gets rewritten and that a single dash is correct. big thanks for the response though..

i forgot to come back and make the correction because of all the attempts to fix.

Edited January 28Jan 28 by xtrap225

came back

start was approx

2026-01-28 14:04:40.477+0000: starting up libvirt version: 11.7.0, qemu version: 9.2.3, kernel: 6.12.54-Unraid, hostname:

done starting approx

026-01-28T14:19:29.674078Z

error

2026-01-29T14:21:54.949080Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

remains on vpn for a while longer so i won't try anything until i must. or no one is watching plex

here is my latest attempts - added 'tpm_tis.interrupts=0' to the boot see picture below

added this to go file

# 1. Force TPM Power to stay ON (prevents sleep/broken pipe)

echo "on" > /sys/class/tpm/tpm0/device/power/control

# 2. Try to wrest RNG control away if it hasn't been blocked via Syslinux yet

echo "none" > /sys/devices/virtual/misc/hw_random/rng_current 2>/dev/null #<----this didn't work it remains 'tpm-rng-0'

# 3. Ensure permissions are wide open for QEMU

chmod 666 /dev/tpm0

assuming now that the error will return, next thing to try will be to make changes to the bios.

BIOS Category	Setting Name	Action	Why?
Security > TPM 2.0	TPM Security / TPM On	ENABLED	Essential for the chip to exist.
Security > TPM 2.0	PPI Bypass for Enable	ENABLED (Check)	Prevents BIOS prompts when the VM resets the TPM.
Security > TPM 2.0	PPI Bypass for Clear	ENABLED (Check)	Same as above; avoids manual interaction.
Security > TPM 2.0	Attestation Enable	DISABLED (Uncheck)	Stops Dell firmware from constantly "pinging" the chip.
Security > TPM 2.0	Key Storage Enable	ENABLED (Check)	Allows the chip to actually store the keys your VPN needs.
Security > TPM 2.0	SHA-256	ENABLED	Ensure the hashing algorithm is modern (standard for TPM 2.0).
Virtualization	Trusted Execution (TXT)	DISABLED (Off)	CRITICAL. This is the primary cause of "Broken Pipe."
Security	Intel PTT	DISABLED (Off)	Prevents the CPU's internal TPM from fighting the discrete chip.

but for now i am monitoring ...

2026-02-02 17:43:18.714+0000: Domain id=2 is tainted: high-privileges

2026-02-02 17:43:18.714+0000: Domain id=2 is tainted: custom-argv

char device redirected to /dev/pts/1 (label charserial0)

2026-02-03T12:12:18.839718Z qemu-system-x86_64: tpm_passthrough: error while transmitting data to TPM: Broken pipe

approx start time 2026-02-02 5:43 PM
approx error time 2026-02-03T12:12 AM

next schedule shutdown and hopefully make bios changes above, i don't actually know what the current settings are.

bios settings were no help

back to the drawing board.

okay i got it i am like 99.999% sure this time. kinda cheating but whatever gets the job done.
i will edit this with more detail later before marking it complete.

basically i got a new usb corporate image sent to me. i dd'd it to a .img file edited the xml to use the .img as the installer, and before doing that also switched emulated tpm before installing. this allowed me to use an emulated tpm and get the vpn to work and not have to rat myself out to the IT support team.

but there are more important details to come. just in case anyone else is in the same position.