Repository: pwr-Solaar/Solaar

Issue:
Permissions error each start
Hi,

I've got a Permissions error each start of my system:

> Permissions error
Found a Logitech Receiver (/dev/hidraw3), but did not have permission to open it.
If you've just installed Solaar, try removing the receiver and plugging it back in.

I must remove the receiver and plug it back for a full working of Solaar

System:    Host: mint Kernel: 4.4.0-21-generic x86_64 (64 bit gcc: 5.3.1)
Desktop: Cinnamon 3.4.6 (Gtk 3.18.9-1ubuntu3.3) dm: mdm Distro: Linux Mint 18.2 Sonya

Any idea ?

PS: I like Solaar because it solves the "Key 5 automatically pressed on some Logitech wireless keyboards" problem with my Logitech K800 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1579190) and more surprising: https://github.com/pwr/Solaar/issues/264


Discussion:
This seems to be related to udev and not with solaar. Please, send result of `ls -l /dev/hidraw*` before (when permission problem occurs) and after, when you removed and reinserted receiver.

thanks.
Thank you for your answer.

Here is when the problem occurs:

$ ls -l /dev/hidraw*
crw-rw----+ 1 root root 246, 0 oct.  19  2017 /dev/hidraw0
crw-rw----+ 1 root root 246, 1 oct.  19  2017 /dev/hidraw1
crw-------  1 root root 246, 2 oct.  19  2017 /dev/hidraw2
crw-------  1 root root 246, 3 oct.  19  2017 /dev/hidraw3

and after

$ ls -l /dev/hidraw*
crw-rw----+ 1 root root 246, 0 oct.  19 18:24 /dev/hidraw0
crw-rw----+ 1 root root 246, 1 oct.  19 18:24 /dev/hidraw1
crw-------  1 root root 246, 2 oct.  19  2017 /dev/hidraw2
crw-------  1 root root 246, 3 oct.  19  2017 /dev/hidraw3



What does `getfacl /dev/hidraw[01]` say?
$ getfacl /dev/hidraw[01]
getfacl : suppression du premier « / » des noms de chemins absolus
\# file: dev/hidraw0
\# owner: root
\# group: root
user::rw-
user:olivier:rw-
group::---
mask::rw-
other::---

\# file: dev/hidraw1
\# owner: root
\# group: root
user::rw-
user:olivier:rw-
group::---
mask::rw-
other::---


Anyone can help ?
this getfacl was before or after permission issue solved by reinserting dongle?
Results before:
```
$ ls -l /dev/hidraw*
crw-rw----+ 1 root root 246, 0 janv. 24  2018 /dev/hidraw0
crw-rw----+ 1 root root 246, 1 janv. 24  2018 /dev/hidraw1
crw-------  1 root root 246, 2 janv. 24  2018 /dev/hidraw2
crw-------  1 root root 246, 3 janv. 24  2018 /dev/hidraw3
olivier@antec-mint ~ $ getfacl /dev/hidraw[01]
getfacl : suppression du premier « / » des noms de chemins absolus
# file: dev/hidraw0
# owner: root
# group: root
user::rw-
user:olivier:rw-
group::---
mask::rw-
other::---

# file: dev/hidraw1
# owner: root
# group: root
user::rw-
user:olivier:rw-
group::---
mask::rw-
other::---
```

and after:
```
$ ls -l /dev/hidraw*
crw-rw----+ 1 root root 246, 0 janv. 24 15:16 /dev/hidraw0
crw-rw----+ 1 root root 246, 1 janv. 24 15:16 /dev/hidraw1
crw-------  1 root root 246, 2 janv. 24 15:16 /dev/hidraw2
crw-------  1 root root 246, 3 janv. 24 15:16 /dev/hidraw3
olivier@antec-mint ~ $ getfacl /dev/hidraw[01]
getfacl : suppression du premier « / » des noms de chemins absolus
# file: dev/hidraw0
# owner: root
# group: root
user::rw-
user:olivier:rw-
group::---
mask::rw-
other::---

# file: dev/hidraw1
# owner: root
# group: root
user::rw-
user:olivier:rw-
group::---
mask::rw-
other::---
```
The problem still persists.
Something interesting: This error only shows up on ONE of my 3 unified recievers.
ls -l /dev/hidraw*
returns the same values no matter which one is plugged in, and
getfacl /dev/hidraw[04] (mine shows up as 3 & 4) show the same rw values no matter which of the receivers is plugged in.

