CRIO Tips: Mounting Network Drives

This a follow on article to a previous article. Its part of a series of tips that Neil Crossan provided me with, dealing with cRIOs and Linux RT targets. He saw a post of mine and sent me a bunch of tips and tricks. I thought I would share some of them with you here. Many thanks to Neil for sharing his knowledge. Also, general Linux knowledge is really helpful. If you want to brush up, here is a good book.

The Challenge

One of the challenges when using a cRIO in a project is retrieving data. For systems where you have an HMI that is running and communicating with the cRIO you can easily transfer data using network streams or TCP/IP in realtime. However not all systems always have an HMI running on a separate computer.

Things get more difficult when you have a headless machine. Headless means there is no HMI running. There are a couple of options here. You could have the cRIO log data to a database running somewhere on your network. You run the risk of the database being inaccessible if the network goes down. You could run the database locally, but then you would run into space considerations. A networked database like Postgres works well for things that aren’t very data intensive. For example, a monitoring system that polls sensors once a second. The overhead of reaching out over the network is low enough that it wouldn’t interfere with data collection.

What to do if you are collecting large amounts of data? If you have a lot of information generated, you are probably generating tdms files. How do you retrieve those? An easy solution is to have the cRIO throw them onto a network share. The challenge is how do you mount a network share on a cRIO?

The Solution

Setup

There are 2 different ways to mount a network drive. Both require admin access. You can either give lvuser root access (this is required if you plan to mount the drive from within LabVIEW via SystemExec) or simply type in su admin via ssh or the console (if you do this you can leave off the sudo).

You’ll also need cifs tools. You can get them by updating opkg (so you make sure you get the latest version.) and then using opkg to install cifs-utils

opkg update
opkg install cifs-utils

Manual Mount

Then mounting the drive is as simple as:

sudo mount -t cifs //[IP of remote server]/[name of shared folder]/ -o username=[your username],password=[your password],uid=lvuser /home/lvuser/data

You can run this command via ssh/the console or via System Exec. -o specifies the options. There are more you can set, but these are the basics. The username and password are the credentials for the share. The uid=lvuser is to make sure that the owner and permissions are set up so that lvuser has read and write permissions. This is necessary because LabVIEW runs as lvuser. The /home/lvuser/data can be any path you want. That is where the drive gets mounted. It does need to exist. If it doesn’t you’ll have to use the mkdir command to create it first. If you create it just be carefule with permissions – make sure it is owned by lvuser and they can read/write to it. Once mounted then you can just throw any datafiles into /home/lvuser/data and they’ll show up on the share.

Dealing with network issues

I am no linux or file sharing expert, but I always store the created files in a local folder and then have a separate process that periodically moves them to the shared folder. This is so that if the network share is unavailable for any reason my normal code won’t hang or crash or lose any data. Not entirely sure exactly what would happen if you just pulled the network cable or the fileserver crashed, but whatever it is, it wouldn’t be good. This way your process can keep going until the network comes back. If you wanted to test this out, you could always create a Virtual cRIO and try it out.

Mounting on startup

The command above is for manual mounting. If you reboot, the mounting goes away. So you would have your LabVIEW code mount the drive using the snippet above everytime it ran. If you wanted the drive to always be there, you could set it up in fstab. If you google fstab, there is lots of information on how to do that. Also be sure to back up your fstab file. If you hose it, you will have trouble booting.

The fstab entry would look something like this:

//[IP of remote server]/[name of shared folder]/ /home/lvuser/data  username=[your username],password=[your password],uid=lvuser  0 0

Hiding Credentials

Another caution, particularly if you are using fstab, but even if you are manually mounting via LabVIEW is that you are potentially exposing the credentials for the share. fstab is readable by anyone on the machine and it is bad practice to hardcode credentials in your LabVIEW executable. If you do, the simple linux strings command will expose them, plus if they are hardcoded, you can’t change them without rebuilding the exe. The workaround for that is to create a protected file that contains the credentials.

#create hidden .creds file
echo "username=me" >>.creds
echo "password=secret" >>.creds
#change owner to root and set to only allow root to read it
sudo chown root .creds
sudo chgrp root .creds
sudo chmod 400 .creds

Then when you mount, instead of typing out the credentials, just pass the .creds file. Below is the manual command, you can also do something similar with fstab.

sudo mount -t cifs //[IP of remote server]/[name of shared folder]/ -o credentials=/pathto/.creds,uid=lvuser /home/lvuser/data

Help!

If you would like help setting up a CRIO system and using Linux RT, give us a call. We’d be glad to talk about how we can help.