LizardByte
(Linux) unable to create a virtual Dualshock 5 controller: Permission denied
Is there an existing issue for this?
- [x] I have searched the existing issues
Is your issue described in the documentation?
- [x] I have read the documentation
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
When running v2025.325.122632 of the Sunshine client on Linux, connect a Dualshock/Dualsense 5 controller via Bluetooth to an Android TV device. Upon opening the client, the Sunshine process will output:
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Info: Gamepad 0 will be DualSense 5 controller (manual selection)
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Warning: Gamepad 0 is emulating a DualShock 5 controller, but the client gamepad doesn't have motion sensors active
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Warning: Gamepad 0 is emulating a DualShock 5 controller, but the client gamepad doesn't have a touchpad
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Warning: Unable to create virtual DualShock 5 controller: Permission denied
The controller does not work or send inputs to the server.
Expected Behavior
A virtual controller should be created successfully, allowing the server's Steam interface to be navigated.
Additional Context
I have installed using the sunshine-beta-bin AUR package in order to get the most recent changes from 2cd4b1b
Host Operating System
Linux
Operating System Version
6.4.12-arch1-1
Architecture
amd64/x86_64
Sunshine commit or version
v2025.325.122632
Package
Linux - AUR (Third Party)
GPU Type
AMD
GPU Model
AMD Radeon RX 5700 XT
GPU Driver/Mesa Version
Mesa 25.0.2-arch1.2
Capture Method
KMS (Linux)
Config
gamepad = ds5
output_name = 1
Apps
Relevant log output
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.737]: Warning: Gamepad 0 is emulating a DualShock 5 controller, but the client gamepad doesn't have a touchpad
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.737]: Warning: Unable to create virtual DualShock 5 controller: Permission denied
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.746]: Info: Gamepad 0 will be DualSense 5 controller (manual selection)
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.746]: Warning: Gamepad 0 is emulating a DualShock 5 controller, but the client gamepad doesn't have motion sensors active
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.746]: Warning: Gamepad 0 is emulating a DualShock 5 controller, but the client gamepad doesn't have a touchpad
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.746]: Warning: Unable to create virtual DualShock 5 controller: Permission denied
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Info: Gamepad 0 will be DualSense 5 controller (manual selection)
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Warning: Gamepad 0 is emulating a DualShock 5 controller, but the client gamepad doesn't have motion sensors active
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Warning: Gamepad 0 is emulating a DualShock 5 controller, but the client gamepad doesn't have a touchpad
Mar 25 21:08:02 archlinux sunshine[292138]: [2025-03-25 21:08:02.816]: Warning: Unable to create virtual DualShock 5 controller: Permission denied
https://docs.lizardbyte.dev/projects/sunshine/master/md_docs_2troubleshooting.html#input-not-working
https://docs.lizardbyte.dev/projects/sunshine/master/md_docs_2troubleshooting.html#input-not-working
The issue persists through running sudo usermod -aG input $USER and restarting the machine
Permission denied when making a DualSense controller is most likely tied to /dev/uhid, with the right udev rules you should have something like:
ls -la /dev/uhid
crw-rw----+ 1 root root 10, 239 Mar 26 20:28 /dev/uhid
Notice that + at the end? When I call getfacl /dev/uhid my user is listed as rw- can you check if that's the case for you too?
If that's not the case, make sure that you have installed the udev rules and reboot the system.
Running getfacl /dev/uhid does show the correct rw- you described, but for some reason, my udev rules were not showing the +. I was able to get the correct udev rules by running
sudo setfacl -m g:input:rw /dev/uhid
It does not persist across boot, but the controller works correctly. I am unsure what is causing the udev rules to not be set automatically via the post-install script or via sudo usermod -aG input $USER, but at least I am able to work around the issue for the time being.
/dev/uhid is usually not exposed to the input group (see root root in my output above) so doing usermod wouldn't help there.
Could it be that you have some outdated udev rules?
It's only very recently that Sunshine started using uhid for properly implementing virtual DualSense support; can you check that the following is present in your 60-sunshine.rules rules
# Allows Sunshine to access /dev/uhid
KERNEL=="uhid", TAG+="uaccess"
?
Yes, it is included
$ cat /usr/lib/udev/rules.d/60-sunshine.rules
# Allows Sunshine to acces /dev/uinput
KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", TAG+="uaccess"
# Allows Sunshine to access /dev/uhid
KERNEL=="uhid", TAG+="uaccess"
# Joypads
KERNEL=="hidraw*" ATTRS{name}=="Sunshine PS5 (virtual) pad" MODE="0660", TAG+="uaccess"
SUBSYSTEMS=="input", ATTRS{name}=="Sunshine X-Box One (virtual) pad", MODE="0660", TAG+="uaccess"
SUBSYSTEMS=="input", ATTRS{name}=="Sunshine gamepad (virtual) motion sensors", MODE="0660", TAG+="uaccess"
SUBSYSTEMS=="input", ATTRS{name}=="Sunshine Nintendo (virtual) pad", MODE="0660", TAG+="uaccess"
The issue seems to be that the udev rules on Arch don't apply to the /dev/uhid device immediately. The rules are present, but after boot 'getfacl /dev/uhid' for the logged in user still shows no permissions. I suspect this is because the module is not actually loaded when udev runs as described here.
Forcing the module to load with an appropriate entry in /etc/modules.conf.d/modules.conf does show the right permissions after boot with 'getfacl /dev/uhid'. This is my workaround, and does allow simulated DualSense.
I believe (but have not fully retested) that it can be made to work by having the uhid module load for Sunshine once and then forcing udev to reload rules/trigger (udevadm control --reload && udevadm trigger). Since reloaded udev rules also happens as a part of Sunshine updates, it leads to confusing results where sometimes it works until the next reboot.
I had this problem too and it was fixed by loading the uhid module at boot as stated by the @axxelh (thanks btw).
For others having this issue, the other thing you'll see is "Warning: Gamepad ds5 is disabled due to Permission denied" in the sunshine log.
You can confirm the problem with the following (notice the permissions are crw-------, not crw-rw----+ which is what they should be.)
$ ls -la /dev/uhid
crw------- 1 root root 10, 239 Apr 22 17:25 /dev/uhid
$ udevadm info /dev/uhid
Unknown device "/dev/uhid": No such device
The workaround to load uhid on boot can be done with:
echo "uhid" | sudo tee /etc/modules-load.d/uhid.conf
and to enable it manually right now:
sudo modprobe uhid
After which you should see this instead:
$ ls -la /dev/uhid
crw-rw----+ 1 root root 10, 239 Apr 22 17:26 /dev/uhid
$ udevadm info /dev/uhid
P: /devices/virtual/misc/uhid
M: uhid
J: c10:239
U: misc
D: c 10:239
N: uhid
L: 0
E: DEVPATH=/devices/virtual/misc/uhid
E: DEVNAME=/dev/uhid
E: MAJOR=10
E: MINOR=239
E: SUBSYSTEM=misc
E: USEC_INITIALIZED=111088546
E: TAGS=:seat:uaccess:
E: CURRENT_TAGS=:seat:uaccess:
Restart sunshine and you shouldn't see that warning any more in the logs and your controller should work.
Thanks for the workaround @axxelh
See also: #2906 That PR might be necessary after all. (I'm a bit out of the loop though.)
@gschintgen do you want me to re-open it?
I do, though I'm not sure if and when I'll have the time to update and re-test it.