Two of the receivers work perfectly, so I'm supposing that it's the 3rd receiver hardware or firmware that is messed up.

My advice would be to acquire another unified receiver and try again.

I'll post more if I can somehow manage to fix the broken one.
There have been several changes to solaar over the past couple of years so this issue may have already been addressed.

If you are still using solaar and this issue has not been resolved please download and run the current version from this github repository. If the problem still persists add a new comment here, providing the output of `solaar -V` and `solaar show` and any new information about the issue.

If you are still using solaar you should be able to download and run its current version (in Linux) as follows:

1. Install git on your machine if it is not already installed. This is generally done via `sudo apt install git` or `sudo dnf install git`
2. Change to a directory where you want the code.
3. Download solaar via `git clone https://github.com/pwr-Solaar/Solaar.git`
4. Run solaar via `Solaar/bin/solaar`

For more information on installing solaar from github see https://github.com/pwr-Solaar/Solaar/blob/master/docs/installation.md

Closing due to no response from original poster.
I seem to be experiencing this issue all of a sudden.  I've been using Solaar for a couple of years now and after a rather large system update (Fedora 31 KDE) I am getting the error listed above.  However I only get it when I plug my unifying receiver into the external hub (USB-C hub that also powers my laptop).  If I plug the unifying receiver directly into the laptop, it works correctly.  I'm guessing the change is not something wrong with Solaar, but something in an update today.  I just don't know where to get started looking.

Thanks for the help.
I think this has to do with device permissions.  Solaar uses access control lists set up by udev to allow it to read from and write to the receiver.  If everything is set up OK you should see `getfacl /dev/hidraw*` showing a line like

> user:pfps:rw-

(with your userid instead of pfps) for your receiver's raw device (the "Device path" from `solaar show`, which may change when you move the receiver).
So please try this both with the receiver directly connected to your computer and connected through the hub and report back.

Thanks for the help!  Here is what I get when I run that with the unifying receiver plugged directly in to the laptop:

```
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw0
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw1
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw2
# owner: root
# group: root
user::rw-
user:nathan:rw-
group::---
mask::rw-
other::---

# file: dev/hidraw3
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw4
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw5
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw6
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw7
# owner: root
# group: root
user::rw-
group::---
other::---
```

And then completely unplugged:
```
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw0
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw1
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw3
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw7
# owner: root
# group: root
user::rw-
group::---
other::---

```
And then when plugged into the docking station:
```
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw0
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw1
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw2
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw3
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw4
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw5
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw6
# owner: root
# group: root
user::rw-
group::---
other::---

# file: dev/hidraw7
# owner: root
# group: root
user::rw-
group::---
other::---

```

What I notice is that when it is plugged into the laptop directly, it has user "nathan" (me) with read/write on hidraw2.  But when it is unplugged, half of the devices go away.  When it is plugged into the docking station, I have all of the devices back, but no user with permissions anywhere.  I just don't know how to interpret or fix that.
So this definitely looks like a permissions problem.  It also seems that you are running a modern kernel so that all the devices have their own hid interface.  It would have been a bit better to have direct evidence that the receiver is hidraw2 in both situations (`solaar show` will provide this).  When the receiver is plugged into the hub somehow the solaar udev rule isn't firing so the required permissions are not set up.   I don't have this problem with my USBc (non-thunderbolt) hub.

