04-09-2019 06:47 AM
I am currently facing some serious issues with file permissions on a RT-Linux cRIO. It seems as if the same code would randomly change permissions:
It might also be the case, that some files were created by different builds or from debugging mode.
Debug mode brings up this error message:
A workaround is to unplug the ETH port while the device boots. But that's not a feasible solution for us. Do I need to configure the aliases file?
I'm using LV 2017 on a cRIO 9063.
04-10-2019 10:54 PM
The files all have read/write permission for lvuser, which is the account the real-time application runs under, so that shouldn't be a problem. I'm unsure why some files have extra permissions set. Were they all created with the LabVIEW RT app (and not created with a text editor or copied to the cRIO)?
What options are you supplying to the Open/Create/Replace File VI? Is this the only place the log file is created and written to?
Error 8 can also refer to a missing file or bad path, so double check the path is valid.
On the face of it, it doesn't make sense unplugging the network cable should affect disk logging. My best guess is that there's a race condition, where a network timeout is causing the log file creation to work.
04-11-2019 02:42 AM
Your're right, we found a document related to RT security (http://www.ni.com/pdf/support/us/ni_linux_real-time_security_user_guide.pdf / Page 26), which states that the LV application runs on lvuser, so write access should go to /home/lvuser. It seems that it works, if we use this location as a location for log files. But the strange thing is that it did work sometimes. Actually we have one system running for months now.
We probably also need to review the code for file access, but that will take a little more time.
You might be right about the race condition, but the application is quite complex, and since we migrated it from LV 2012 to 2017, we have various bugs. User permissions is just one of them. Possibly there's just a coincidence with another issue.