Read & write permission ttyTHS1

Hi everyone,

How do i get read and write permission for the /dev/ttyTHS1 on every startup?

I can of course do sudo chmod 666 /dev/ttyTHS1, but I wanted a headless startup, without having to enter the password.

I tried two ways so far - without success:

  1. I created a udev rule: /etc/udev/rules.d/55-tegraserial.rules containing:
KERNEL=="ttyTHS*", MODE="0666"
  1. I created a rc.local file, that gets executed:
#!/bin/sh -e
#

chmod 666 /dev/ttyTHS1
touch /home/nano/test.txt
exit 0

rc.local gets executed, the test.txt file created with superuser privileges, but in both cases 1) and 2), when i look at the permissions of /dev/ttyTHS1 i get:

crw--w---- 1 root tty 238, 1 Sep 12 18:38 /dev/ttyTHS1

my system:
Jetson Nano (img file from nvidia website)
Ubuntu 18.04.3 LTS
Kernel: 4.9.140-tegra

I forgot to mention that i also added the user to bot tty and dialout without success.

I couldn’t tell you for sure, but it sounds like something else is already in ownership of the port. udev won’t work if it is denied permission, e.g., if the file is locked by a process. The default should be that group “dialout” has read-write permissions for unowned serial UARTs. The existence of group “tty” implies the device is a terminal (e.g., serial console) and is not available for other uses.

Thanks for your response, that would make sense. Do you know a way to check which process is in ownership? It even happens right after booting up the system. It probably is something that is executed after the rc.local, because otherwise access would be allowed by 2) that i tried

Your udev rule is actually working but the nvgetty service is then starting a console on ttyTHS1 which sets it back to 0620. If you stop and disable the nvgetty service, your udev rule should stay in effect.

systemctl stop nvgetty
systemctl disable nvgetty
udevadm trigger (or reboot)

BTW, “lsof” will show you who has a particular file open. You have to “apt-get install lsof” to get it.

Thanks a lot gtj, this resolved my issue! After disabling the service and restarting, I was able to set the rights with the udev rule as in 1)

I had the same problem and that solved it. Thanks!