I know next to nothing about udev rule programming so I can't help on this.  Help would be appreciated here. 

Have you ever been able to have Solaar work with the receiver connected via the hub?
Perhaps upgrading your system removed the Solaar udev rules.  Check for the file 42-logitech-unify-permissions.rules in a udev rules directory, likely /usr/lib/udev/rules.d

If you can't find this, re-installing Solaar might fix the problem.
Few questions - let me start with those.
Yes, I have a current kernel.  That was one of the things that was updated recently.  Specifically:
`5.4.17-200.fc31.x86_64`
I have successfully used the receiver on the docking station for about 18 months now - yes.
I have also already uninstalled and reinstalled Solaar, so I don't know if that might still be the issue with the udev rules.
I'll supply the information you asked for down below, but please let me know if I missed anything that would be helpful.

solaar show with it plugged in to the laptop (and yes, it is the keyboard that I'm interested in.  I no longer use the M570 trackball and the mouse is for when I'm travelling only.  I use a bluetooth trackball at my desk now.):
```
Unifying Receiver
  Device path  : /dev/hidraw1
  USB id       : 046d:c52b
  Serial       : 6A0195A2
    Firmware   : 12.08.B0030
    Bootloader : 02.15
    Other      : AA.AA
  Has 3 paired device(s) out of a maximum of 6.
  Notifications: wireless, software present (0x000900)
  Device activity counters: 1=86

  1: Wireless Solar Keyboard K750
     Codename     : K750
     Kind         : keyboard
     Wireless PID : 4002
     Protocol     : HID++ 2.0
     Polling rate : 20 ms (50Hz)
     Serial number: D170DF71
     The power switch is located on the edge of top right corner.
     Battery status unavailable.

  2: Wireless Trackball M570
     Codename     : M570
     Kind         : trackball
     Wireless PID : 1028
     Protocol     : unknown (device is offline)
     Polling rate : 8 ms (125Hz)
     Serial number: 8370832E
     The power switch is located on the base.
     Battery: unknown (device is offline).

  3: M215 2nd Gen
     Codename     : M215 2nd Gen
     Kind         : mouse
     Wireless PID : 401B
     Protocol     : unknown (device is offline)
     Polling rate : 8 ms (125Hz)
     Serial number: 6747B30C
     The power switch is located on the base.
     Battery: unknown (device is offline).
```
solaar show unplugged:
`solaar: error: Logitech receiver not found`

solaar show plugged in to the docking station:
`Solaar: error: [Errno 13] Permission denied: '/dev/hidraw0'`


Moving on to the logitech unify permissions:
```
nathan@XPS13-9370:/usr/lib/udev/rules.d$ ll 42*
-rw-r--r--. 1 root root 2306 Aug 28 07:16 42-logitech-unify-permissions.rules
```
It exists.  I'm not sure what to look at beyond that though.
Just for S&G, I booted the prior kernel (that worked previously) and experienced the same issues.

OK, I'm stumped.  I'm even running the same kernel.  I'll try with my USBc hub, but it won't be until Friday or the weekend.
I appreciate the time.  And of course please let me know if you need me to try anything.  My work around of plugging it in to the laptop isn't really all that bad - just mildly annoying.  But I'm nervous that there might be something else that could suddenly be a big deal for a lot of folks.
There are a couple of things that can be done that might shed a bit of light on the problem without actually instrumenting the udev rules.   
To see what udev did (more or less) you can do `udevadm info /dev/hidrawX` where X is the device for your receiver.  I see 

>
idefix ~> udevadm info /dev/hidraw0
P: /devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/0003:046D:C534.000B/hidraw/hidraw0
N: hidraw0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-7/3-7:1.0/0003:046D:C534.000B/hidraw/hidraw0
E: DEVNAME=/dev/hidraw0
E: MAJOR=241
E: MINOR=0
E: SUBSYSTEM=hidraw
E: USEC_INITIALIZED=48692901067
E: ID_PATH=pci-0000:00:14.0-usb-0:7:1.0
E: ID_PATH_TAG=pci-0000_00_14_0-usb-0_7_1_0
E: ID_FOR_SEAT=hidraw-pci-0000_00_14_0-usb-0_7_1_0
E: TAGS=:uaccess:seat:

