# Swtpm Permission Denied **URL:** \ **Category:** General\ **Created:** [April 8, 2024, 6:05pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035 "2024-04-08T18:05:59Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Scridgeon](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/scridgeon/32/1142_2.png) [@Scridgeon](https://universal-blue.discourse.group/u/Scridgeon)\ **Post date:** [April 8, 2024, 6:05pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/1 "2024-04-08T18:05:59Z")
I’m having an issue starting my guest system in Virtual Machine Manager. I first installed ver 38 of Bluefin-dx and then rebased to the latest version. I created the Virtual Machine on the latest version (39) and it was working fine. I then rebased back to the gts version and that’s when this issue started with the swtpm error message. I rebased back to version 39 hoping it was the version downgrade that caused the problem but the swtpm error persists. Can someone help me get this fixed? I need the Virtual Machine functioning for work. Here’s the error message from VMM when running ‘sudo virsh start image\_name’. Error starting domain: operation failed: swtpm died and reported: libvirt: error : cannot execute binary /usr/bin/swtpm: Permission denied Traceback (most recent call last): File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 72, in cb\_wrapper callback(asyncjob, \*args, \*\*kwargs) File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 108, in tmpcb callback(\*args, \*\*kwargs) File “/usr/share/virt-manager/virtManager/object/libvirtobject.py”, line 57, in newfn ret = fn(self, \*args, \*\*kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^ File “/usr/share/virt-manager/virtManager/object/domain.py”, line 1402, in startup self.\_backend.create() File “/usr/lib64/python3.12/site-packages/libvirt.py”, line 1373, in create raise libvirtError(‘virDomainCreate() failed’) libvirt.libvirtError: operation failed: swtpm died and reported: libvirt: error : cannot execute binary /usr/bin/swtpm: Permission denied ---
**Author:** ![m2Giles](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/m2giles/32/471_2.png) [@m2Giles](https://universal-blue.discourse.group/u/m2Giles)\ **Post date:** [April 9, 2024, 3:55pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/2 "2024-04-09T15:55:29Z")
check what is the SELinux fcontexts for /usr/bin/swtpm. We have a service for applying the right contexts on boot called swtpm-workaround.service in -dx. ---
**Author:** ![Scridgeon](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/scridgeon/32/1142_2.png) [@Scridgeon](https://universal-blue.discourse.group/u/Scridgeon)\ **Post date:** [April 9, 2024, 4:21pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/3 "2024-04-09T16:21:16Z")
Here’s what I’m getting by running: matchpathcon -V /usr/bin/swtpm /usr/bin/swtpm has context system\_u:object\_r:bin\_t:s0, should be system\_u:object\_r:swtpm\_exec\_t:s0 ---
**Author:** ![m2Giles](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/m2giles/32/471_2.png) [@m2Giles](https://universal-blue.discourse.group/u/m2Giles)\ **Post date:** [April 10, 2024, 6:56pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/4 "2024-04-10T18:56:18Z")
That is correct. However, try checking with ls -lZ /usr/bin/swtpm as well. Please check the logs for swtpm in /var/log/swtpm as well. ---
**Author:** ![Scridgeon](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/scridgeon/32/1142_2.png) [@Scridgeon](https://universal-blue.discourse.group/u/Scridgeon)\ **Post date:** [April 11, 2024, 4:45pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/5 "2024-04-11T16:45:02Z")
Here is the output of ls -lZ /usr/bin/swtpm: -rwxr-xr-x. 5 root root system\_u:object\_r:bin\_t:s0 42136 Dec 31 1969 /usr/bin/swtpm I compared both the matchpathcon and ls commands against a fresh install in a VM and the permissions are the same between my system and the VM. I don’t see any errors in the swtpm log. ```auto Starting vTPM manufacturing as tss:tss @ Mon 08 Apr 2024 10:57:17 AM PDT Successfully created RSA 2048 EK with handle 0x81010001. Invoking /usr/bin/swtpm_localca --type ek --ek aef3d8fcaaf2336adb92946a6dbde31a3c8049db7adb99eb8cf567a7586a7c73a7f24bd1ec472455b0723d326e592c6a205e53455e61be73c46c76a943a6a9c0e775808324d4016ac89a6f73c8ee2a5a3741fea2690f16c493f3bcfb09f9381454ef202cbf023a2982c91815aa5a4d2128898338ded2ed9a1ba9bf4c467bdac424c6ce3c75dd63bacbbd4e73b4b9235bb1cad9210da7022739fc86a9d44dd0699ffcbe7abce231d66a0239fcfc754ed7bb1924db4aadb5e4bf9be70b88abaae1d1ea206d2d3d7a351f967a797cfa04794a5fc9e28fa568b44b54878b554e5c58cb0ece80b39bdab29c1616e5b92309861266113115273bbf45239cb8b7992c17 --dir /tmp/swtpm_setup.certs.5MFDM2 --logfile /var/log/swtpm/libvirt/qemu/RDPWindows-swtpm.log --vmid RDPWindows:c746833a-557d-472f-a7f0-d9baab72e7c0 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options Successfully created EK certificate locally. Invoking /usr/bin/swtpm_localca --type platform --ek aef3d8fcaaf2336adb92946a6dbde31a3c8049db7adb99eb8cf567a7586a7c73a7f24bd1ec472455b0723d326e592c6a205e53455e61be73c46c76a943a6a9c0e775808324d4016ac89a6f73c8ee2a5a3741fea2690f16c493f3bcfb09f9381454ef202cbf023a2982c91815aa5a4d2128898338ded2ed9a1ba9bf4c467bdac424c6ce3c75dd63bacbbd4e73b4b9235bb1cad9210da7022739fc86a9d44dd0699ffcbe7abce231d66a0239fcfc754ed7bb1924db4aadb5e4bf9be70b88abaae1d1ea206d2d3d7a351f967a797cfa04794a5fc9e28fa568b44b54878b554e5c58cb0ece80b39bdab29c1616e5b92309861266113115273bbf45239cb8b7992c17 --dir /tmp/swtpm_setup.certs.5MFDM2 --logfile /var/log/swtpm/libvirt/qemu/RDPWindows-swtpm.log --vmid RDPWindows:c746833a-557d-472f-a7f0-d9baab72e7c0 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options Successfully created platform certificate locally. Successfully created NVRAM area 0x1c00002 for RSA 2048 EK certificate. Successfully created NVRAM area 0x1c08000 for platform certificate. Successfully created ECC EK with handle 0x81010016. Invoking /usr/bin/swtpm_localca --type ek --ek x=8c183acb803a1ef172f9c0b2b870fdfe59bb24aafaf144f8dd17df95b8dea7f1099c2eda43dd8f6fa825cf635d20048b,y=0363309c332e1ca08d5f8d45663cae7dceb37463c8058d1f87e77ff13f2e985078d63a682c0c2072931e67e83c17c188,id=secp384r1 --dir /tmp/swtpm_setup.certs.5MFDM2 --logfile /var/log/swtpm/libvirt/qemu/RDPWindows-swtpm.log --vmid RDPWindows:c746833a-557d-472f-a7f0-d9baab72e7c0 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options Successfully created EK certificate locally. Successfully created NVRAM area 0x1c00016 for ECC EK certificate. Successfully activated PCR banks sha256 among sha1,sha256,sha384,sha512. Successfully authored TPM state. Ending vTPM manufacturing @ Mon 08 Apr 2024 10:57:17 AM PDT ``` ---
**Author:** ![m2Giles](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/m2giles/32/471_2.png) [@m2Giles](https://universal-blue.discourse.group/u/m2Giles)\ **Post date:** [April 11, 2024, 4:49pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/6 "2024-04-11T16:49:11Z")
`ls -lZ` is showing that swtpm does not have the right label. Do you have our swtpm-workaround.service disabled? That relabels swtpm on boot. ---
**Author:** ![Scridgeon](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/scridgeon/32/1142_2.png) [@Scridgeon](https://universal-blue.discourse.group/u/Scridgeon)\ **Post date:** [April 11, 2024, 6:40pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/7 "2024-04-11T18:40:09Z")
> [@m2Giles](#): > > swtpm-workaround.service That was the issue. The swtpm-workaround.service was not enabled. I fixed that and I no longer have the permission error. Thank you for helping me sort this out. ---
**Author:** ![darkghosthunter](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/darkghosthunter/32/703_2.png) [@darkghosthunter](https://universal-blue.discourse.group/u/darkghosthunter)\ **Post date:** [May 24, 2024, 3:24am UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/8 "2024-05-24T03:24:25Z")
I can confirm it also happened on my Bluefin that rebased to `:latest` (with Fedora 40). Well, my initial problem was that `libvirt` didn’t have permissions to create a log on `/var/log/libvirt`, and after fixing that, the `swtpm` error appeared. I had to use these commands to fix the permissions for SELinux when trying to use VMM (or any virtual machine at all). ``` sudo restorecon -rv /var/log/libvirt/ systemctl restart swtpm-workaround.service ``` The `swtpm-workaround.service` was enabled and running, but for some reason the problem persisted until I restarted it with `restart`. ---
**Author:** ![m2Giles](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/m2giles/32/471_2.png) [@m2Giles](https://universal-blue.discourse.group/u/m2Giles)\ **Post date:** [May 24, 2024, 7:48pm UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/9 "2024-05-24T19:48:15Z")
Looks like a few people have run into this error. We can probably setup something to auto run this on boot. Swtpm and VMs are pretty critical for the -dx experience. ---
**Author:** ![darkghosthunter](https://yyz2.discourse-cdn.com/free1/user_avatar/universal-blue.discourse.group/darkghosthunter/32/703_2.png) [@darkghosthunter](https://universal-blue.discourse.group/u/darkghosthunter)\ **Post date:** [June 12, 2024, 6:12am UTC](https://universal-blue.discourse.group/t/swtpm-permission-denied/1035/10 "2024-06-12T06:12:47Z")
If someone stumbles upon not being able to _enable_ the network in VMM because it can’t create a folder below `libvirt`, you can apply the same SELinux command to it. ```shell sudo restorecon -rv /var/lib/libvirt ```