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:
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.