You can see that this is the hidraw device for my 046d:c534 receiver and the last line shows that udev added seat control for the device.

You can call see what information went into udev for the device in /sys/class/hidraw/hidrawX/device/uevent.   I see 

idefix ~> cat /sys/class/hidraw/hidraw0/device/uevent
DRIVER=logitech-djreceiver
HID_ID=0003:0000046D:0000C534
HID_NAME=Logitech USB Receiver
HID_PHYS=usb-0000:00:14.0-7/input0
HID_UNIQ=
MODALIAS=hid:b0003g0001v0000046Dp0000C534

This shows a bit more information about how the device is being handled, notably the driver that is being used.  In fact, it would be useful to see the output for all hidraw devices, so please send back the output from `cat /sys/class/hidraw/hidraw*/device/uevent`

You got it.  And I assume sticking with the 3 outputs still is helpful (let me know if not).

cat plugged in to the laptop:
```
DRIVER=logitech-djreceiver
HID_ID=0003:0000046D:0000C52B
HID_NAME=Logitech USB Receiver
HID_PHYS=usb-0000:39:00.0-1/input2
HID_UNIQ=
MODALIAS=hid:b0003g0001v0000046Dp0000C52B
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:00004002
HID_NAME=Logitech K750
HID_PHYS=usb-0000:39:00.0-1/input2:1
HID_UNIQ=4002-d1-70-df-71
MODALIAS=hid:b0003g0102v0000046Dp00004002
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:00001028
HID_NAME=Logitech M570
HID_PHYS=usb-0000:39:00.0-1/input2:2
HID_UNIQ=1028-83-70-83-2e
MODALIAS=hid:b0003g0102v0000046Dp00001028
DRIVER=hid-generic
HID_ID=0003:00000764:00000601
HID_NAME=CPS CP1500PFCLCDa
HID_PHYS=usb-0000:39:00.0-2.1.2/input0
HID_UNIQ=CXXJV2020309
MODALIAS=hid:b0003g0001v00000764p00000601
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:0000401B
HID_NAME=Logitech M215 2nd Gen
HID_PHYS=usb-0000:39:00.0-1/input2:3
HID_UNIQ=401b-67-47-b3-0c
MODALIAS=hid:b0003g0102v0000046Dp0000401B
DRIVER=hid-multitouch
HID_ID=0018:000004F3:000024F0
HID_NAME=ELAN24F0:00 04F3:24F0
HID_PHYS=i2c-ELAN24F0:00
HID_UNIQ=
MODALIAS=hid:b0018g0004v000004F3p000024F0
DRIVER=hid-multitouch
HID_ID=0018:000006CB:000076AF
HID_NAME=DELL07E6:00 06CB:76AF
HID_PHYS=i2c-DELL07E6:00
HID_UNIQ=
MODALIAS=hid:b0018g0004v000006CBp000076AF
DRIVER=hid-generic
HID_ID=0005:0000047D:00008019
HID_NAME=Expert Wireless TB
HID_PHYS=9C:B6:D0:8C:F3:D6
HID_UNIQ=D5:EC:DF:A8:7C:6C
MODALIAS=hid:b0005g0001v0000047Dp00008019
```

