I'm running Sticky Finger's Kali Pi on a Pi 2 with the Adafruit Ultimate GPS HAT connected.

The HAT is accessible from the OS under /dev/ttyAMA0, but the permission is set to root:tty rw--w---. With the proper permission set (with sudo chmod ...), I can view the contents without problems.

The problem is that the permission is reset every reboot to the original one.

additionally, for security reasons I am using a non-privileged user and have a created a new group gpsgrp to give it access to the GPS module.

I would prefer not to simply give this user access to the tty and all the devices this group has access to.

How do I set the permission for this device permanently at boot?


You put a file in /etc/udev/rules.d/ typically with a name starting with a number which specifies the order of operation. Personally, I use 73 for all my USB devices. It should have a content like one of these groups:

ACTION=="add", KERNEL=="ttyUSB*", \
    ATTRS{serial}=="A602HSHI", \
    MODE="0666", \

ACTION=="add", KERNEL=="ttyUSB*", \
    ATTRS{idVendor}=="067b", \
    ATTRS{idProduct}=="2303", \
    MODE="0666", \

Though in your case, you need to change the value of KERNEL== to "ttyAMA*", and find the appropriate ATTRS{...} tests to match your device. (lsusb should be able to show this data.)

Once there is a match, the single = entries tell it what changes to make. MODE= sets the mode. SYMLINK+= adds an additional name (which is very useful if you start adding additional devices and the order can vary). OWNER= and GROUP= can be used. Read the "udev" man page for more details.

  • There's a rule in my udev/rules.d that includes that lines: SUBSYSTEM=="gpio",PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath'" as well as KERNEL=="ttyAMA[01]",PROGRAM="/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0 $ALIASES/serial0 then echo 0; elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 1; fi'",SYMLINK+="serial%c".
    – user942937
    Feb 5 '20 at 19:23
  • I have tried adding the relevant OWNER,GROUP, and MODE values to the section under KERNEL=="ttyAMA[01]" as well as creating a new rule written similar to your example (minus the ATTRS{idProduct} and ATTRS{idVendors}. I could not find this information. Maybe because the module is attached to the GPIO instead of being plugged into a USB port?). Neither method worked and I'm still stuck with crw--w---- root:tty.
    – user942937
    Feb 5 '20 at 19:29
  • well, if it shows up in the output of lsusb then it should include "ID <vendor>:<product>" If it doesn't, it isn't USB and is coming from some other subsystem. If you can do an ls -l on the device and see major and minor device numbers, try doing cd /sys/dev/char/<major>:<minor>. At this point, file "uevent" gives you the local properties you can match, and the parent directories some additional matchable properties.
    – David G.
    Feb 5 '20 at 20:54
  • The uevent of the device only contains, the DEVNAME, MAJOR, and MINOR values. In any case, identifying the device doesn't seem to be a problem. For good measure, I have tried deleting 99-com.rules, leaving me only with the rule I created and 73-usb-net-by-mac.rules which is apparently a link to /dev/null. The rule I created sets the OWNER,GROUP,MODE as well as the SYMLINK. The end result so far is that the link is created, but none of the permission and ownership rules are applied. Is it possbile that something else may be re-assigning these?
    – user942937
    Feb 6 '20 at 6:53
  • Well, in addition to the local rules in /etc/udev/rules.d, there are stock pre-installed rules in /lib/udev/rules.d/ These could be changing things. The complete set of available match patterns can be obtained with the command udevinfo. The command udevadm can be used to test the rules to find out what is happening. I recommend reading the man page on that - I mostly did trial and error with it. Finally, it is possible the so called "device tree" could be messing things up (and I can't really help there).
    – David G.
    Feb 6 '20 at 13:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.