Hi,
I have connected pixhawk to /dev/ttyTHS0 to access it, I used sudo chmod 777 /dev/ttyTHS0 but after restarting Jetson device, I have to change the permissions again.
Is there a way to permeantly own /dev/ttyTHS0?
Thanks
FYI, “/dev/ttyTHS0” is not a real file. This is a pseudo file…it exists only in RAM and is really the device driver presenting a way to talk to it. What permissions does it have now? If that file is group “tty”, then it means serial console is already using it, and you’d have to disable serial console to make the port available for other use. If the file is instead group “dialout”, then you are free to use this. However, you would not want to gain access by changing its permissions…instead you would want to add your user to the group “dialout”.
If your user name is “ubuntu”, then you could add your user to group “dialout” like this:
sudo usermod -aG dialout ubuntu
Hi, thanks for the response. /Dev/ttyTHS0 belongs to the “tty” group, I haven’t stopped the serial console and still I am able to communicate with when pixhawk using /dev/ttyTHS0
If I add the user to the “tty” group the permission resets on restart
Thanks @linuxdev
You should never use a tty device for general use. Everything you send is going to the console (or to the login attempt of the console if not logged in). The console will mostly see this as nonsense, but in some cases if the text has something like “rm -f”, then it will execute that code. The response from the nonsense which the console sends to name errors will be sent to the Pixhawk. You must not use this before disabling serial console, or else you must use a different UART than the one going to those pins.
Adding your user to group “tty” should never happen. “tty” is a special system group which involves security, and this will not work as you expect. I advise simply finding a different UART going to other pins if possible since serial console is very useful if you need to debug.
Also, realize that if you do disable serial console within Linux, that you would still have to disable this in boot stages prior to Linux running (boot and Linux are two separate programs running at different times and must be disabled separately). If any “keystroke” (or serial UART noise) is seen in boot at the wrong moment of boot, then this will drop into a serial console and boot will not continue. Also, all of those boot logs would be sent to the UART, and if your Pixhawk is listening, I don’t know what it will do.
Hi, Thank you so much for such a detailed answer. as mentioned by you, I’ll look for another UART port. but can you tell me how can I make sure that port is owned by the user and it doesn’t require to be owned every time I restart the system?
thanks
This sort of method to change ownership does not have a simple answer since it is a driver and not a file. The “general” renaming or change of ownership policies for such files is through use of “udev” rules. Custom rules are usually placed in “/etc/udev/rules.d/”. You’d need to study how to make a udev rule to be able to do so (this is actually not too difficult).
However, if a serial console is used on a UART port, then trying to change something like this will cause a failure of some unpredictable nature. Not recommended to take a “tty” group UART and simply rename it or try to use it simultaneously with the console.
Unless you’ve built your own custom USB device, then the correct way of dealing with this is to add your user to group dialout, and to not alter the device driver’s name/ownership setup. Should you go that route, then “udev” is the tool to use (“udev” is actually well documented and has many tutorials out on the topic…it is a simple and useful thing to know, but it isn’t specific to a Jetson).
Any file (including device special files which are really part of a driver) can be examined for ownership and permission via “ls -l /some/location/SomeFileName”. I can’t emphasize enough that if the file is in “/dev” and is a UART file of some sort that you should add your user to the group rather than changing the file.
1 Like
Thanks for the info and details, I’ll check the udev rules
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.