Unplugged:
```
DRIVER=hid-generic
HID_ID=0003:00000764:00000601
HID_NAME=CPS CP1500PFCLCDa
HID_PHYS=usb-0000:39:00.0-2.1.2/input0
HID_UNIQ=CXXJV2020309
MODALIAS=hid:b0003g0001v00000764p00000601
DRIVER=hid-multitouch
HID_ID=0018:000004F3:000024F0
HID_NAME=ELAN24F0:00 04F3:24F0
HID_PHYS=i2c-ELAN24F0:00
HID_UNIQ=
MODALIAS=hid:b0018g0004v000004F3p000024F0
DRIVER=hid-multitouch
HID_ID=0018:000006CB:000076AF
HID_NAME=DELL07E6:00 06CB:76AF
HID_PHYS=i2c-DELL07E6:00
HID_UNIQ=
MODALIAS=hid:b0018g0004v000006CBp000076AF
DRIVER=hid-generic
HID_ID=0005:0000047D:00008019
HID_NAME=Expert Wireless TB
HID_PHYS=9C:B6:D0:8C:F3:D6
HID_UNIQ=D5:EC:DF:A8:7C:6C
MODALIAS=hid:b0005g0001v0000047Dp00008019
```

Plugged into the docking station:
```
DRIVER=logitech-djreceiver
HID_ID=0003:0000046D:0000C52B
HID_NAME=Logitech USB Receiver
HID_PHYS=usb-0000:39:00.0-2.1.6/input2
HID_UNIQ=
MODALIAS=hid:b0003g0001v0000046Dp0000C52B
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:00004002
HID_NAME=Logitech K750
HID_PHYS=usb-0000:39:00.0-2.1.6/input2:1
HID_UNIQ=4002-d1-70-df-71
MODALIAS=hid:b0003g0102v0000046Dp00004002
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:00001028
HID_NAME=Logitech M570
HID_PHYS=usb-0000:39:00.0-2.1.6/input2:2
HID_UNIQ=1028-83-70-83-2e
MODALIAS=hid:b0003g0102v0000046Dp00001028
DRIVER=hid-generic
HID_ID=0003:00000764:00000601
HID_NAME=CPS CP1500PFCLCDa
HID_PHYS=usb-0000:39:00.0-2.1.2/input0
HID_UNIQ=CXXJV2020309
MODALIAS=hid:b0003g0001v00000764p00000601
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:0000401B
HID_NAME=Logitech M215 2nd Gen
HID_PHYS=usb-0000:39:00.0-2.1.6/input2:3
HID_UNIQ=401b-67-47-b3-0c
MODALIAS=hid:b0003g0102v0000046Dp0000401B
DRIVER=hid-multitouch
HID_ID=0018:000004F3:000024F0
HID_NAME=ELAN24F0:00 04F3:24F0
HID_PHYS=i2c-ELAN24F0:00
HID_UNIQ=
MODALIAS=hid:b0018g0004v000004F3p000024F0
DRIVER=hid-multitouch
HID_ID=0018:000006CB:000076AF
HID_NAME=DELL07E6:00 06CB:76AF
HID_PHYS=i2c-DELL07E6:00
HID_UNIQ=
MODALIAS=hid:b0018g0004v000006CBp000076AF
DRIVER=hid-generic
HID_ID=0005:0000047D:00008019
HID_NAME=Expert Wireless TB
HID_PHYS=9C:B6:D0:8C:F3:D6
HID_UNIQ=D5:EC:DF:A8:7C:6C
MODALIAS=hid:b0005g0001v0000047Dp00008019
```
Not sure what it means but the difference between the working and non-working plugged in appears to be the HID_PHYS, which I assume is the physical port it's plugged in to?  That's: `HID_PHYS=usb-0000:39:00.0-2.1.6/input2` vs `HID_PHYS=usb-0000:39:00.0-1/input2`
Thanks, this all looks as it should.  Can you also provide the output from `udevadm info /dev/hidraw*` (only) when the receiver is plugged into the docking station? 
Certainly!
```
DRIVER=logitech-djreceiver
HID_ID=0003:0000046D:0000C52B
HID_NAME=Logitech USB Receiver
HID_PHYS=usb-0000:39:00.0-2.1.6/input2
HID_UNIQ=
MODALIAS=hid:b0003g0001v0000046Dp0000C52B
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:00004002
HID_NAME=Logitech K750
HID_PHYS=usb-0000:39:00.0-2.1.6/input2:1
HID_UNIQ=4002-d1-70-df-71
MODALIAS=hid:b0003g0102v0000046Dp00004002
DRIVER=logitech-hidpp-device
HID_ID=0003:0000046D:00001028
HID_NAME=Logitech M570
HID_PHYS=usb-0000:39:00.0-2.1.6/input2:2
HID_UNIQ=1028-83-70-83-2e
MODALIAS=hid:b0003g0102v0000046Dp00001028
DRIVER=hid-generic
HID_NAME=CPS CP1500PFCLCDa
HID_PHYS=usb-0000:39:00.0-2.1.2/input0
MODALIAS=hid:b0003g0001v00000764p00000601
MODALIAS=hid:b0018g0004v000004F3p000024F0
DRIVER=hid-generic
HID_NAME=Expert Wireless TB
E: DEVNAME=/dev/hidraw0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-1/3-1:1.2/0003:046D:C52B.0022/0003:046D:4002.0023/hidraw/hidraw1
E: DEVNAME=/dev/hidraw1
E: SUBSYSTEM=hidraw
L: 0
E: DEVNAME=/dev/hidraw2
L: 0

N: hidraw1
L: 0
E: DEVNAME=/dev/hidraw1

E: MAJOR=241

N: hidraw3
E: MAJOR=241

N: hidraw4
L: 0
E: DEVNAME=/dev/hidraw5
E: DEVNAME=/dev/hidraw6
E: MAJOR=241
E: MINOR=6
E: SUBSYSTEM=hidraw

P: /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0028/hidraw/hidraw0
E: SUBSYSTEM=hidraw
E: ID_PATH=pci-0000:39:00.0-usb-0:2.1.6:1.2
N: hidraw1
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0028/0003:046D:4002.0029/hidraw/hidraw1
E: TAGS=:seat-usb-pci-0000_39_00_0-usb-0_2_1:

P: /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0028/0003:046D:1028.002A/hidraw/hidraw2
N: hidraw2
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0028/0003:046D:1028.002A/hidraw/hidraw2
E: DEVNAME=/dev/hidraw2
E: MAJOR=241
E: MINOR=2
E: SUBSYSTEM=hidraw
E: USEC_INITIALIZED=54424474819
E: ID_SEAT=seat-usb-pci-0000_39_00_0-usb-0_2_1
E: TAGS=:seat-usb-pci-0000_39_00_0-usb-0_2_1:

P: /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.2/3-2.1.2:1.0/0003:0764:0601.0004/hidraw/hidraw3
N: hidraw3
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.2/3-2.1.2:1.0/0003:0764:0601.0004/hidraw/hidraw3
E: DEVNAME=/dev/hidraw3
E: MAJOR=241
E: MINOR=3
E: SUBSYSTEM=hidraw
E: USEC_INITIALIZED=22786089
E: ID_SEAT=seat-usb-pci-0000_39_00_0-usb-0_2_1
E: TAGS=:seat-usb-pci-0000_39_00_0-usb-0_2_1:

P: /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0028/0003:046D:401B.002B/hidraw/hidraw4
N: hidraw4
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0028/0003:046D:401B.002B/hidraw/hidraw4
E: DEVNAME=/dev/hidraw4
E: MAJOR=241
E: MINOR=4
E: SUBSYSTEM=hidraw
E: USEC_INITIALIZED=54424477171
E: ID_SEAT=seat-usb-pci-0000_39_00_0-usb-0_2_1
E: TAGS=:seat-usb-pci-0000_39_00_0-usb-0_2_1:

P: /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-7/i2c-ELAN24F0:00/0018:04F3:24F0.0008/hidraw/hidraw5
N: hidraw5
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-7/i2c-ELAN24F0:00/0018:04F3:24F0.0008/hidraw/hidraw5
E: DEVNAME=/dev/hidraw5
E: MAJOR=241
E: MINOR=5
E: SUBSYSTEM=hidraw

P: /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0009/hidraw/hidraw6
N: hidraw6
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0009/hidraw/hidraw6
E: DEVNAME=/dev/hidraw6
E: MAJOR=241
E: MINOR=6
E: SUBSYSTEM=hidraw

P: /devices/virtual/misc/uhid/0005:047D:8019.0019/hidraw/hidraw7
N: hidraw7
L: 0
E: DEVPATH=/devices/virtual/misc/uhid/0005:047D:8019.0019/hidraw/hidraw7
E: DEVNAME=/dev/hidraw7
E: MAJOR=241
E: MINOR=7
E: SUBSYSTEM=hidraw
```
Thanks.  This sure looks like the udev rule didn't fire, but why?   I'll see what happens with my docking station.
@NathanDeckinga That output from udevadm looks weird.  There should be blocks of information (one for each device) and in each block there should only be lines looking like 
X: ...
where X is a single upper-case letter.

