GPIO permission errors after upgrade to 3.18.x (Raspbian)

[irlp]

When the latest package raspberrypi-bootloader:armhf 1.20150130-1 was installed, the gpio symbolic links in /sys/class/gpio/ moved from /sys/devices/virtual/ to /sys/devices/soc/20200000.gpio.

The permissions in /sys/devices/soc/20200000.gpio do not include the "x" bit, as as such nobody but root can use the gpio.

This has changed since the latest bootloader, and the only way I can fix this is on boot, as root, run

chmod -R +x /sys/devices/soc/20200000.gpio

Is there a better way to allow a non-root user to access the GPIO?

[fivdi]

I think this is happening because /lib/udev/rules.d/60-python-pifacecommon.rules and /lib/udev/rules.d/60-python3-pifacecommon.rules no longer function as expected.

For example, here's /lib/udev/rules.d/60-python3-pifacecommon.rules:

KERNEL=="spidev*", GROUP="spi", MODE="0660"
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'"

The directory /sys/devices/virtual/gpio no longer exists, so the rule doesn't work.

[popcornmix]

Does disabling device-tree (add "device_tree=" to config.txt) work around the issue?

Ping @pelwell @asb

[OliverHoermann]

I came round this issue when testing my PiFace Digital, where pifacecommon/interrupts.py threw an exception of not finding /sys/devices/virtual/gpio. Setting device_tree=off in config.txt makes /sys/devices/virtual/gpio reappear. After that, PiFace Digital works as expected again.

BR Oliver

[pelwell]

Can somebody explain how PiFace (my phone really wanted to write "pigface" there) uses these file nodes, and why it doesn't/can't use the nodes under /sys/class/gpio/ instead?

[popcornmix]

I believe it's just used in /lib/udev/rules.d/60-python3-pifacecommon.rules (which we include in raspbian image)

[pelwell]

I don't buy that. Why bother changing permissions on files or directories that you aren't otherwise going to use?

[OliverHoermann]

Phil, the /sys/..../gpio is used in pifacecommons/interrupts.py.

I tried changing above file. Pifacedigital-emulator started up afterwards, but didn't read the input lines then. Only output settings worked.

Hope that helped, Oliver

Am 07.02.2015 um 20:10 schrieb Phil Elwell notifications@github.com:

I don't buy that. Why bother changing permissions on files or directories that you aren't otherwise going to use?

— Reply to this email directly or view it on GitHub https://github.com/raspberrypi/linux/issues/791#issuecomment-73378114.

[fivdi]

In order for user pi to be able to access gpios without root permissions on a michine with the device tree disabled, udev rules are needed for both /sys/class/gpio and /sys/devices/virtual/gpio. They are needed for /sys/devices/virtual/gpio because the gpioN directories in /sys/class/gpio are links to the gpioN directories in /sys/devices/virtual/gpio. For example, see directory gpio4 here:

pi@raspberrypi /sys/class/gpio $ echo 4 > export 
pi@raspberrypi /sys/class/gpio $ ls -la
total 0
drwxrwx---  2 root gpio    0 Feb  7 20:11 .
drwxr-xr-x 38 root root    0 Feb  7 19:28 ..
-rwxrwx---  1 root gpio 4096 Feb  7 20:11 export
lrwxrwxrwx  1 root gpio    0 Feb  7 20:11 gpio4 -> ../../devices/virtual/gpio/gpio4
lrwxrwxrwx  1 root gpio    0 Jan  1  1970 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
-rwxrwx---  1 root gpio 4096 Feb  7 19:40 unexport
pi@raspberrypi /sys/class/gpio $ 

I can't think of a sane reason to use /sys/devices/virtual/gpio in source code as /sys/class/gpio can always be used instead, if I'm not mistaken.

Note that this only functions when the device tree is disabled. When the device tree is enabled, /sys/devices/virtual/gpio disappears.

If the device tree is enabled, the udev rules on the Pi 2 need to use /sys/devices/soc/3f200000.gpio/gpio/ instead. The address 3f200000 may be different on the Pi 1, I'm not sure.

Note that /sys/devices/virtual/gpio is used in both /lib/udev/rules.d/60-python3-pifacecommon.rules and /lib/udev/rules.d/60-python-pifacecommon.rules in Raspbian. I've no idea how many users rely on this now.

[pelwell]

Can somebody try this modified version of /lib/udev/rules.d/60-python-pifacecommon.rules (change either or both versions)?:

KERNEL=="spidev*", GROUP="spi", MODE="0660"
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/devices/soc/*.gpio/gpio && chmod -R 770 /sys/devices/soc/*.gpio/gpio'"

It should work with and without DT, on Pi1 and Pi2.

[tompreston]

Hi, I'm one of the Tom's at PiFace -- we're looking into this right now. :)

[tompreston]

@pelwell The new rule works when the interrupt module in pifacecommon points to /sys/class/gpio instead of /sys/devices/virtual/gpio. I'm going to patch this in and the updated package should go live asap.

[pelwell]

That sounds like the right change - you can think of /sys/class/gpio as the generic interface, and /sys/devices/*/gpio as the specific implementation.

[fivdi]

@pelwell The new rule you provided above also works for me. I'm not using PiFace, but rely on the rule to enable user pi on Raspbian to use gpio without root privileges. Thanks :)

[alexanderhaensch]

in /boot/config.txt

device_tree=

is the only solution for me. i am using lric_rpi and some gpios. even lirc_rpi dt_overlay is not working correctly... :(

[VipSaran]

I've fixed both pi-gpio (pull request #34) and gpio-admin (pull request #7) in a manner so that both the old and the new paths are supported. Hopefully, those pull requests are merged soon...

[ccforward]

Look here https://github.com/nickfloyd/raspberry-beacons

[Ruffio]

@irlp has this issue been resolved? If yes, please close this issue. Thanks.

[trgtylcnky]

I am experiencing this problem in 4.9.17-v7+ and nothing suggested seems to solve my problem.

[pelwell]

This isn't really a kernel issue. Which distribution are you running, and what is the install history (i.e. is it a clean install or did you upgrade, and if so from what)?

[trgtylcnky]

I was using latest OctoPi raspbian release. It was the kernel 4.1.19-v7+ but I upgraded it by rpi-update. When I turn back to 4.1.19, gpio works without problem. However in that version I am getting undefined symbol: mmal_vc_init_fd while running chromium-browser.

[pelwell]

Using the 4.9 kernel, what do you get from:

sudo grep -r gpio /etc
ls -l /sys/class/gpio /sys/devices/virtual/gpio

[trgtylcnky]

$ sudo grep -r gpio /etc
/etc/udev/rules.d/99-com.rules: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/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"
/etc/udev/rules.d/99-com.rules:SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"
/etc/group-:gpio:x:997:pi
/etc/gshadow-:gpio:!::pi
/etc/group:gpio:x:997:pi
/etc/gshadow:gpio:!::pi

$ ls -l /sys/class/gpio /sys/devices/virtual/gpio
ls: cannot access /sys/devices/virtual/gpio: No such file or directory
/sys/class/gpio:
total 0
-rwxrwx--- 1 root gpio 4096 Mar 30 08:17 export
lrwxrwxrwx 1 root gpio    0 Mar 30 08:17 gpiochip0 -> ../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio    0 Mar 30 08:17 gpiochip100 -> ../../devices/gpiochip1/gpio/gpiochip100
-rwxrwx--- 1 root gpio 4096 Mar 30 08:17 unexport

[pelwell]

Those permissions all look correct. What happens when you echo 10 > /sys/class/gpio/export?

[deadprogram]

Seems like this problem still exists on the latest released Jessie Lite v4.4, from my testing. Sorry about the cross-post to multiple issues.

[pelwell]

That's not a very useful bug report. Please say what you do and what results you get, and your installation history.

[deadprogram]

I installed the default Raspbian from here: https://downloads.raspberrypi.org/raspbian_lite_latest

Then I tried to run the Gobot example code that handles in the same fashion as Python/node.js libs, via a sysfs interface using /sys/class/gpio/export.

https://github.com/hybridgroup/gobot/blob/master/examples/raspi_blink.go

This code is able to run under sudo, but not without sudo. My understanding was that the dev rules in the latest Raspibian would no longer require this.

Thank you.

[pelwell]

Thanks - I would have expected that to work. Just to be clear, are you saying you have not upgraded or altered the kernel in any way?

[deadprogram]

That's correct. No changes whatever.

[fivdi]

@deadprogram After exporting a gpio to userspace, does your code wait for the permissions on the files in /sys/class/gpio/gpioN to change before using them or does it attempt to use the files immediately?

[deadprogram]

Possible race condition? If that is the case, then how long should one wait after exporting before using the pin?

[fivdi]

The udev rules modify the permissions asynchronously and your code runs at the same time, so your code may end up trying to access the files before the permissions are changed.

If that is the case, then how long should one wait after exporting before using the pin?

There isn't really a good answer to this question as it will be highly dependent on the current system load.

In onoff it's done like this. The code keeps attempting to set the direction of the GPIO until it succeeds. In theory it tries up to 10000 times. In practice it only has to try once or twice when the system load is "normal". After the direction has been set, onoff doesn't have any further special code for dealing with the issue.

[deadprogram]

Thank you for the tip @fivdi and the link.

I've implemented that solution now, and works great.

[trgtylcnky]

Sorry for late reply. I was away from my pi.

$ ls -l /sys/class/gpio/gpio10/
total 0
-rw-r--r-- 1 root root 4096 Apr  3 08:38 active_low
lrwxrwxrwx 1 root root    0 Apr  3 08:38 device -> ../../../gpiochip0
-rw-r--r-- 1 root root 4096 Apr  3 08:38 direction
-rw-r--r-- 1 root root 4096 Apr  3 08:38 edge
drwxr-xr-x 2 root root    0 Apr  3 08:38 power
lrwxrwxrwx 1 root root    0 Apr  3 08:38 subsystem -> ../../../../../../../class/gpio
-rw-r--r-- 1 root root 4096 Apr  3 08:38 uevent
-rw-r--r-- 1 root root 4096 Apr  3 08:38 value

[pelwell]

The udev rule uses $devpath to locate the device nodes, and it is looking like that mechanism isn't working in your case. Can you try these tests?:

echo 10  >/sys/class/gpio/export
udevadm info --query=all --path=/sys/class/gpio
udevadm info --query=all --path=/sys/class/gpio/gpio10

[trgtylcnky]

$ udevadm info --query=all --path=/sys/class/gpio
P: /class/gpio
E: DEVPATH=/class/gpio
E: SUBSYSTEM=subsystem

 $ udevadm info --query=all --path=/sys/class/gpio/gpio10
P: /devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio10
E: DEVPATH=/devices/platform/soc/3f200000.gpio/gpiochip0/gpio/gpio10
E: SUBSYSTEM=gpio

[pelwell]

That all looks OK. What do you have in /etc/udev/rules.d/99-com.rules? You can omit the spi/i2c/tty rules.

[trgtylcnky]

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/devices/platform/soc/*.gpio/gpio && chmod -R 770 /sys/devices/platform/soc/*.gpio/gpio'"
SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

[pelwell]

That rule for "gpio" doesn't match the current Raspbian version - try using this instead (replacing `/devices/platform/soc/.gpio/gpiowith$devpath`):

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/devices/platform/soc/*.gpio/gpio'"

@XECDesign - @trgtylcnky says he is running OctoPi Raspbian. Does this look like an old Raspbian rules file, or is it some other concoction?

[XECDesign]

It looks like it's an older version of the file: https://github.com/RPi-Distro/raspberrypi-sys-mods/blob/c2f4795c7214a2c87589391acbae73d31e8099a3/etc/udev/rules.d/99-com.rules

What is the md5sum of the file? Is raspberrypi-sys-mods installed? If so, what version?

[ziesemer]

See also: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=183481

Had the same issues. raspberrypi-sys-mods was not installed. Installing it, and confirming to overwrite /etc/udev/rules.d/99-com.rules if prompted, resolved the issue for me. Be sure to remove any existing GPIO exports, or simply reboot - or existing exports will still have the broken permissions.

In regards to @XECDesign's above question, this is what I had before (non-working):

$ ll 99-com.rules ; md5sum 99-com.rules
-rw-r--r-- 1 root root 506 Nov 21  2015 99-com.rules
1de39a305333e7c5bf0dca7ba5df9bdf  99-com.rules

... and after (working):

$ ll 99-com.rules ; md5sum 99-com.rules
-rw-r--r-- 1 root root 983 Mar 21  2016 99-com.rules
279f8967ca1013b96aa59416fd8557ab  99-com.rules

Regarding OctoPi: I am not using OctoPi, but https://github.com/vitormhenrique/OctoPrint-Enclosure/issues/16 also looks to be the same.

[JamesH65]

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[JamesH65]

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.