Curious but I can’t seem to work this out.
I’m trying to implement where a Python code auto-runs when powered up. The only problem is that I’m using two different directories that require permission and have to be run in the terminal.
sudo usermode -aG gpio
sudo chown root.gpio /dev/gpiochip0
sudo chmod 660 /dev/gpiochip0
sudo chmod 666 /dev/ttyTHS1
Any help is appreciated. Thanks!
Hi johnmel.bolaybolay,
What’s your Jetpack version in use?
Could you use that command to give permission to your desired node?
and why you would need to change permission every time during boot up?
Not sure how to check my Jetpack version but I downloaded it here: Get Started With Jetson Nano Developer Kit | NVIDIA Developer
Says the zip file is jetson-nano-jp461
And I’ve never tried including a command in my Python file to give permission to the directory. I might try it because I was checking if there’s anything we can do to make permissions by default.
On the other hand, I’m not really sure why I need to set permissions before using these directories. I’ve pip-installed these two directories. Even though, I ran the commands in the terminal, the permissions just reset back again every boot.
okay, these nodes is created during boot up so that you need to give them permission before use.
Or you could just enter into super user mode with sudo su after boot up.
But, to reply, is there anyway that sudo su is implemented automatically right after boot up? Like no need to type and enter it into the terminal
If you were to do this the “official” way, then you’d need to know that files in “/dev” are not real files. They are actually drivers, in RAM, pretending to be files. Changing permissions is somewhat different. To modify defaults the “udev” system is used.
If you browse in “/etc/udev/rules.d/”, then you will find human-readable files. Each file has a number of ways to identify a file in “/dev”. Once identified there are a number of things udev can edit. One of those will be file permissions. This is the “MODE”, a.k.a., permissions. Example:
grep MODE /etc/udev/rules.d/*
You’ll find owner, group, and mode (chmod) can be set. You’d be interested in MODE.
The hard part is to identify only your files. I will start by saying that you should look closely at the output of “ls -l /dev/ttyTHS1” before you modify it. If this is group dialout, then you should instead add your user to that group as a supplemental group instead of changing the file itself. If that file is group tty, then this should not be altered. The reason for being group tty would be that the serial port is already used as a serial console. One can disable serial console (not really a good idea), and the permissions will revert to group dialout. An example of how to append this group to your regular user is this (I’m pretending your user name is “nvidia”; adjust to be whatever your user name really is):
sudo usermod -aG dialout nvidia
It’s a really bad idea in terms of security to add your user to supplemental group root, but you could add your user to supplemental group gpio if that is the group of those files. Most likely the group is root.
An interesting topic on udev, which is used to control attributes of device special files the proper way at bootup:
https://askubuntu.com/questions/15570/configure-udev-to-change-permissions-on-usb-hid-device
Go to “/etc/udev/rules.d/”. The files there are human readable. Examine a few. Notice how they start by providing attributes of a file which identify which file(s) the rule will apply to. Some of those attributes are based on USB descriptors (the idVendor and idProduct), and only matter for USB devices. Others might name a file pattern. An example is if you see:
KERNEL=="ttyUSB[0-9]"
…the above uses a regular expression to find a file the kernel has assigned name pattern “ttyUSB0” through “ttyUSB9” to.
The inverse is this, which identifies files not using that name pattern:
KERNEL!="ttyUSB[0-9]"
The reason for this is that sometimes there are a series of rules, and reaching some test condition might invoke a “GOTO” statement to skip some lines. I have not used this on GPIO, but in theory you could create a new file in “/etc/udev/rules.d/” which has this as identity of files you are looking at:
KERNEL=="gpiochip[0-9]"
Do not change the group unless you know that group exists. For example, you could search for group “gpio” via either:
A. grep -i 'gpio' /etc/group
B.
less -i /etc/group
# The "/" starts a regular expression search:
/gpio
If you don’t have a group called “gpio”, then you could create it (this is only one way of multiple):
# There are options to this, e.g., setting a specific group number; useful
# if you are creating a group which is part of the system and traditionally
# from a lower number.
sudo addgroup gpio
Take a look at your own group since Ubuntu (and most Linux flavors) create a group for each user. If your login name is “someone”, then this will find your group:
grep 'someone' /etc/group
Let’s say you are a member of more than one group, then the above will return more than one result. This includes supplemental groups you are in. If a group exists, and you add yourself to it (for example, remember earlier I mentioned that you can add your user to supplemental group “dialout”?), that will show up. If group gpio does not exist, and you manually added it, then no user will be part of it yet.
To add yourself to group gpio (assuming your user name is “someone”; adjust for your user name):
sudo usermod -aG gpio someone
If you also happen to have a udev rule which changes the gpiochip[0-9]' to OWNER of root, GROUP of gpio, and MODE of 0660, then any user of gpio group can use those device special files.
In summary: It is better to use udev to modify permissions and ownerships in /dev, and to create a new group or reuse an existing group, and then add your user to that group. Manual chmod might not always work the way you expect because those are not real files.
I got it now. Thanks a lot
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.