Could you try `udevadm info /dev/hidrawZ` where Z is each one of your /dev/hidrawZ devices that is a receiver?  (You can err on the side of permissiveness.)
@NathanDeckinga I'm using my docking station and everything is looking fine. So I am a bit stumped.
So - tell me if I found the right pattern to get this information.  I did a `solaar show` to find the device that was the correct one (unifying receiver).  That showed it was hidraw0 this time.  Then I grabbed the data you asked for and here is laptop:
```
nathan@XPS13-9370:~$ udevadm info /dev/hidraw0
P: /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-1/3-1:1.2/0003:046D:C52B.002E/hidraw/hidraw0
N: hidraw0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-1/3-1:1.2/0003:046D:C52B.002E/hidraw/hidraw0
E: DEVNAME=/dev/hidraw0
E: MAJOR=241
E: MINOR=0
E: SUBSYSTEM=hidraw
E: USEC_INITIALIZED=54465380953
E: ID_PATH=pci-0000:39:00.0-usb-0:1:1.2
E: ID_PATH_TAG=pci-0000_39_00_0-usb-0_1_1_2
E: ID_FOR_SEAT=hidraw-pci-0000_39_00_0-usb-0_1_1_2
E: TAGS=:uaccess:seat:
```

and docking station:
```
1 nathan@XPS13-9370:~$ udevadm info /dev/hidraw0
P: /devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0038/hidraw/hidraw0
N: hidraw0
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/0000:04:02.0/0000:39:00.0/usb3/3-2/3-2.1/3-2.1.6/3-2.1.6:1.2/0003:046D:C52B.0038/hidraw/hidraw0
E: DEVNAME=/dev/hidraw0
E: MAJOR=241
E: MINOR=0
E: SUBSYSTEM=hidraw
E: USEC_INITIALIZED=230688936009
E: ID_PATH=pci-0000:39:00.0-usb-0:2.1.6:1.2
E: ID_PATH_TAG=pci-0000_39_00_0-usb-0_2_1_6_1_2
E: ID_FOR_SEAT=hidraw-pci-0000_39_00_0-usb-0_2_1_6_1_2
E: ID_SEAT=seat-usb-pci-0000_39_00_0-usb-0_2_1
E: TAGS=:seat-usb-pci-0000_39_00_0-usb-0_2_1:uaccess:seat
```
I'm so far out of what I understand at this point, I'm just trying to follow instructions.  Let me know if I should have done something different.
@NathanDeckinga You did good. :-)  I'm also very far from an expert here.

