/etc/fstaband execute the mount command from the terminal (via SSH). The mount command executes, gives no error messages, but just hangs (for minutes until I interrupt it). Tests with the same configuration in our office with a Synology NAS as server were successful.
mount error(13): Permission denied. We don't get this error message on the cRIO at the customer, trying to connect to the customer's share.
Update2: My colleague Manu could shed some light:
Mounting a network share (with CIFS-Utils, mount.cifs) works only if the server accepts the old SMBv1. It seems the NI Linux RT kernel doesn't support SMB > 1, despite the fact that the official kernel has support for SMBv3 from version 3.12. Using
smbclientand the option
-m=SMB3, mounting works.
So as for our options:
1) Try a newer software stack on the cRIO - Is it possible to run a LV18 application on a cRIO with LV20 firmware?
smbclient to copy the file to the network share - that feels very much like a hack...
To make it more clear what works and what not:
We have a NAS that provides a SMB network share and restricts the SMB version to >= 2.0. We try to mount this network share on a cRIO 9030 with "NI Linux Real-Time x64 4.9.47-rt37-6.1.0f0" using "cifs-utils version 6.6-r0". The line in /etc/fstab is like the following:
//xx.xx.xx.22/hampel_unversioned/Test /mnt/smb cifs noauto,users,uid=500,gid=500,username=manuel.sebald,password=xxxxx 0 0
The mount command returns
mount error(13): Permission denied
If I try a connection with the samba tool "smbclient" I can force the SMB version to 3.0 and then it works.
For the CIFS-Utils there is an option "vers" to specify the SMB version (e.g. vers=3.0). When I add the "vers" option to the line in /etc/fstab I get the error "Unknown vers= option specified: 3.0".
This leads me to the conclusion that the NI Linux Kernel 4.9 has no support for SMB versions > 1, despite the information that the official Linux Kernel has support for SMBv3 from version 3.12 on.
Do I miss something with the CIFS-Utils or does it just not support SMBv3?
Do you see the same issue if you mount from the command line instead? That is, if you mount using the mount command directly with the vers=3.0 option instead of using the /etc/fstab file?
Can you also share:
Note that the smb version compatibility shouldn't have anything to do with the kernel itself as far as I know and should instead depend on the version of samba used. That being said, kernel versions 4.12 and earlier should default to smb 1.0 and 4.13 and later should default to smb 3.0 (assuming this link is correct and we didn't modify or backport any of that for Linux RT)
here is the output when I use the mount command from the command line in the screenshot:
It makes no difference to the variant with the line in /etc/fstab.
The command "smbstatus" is not installed on this machine. I should mention that I have not install the full Samba stack, only the packages "cifs-utils" (this should be the only package necessary for the mount) and "smbclient" (with a lot dependencies) for testing.
As far as I understand, the "CIFS" (filesystem) is a part of the kernel and it's not necessary to install Samba. Samba is mainly the server for providing a smb/cifs network share (and the whole Active Directory stuff). This relation is substantiated with the fact that I can connect to the network share with "smbclient" (part of samba) and smbclient accepts the option "-m SMB3" but it doesn't work with CIFS.
However, in the meantime I installed the LV2020 software stack (NI Linux Real-Time x64 4.14.146-rt67-cg-8.0.0f1-x64-139) on a second cRIO 9030 and installed only the package "cifs-utils". Then I added the same line into the /etc/fstab as on the LV18 cRIO and ... voila ... the network share gets mounted, with and without "vers=3.0" option. So, it seems the new kernel has direct SMBv3 support (or NI just activated it for this version).
To make a long story short: we will migrate the project from LV18 to LV20. I hope this might help other people with the same problem 🙂