Notes to installing Octoprint on Armbain

For the most part, everything outlined in the install instructions for installing to a Linux based system applies to Armbian and goes smoothly.

Installs to both OrangePi Zero and Friendlyarm NEO went smoothly with a couple of exceptions noted below.

  1. There is no default account in the Armbian installation. After install, users ssh to the unit as 'root' and are prompted to change the root password and then prompted to create a new user account.
    If you create an account named "pi" then all the Octoprint Installation Instructions can be followed almost blindly using the `pi' account.
    If you create an account of another name, (ie oprint), then you have to update the scripts and system permission instructions with that user name.

    sudo usermod -a -G tty pi  -> sudo usermod -a -G tty oprint
  2. If you use a plugin that accesses and uses GPIO pins and the behavior is not as expected, then as with all things Octoprint, first check the log files to see what is going on. In this case, the PSUControl plugin was the one plugin of interest.

      2021-12-28 14:38:06,637 - octoprint.plugins.pluginmanager - INFO - Loaded notice data from disk, was still valid
      2021-12-28 14:38:10,830 - octoprint.plugins.psucontrol - INFO - Periphery version: (2, 3, 0)
      2021-12-28 14:38:10,831 - octoprint.plugins.psucontrol - INFO - Using GPIO for On/Off
      2021-12-28 14:38:10,831 - octoprint.plugins.psucontrol - INFO - Configuring GPIO for pin 6
      2021-12-28 14:38:10,851 - octoprint.plugins.psucontrol - ERROR - Exception while setting up GPIO pin 6
      Traceback (most recent call last):
      File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/periphery/", line 539, in _open
         self._chip_fd =, 0)
      PermissionError: [Errno 13] Permission denied: '/dev/gpiochip0'
      During handling of the above exception, another exception occurred:
      Traceback (most recent call last):
      File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/octoprint_psucontrol/", line 190, in configure_gpio         pin = periphery.GPIO(self.config['GPIODevice'], self.config['onoffGPIOPin'], initial_output)
      File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/periphery/", line 496, in __init__self._open(path, line, direction, edge, bias, drive, inverted, label)
      File "/home/octoprint/OctoPrint/venv/lib/python3.9/site-packages/periphery/", line 541, in _openraise GPIOError(e.errno, "Opening GPIO chip: " + e.strerror)periphery.gpio.GPIOError: [Errno 13] Opening GPIO chip: Permission denied

You may need to update the permissions on the Armbian installation to allow the octoprint user to access the GPIO pins and you need to properly identify the GPIO pins.

On a raspi based system, the default permissions for the gpio are visible with an ls -l

user@raspbian:~ $ ls -l /dev/gpiochip0
crw-rw---- 1 root gpio 254, 0 Dec 27 07:47 /dev/gpiochip0

Compared to the armbian install-

user@armbian:~$ ls -l /dev/gpiochip0
crw------- 1 root root 254, 0 Dec 27 23:52 /dev/gpiochip0

Notice the difference in the file permissions and owner name and owner groups. On the default raspi system, the owner is 'root' and group is 'gpio'.

On the armbian system, the gpio pins are owned buy the root group.

We can fix this by creating a gpio group, and then adding the octoprint user to that group. So to fix the permissions on armbian, we need to do some udev rules magic.. Refernce page: GPIO -

  1. Create the new gpio group and add the octoprint user.

    user@armbian:~$ sudo groupadd gpio

    user@armbian:~$ sudo usermod -a -G gpio oprint

You can verify the group creation and user addition-

   user@armbian:~$ sudo getent group | grep gpio

shows that in the group 'gpio' the user 'oprint'is a member..

  1. Create the udev rule with the proper ACLS's

    user@armbian:~$ sudo /etc/udev/rules.d/96-gpio.rules

      # /etc/udev/rules.d/96-gpio.rules
      SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
         chown -R root:gpio /sys/class/gpio && chmod -R 0770 /sys/class/gpio &&\
         chown -R root:gpio /sys/devices/platform/sunxi-pinctrl/gpio && chmod -R 0770 /sys/devices/platform/sunxi-pinctrl/gpio'"
      SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"

save and reload the rules -

       user@armbian:~$ udevadm control --reload-rules && udevadm trigger

restart the octoprint service or just reboot

user@armbian:~$ sudo service octotoprint restart

now checking the permissions of gpio, we see that they belong to group 'gpio'

user@armbian:~$ ls -l /dev/gpiochip*
crw-rw---- 1 root gpio 254, 0 Dec 28 19:16 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Dec 28 19:16 /dev/gpiochip1

and since the user oprint is a member of the group 'gpio' then octoprint is able to access the gpio pin.

  1. Verify that you are citing the pin number correctly. Pin names on ARM SoC based boards are little different than raspberry pi's. The best way to identify the pin is with a manufacture drawing. Here is an example of an OrangePi

For this example, we are going to use PA06 as the pin of interest. If no direct GPIO reference is given, then we can calculate it from the pin name. From the GPIO -
and pages-

To obtain the correct GPIO pin number calculate it from the pin name: (position of letter in alphabet - 1) * 32 + pin number

For pin PA06, it would be (1-1)*32+6 = 6 (since A is the 1st letter)

and thus we would use GPIO pin 6 for the plugin of inteterest, PSUControl.


You forgot some setup steps for the octoprint user.

It helps a bunch if the user is allowed to use sudo, for example so that you can initiate a reboot or shutdown from within octoprint:

sudo adduser oprint sudo

The sudoers list has to be updated with the visudo tool, which is, curiously, frequently not vi. I think in armbian it defaults to Nano?

sudo visudo

Add the following line:


Since we have just allowed this user to execute as root without entering a password, we should make it impossible for this user to log in:

sudo passwd oprint -d
sudo usermod oprint -L 

One consideration before doing this, OctoPrint allows for running any command that you configure it to, which would not be good if your instance was compromised in any way. Just an extra thing to think about if there is any likelihood of the install being compromised (eg. if it's open to the internet or shared in some way).

Right. That's a given.

Most people expect octoprint to behave like an octopi installation on a raspberry pi, but there is increased interest in running octoprint on other platforms with the rpi shortage as it is right now.

There are probably at least a couple ways to allow octoprint to issue reboot and shutdown and some other root-only commands without opening it up to sudo anything at all. I should do the research.

hey - i just saw all your replies. Thanks!

Any further thoughts on improving the behavior for reboot and shutdown commands?



Why not just add specific permissions? In octoprint_deploy, I give the OctoPrint user systemctl and reboot access:

echo "$USER ALL=NOPASSWD: /usr/bin/systemctl" >> /etc/sudoers.d/octoprint_systemctl
echo "$USER ALL=NOPASSWD: /usr/sbin/reboot" >> /etc/sudoers.d/octoprint_reboot