But now it looks like the udev rule worked.  The entire point of the udev rule is to add :uaccess:seat to the TAGS information.  So if you do `ls -l /dev/hidraw*` you should see a + on the line for /dev/hidraw0, and `getfacl /dev/hidraw0` should have a line with your  userid on it, and `solaar show` should not produce any errors.  Please try these and report back.

If you get an error from `solaar show` try `solaar -D /dev/hidraw0`
Well, you say it fired and I'll believe that.  But I did still get the same error message.  And even despite not being an expert - thanks.

I did actually run solar show right before running udevadm and I did get the error of:
`Solaar: error: [Errno 13] Permission denied: '/dev/hidraw0'`

Let me start over from the beginning just to verify.  Running 
```
ls -l /dev/hidraw*
getfacl /dev/hidraw0
solaar show
solaar -D /dev/hidraw0
```
when the dongle is plugged into the laptop works as expected and returns the data you indicated.  Switching over to the docking station returns (in the order listed above):
```
nathan@XPS13-9370:~$ ls -l /dev/hidraw*
crw-------. 1 root root 241, 0 Feb 15 10:12 /dev/hidraw0
crw-------. 1 root root 241, 1 Feb 15 10:12 /dev/hidraw1
crw-------. 1 root root 241, 2 Feb 15 10:12 /dev/hidraw2
crw-------. 1 root root 241, 3 Feb 12 17:21 /dev/hidraw3
crw-------. 1 root root 241, 4 Feb 15 10:12 /dev/hidraw4
crw-------. 1 root root 241, 5 Feb 12 17:21 /dev/hidraw5
crw-------. 1 root root 241, 6 Feb 12 17:21 /dev/hidraw6
crw-------. 1 root root 241, 7 Feb 15 08:34 /dev/hidraw7

130 nathan@XPS13-9370:~$ getfacl /dev/hidraw0
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw0
# owner: root
# group: root
user::rw-
group::---
other::---

nathan@XPS13-9370:~$ solaar show
Solaar: error: [Errno 13] Permission denied: '/dev/hidraw0'

1 nathan@XPS13-9370:~$ solaar -D /dev/hidraw0
<blank solaar box>
```
@NathanDeckinga Curioser and curioser.
So it looks like sometimes the udev rule fires and sometimes it doesn't.  That's totally beyond my udev knowledge.  So it's now time for bandaids.  
You should be able to get solaar to work by setting the acl for /dev/hidrawX yourself.  One problem is going to be figuring out which X to use.  I'm not sure if there is a really good way to do this, but `cat /sys/class/hidraw/hidrawX/device/uevent` will tell you what udev thinks about the device. You can use this information to determine whether you have the right X.
Then you need to add yourself to the ACL for the device via `sudo setfacl -m "u:USER:rw" /dev/hidrawX` where USER is your user id.  
The solar *should*  work fine - but you have to do this every time you change your hardware setup and on every boot, and maybe even more often.
The other bandaid would be to run solaar as `sudo solaar`.  I hesitate to recommend this, though.
Well, that bandaid doesn't seem to be working for me and I very much agree that running things as root should be avoided.  I would rather just leave this plugged in to my laptop directly than run things as root.  So... Consider me stumped as well.

Resolving patch:
diff --git a/lib/solaar/listener.py b/lib/solaar/listener.py
--- a/lib/solaar/listener.py
+++ b/lib/solaar/listener.py
@@ -343,4 +343,13 @@ def _process_receiver_event(action, device_info):
 			_start(device_info)
 		except OSError:
 			# permission error, ignore this path for now
-			_error_callback('permissions', device_info.path)
+			# If receiver has extended ACL but not writable then it is for another seat.
+			# (It would be easier to use pylibacl but adding the pylibacl dependencies
+			# for this special case is not good.)
+			try: 
+				import subprocess, re
+				output = subprocess.check_output(['/usr/bin/getfacl', '-p', device_info.path])
+				if not re.search(b'user:.+:',output) :
+					_error_callback('permissions', device_info.path)
+			except:
+				_error_callback('permissions', device_info.path)


Test patch: