mount network folder samba cifs

Hi,

I am trying to mount a network folder on my tx1.
the folder is located on a windows server 2019 for which I have enable netbios over tcp/ip:

if I do:

smbclient -L myipadress -U myidonthedomain -W mydomain -m SMB3

I have an error:

Connection to ip failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled – no workgroup available
but I can see the folder on the ip address anyway

if I do:

smbclient -L computername -U myidonthedomain -W mydomain -m SMB3
it works.
I don’t get the difference.

if now I try to mount the folder:
sudo mount -t cifs -o username=myusername,domain=domainname,sec=ntlmv2,vers=3.0 //windowsip/sharedfolder/ /mnt/test/

it gives the error:
Unknown vers= option specified:3.0

only 1.0 works.
I don’t get why.
I can see in man mount.cifs that vers=3.0 is a allowed entry.

I have samba, samba-dev, cifs-utils package, checked that they are up to date.
i have the linux kernel 3.10.96-tegra.

I don’t get why vers=3.0 is not accepted.
how can I mount my network folder ?

Regards

I don’t generally use samba, but this should be no different on a Jetson than other Ubuntu systems. Sometimes packages are installed by default on desktops which are not installed on embedded systems like a TX1, and so it could be nothing more than a missing package.

I did see notes that version 3 is stronger security…which sounds like configuration and authentication might differ. It is probably somewhat lame on my side, but if nobody else has seen this specific problem, check out these URLs and make sure all that is needed for v3 is installed and configured:
[url]https://wiki.samba.org/index.php/LinuxCIFS[/url]
[url]https://wiki.samba.org/index.php/SMB3_kernel_status[/url]

I saw a number of possibly related hits here, but I have no way to test so I’m just poking around in google searches:
https://www.google.com/search?ei=Ail3XMOjC8bbjwTMh4PYBw&q=ubuntu+support+cifs+3&[url]oq=ubuntu+support+cifs+3&gs_l=psy-ab.3...264572.265238..266094...0.0..0.134.616.3j3......0....1..gws-wiz.......0i71.TUAzDqHVQfU[/url]

Thanks for the info.

at some point it started to work, I have no idea what changed because I was working on something else.
so I guess it’s related to a dist upgrade or or the installation of another package that solved a dependency problem.

no idea, but now it works …

after a new flash of the jetson tx1, I get the same problem as before
unknow vers= option specified: 3.0

for details about my cifs.utils configuration:
modinfo cifs
filename: /lib/modules/4.4.38-tegra/kernel/fs/cifs/cifs.ko
version: 2.08
description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows
license: GPL
author: Steve French sfrench@us.ibm.com
alias: fs-cifs
srcversion: 07FFF7956145202ED25FC2E
depends:
intree: Y
vermagic: 4.4.38-tegra SMP preempt mod_unload aarch64
parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (uint)
parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (uint)
parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (uint)
parm: cifs_max_pending:Simultaneous requests to server. Default: 32767 Range: 2 to 32767. (uint)
parm: enable_oplocks:Enable or disable oplocks. Default: y/Y/1 (bool)

apt-cache showpkg cifs-utils
Package: cifs-utils
Versions:
2:6.4-1ubuntu1.1 (/var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial-updates_main_binary-arm64_Packages) (/var/lib/dpkg/status)
Description Language:
File: /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial_main_binary-arm64_Packages
MD5: 935040b98485786df2e3f301255ff219
Description Language: en
File: /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial_main_i18n_Translation-en
MD5: 935040b98485786df2e3f301255ff219
Description Language:
File: /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial-updates_main_binary-arm64_Packages
MD5: 935040b98485786df2e3f301255ff219

2:6.4-1ubuntu1 (/var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial_main_binary-arm64_Packages)
Description Language:
File: /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial_main_binary-arm64_Packages
MD5: 935040b98485786df2e3f301255ff219
Description Language: en
File: /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial_main_i18n_Translation-en
MD5: 935040b98485786df2e3f301255ff219
Description Language:
File: /var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial-updates_main_binary-arm64_Packages
MD5: 935040b98485786df2e3f301255ff219

Reverse Depends:
smb4k,cifs-utils 2:4.1
smbclient,cifs-utils
python-moinmoin,cifs-utils
casper,cifs-utils
udevil,cifs-utils
casper,cifs-utils
pyneighborhood,cifs-utils
clonezilla,cifs-utils
smbclient,cifs-utils
python-moinmoin,cifs-utils
libpam-mount,cifs-utils
Dependencies:
2:6.4-1ubuntu1.1 - samba-common (0 (null)) libc6 (2 2.17) libcap-ng0 (0 (null)) libkeyutils1 (2 1.4) libkrb5-3 (2 1.13~alpha1+dfsg) libpam0g (2 0.99.7.1) libtalloc2 (2 2.0.4~git20101213) libwbclient0 (2 2:4.0.3+dfsg1) keyutils (0 (null)) smbclient (0 (null)) winbind (0 (null)) smbfs (3 2:4.0~rc1-1)
2:6.4-1ubuntu1 - samba-common (0 (null)) libc6 (2 2.17) libcap-ng0 (0 (null)) libkeyutils1 (2 1.4) libkrb5-3 (2 1.13~alpha1+dfsg) libtalloc2 (2 2.0.4~git20101213) libwbclient0 (2 2:4.0.3+dfsg1) keyutils (0 (null)) smbclient (0 (null)) winbind (0 (null)) smbfs (3 2:4.0~rc1-1)
Provides:
2:6.4-1ubuntu1.1 -
2:6.4-1ubuntu1 -
Reverse Provides

I see arm64 in

2:6.4-1ubuntu1.1 (/var/lib/apt/lists/ports.ubuntu.com_ubuntu-ports_dists_xenial-updates_main_binary-arm64_Packages) (/var/lib/dpkg/status)

for example.

shouldn’t it be armhf instead ?
https://packages.ubuntu.com/xenial/armhf/cifs-utils/download

apparently it was the good package.
I tried to dpkg the hf one and I got an error: does not match system (arm64)

The TX1 is 64-bit, ARMv8-a/arm64/aarch64. The older 32-bit is ARMv7-a with floating point hardware, so it is armhf. Although the TX1 CPU (all of the 64-bit ARM CPUs) has a compatibility mode the 32-bit support infrastructure is not installed by default…and even if 32-bit support was available you’d probably end up hating it (it would run quite slow). So look for anything which says one of arm64/aarch64/ARMv8-a.

ok so the packages are the good one apparently. but then why I can’t mount my samba ? why vers=3.0 is not accepted in mount.cifs?

Just to emphasize, I am not a samba guru. Maybe someone else who uses samba might comment. However, from what I can tell the main differences with versions would be that of protocols (especially security). If possible, first investigate the exact version being used on both sides and make sure they are not incompatible due to that. Then investigate the security setup of the end doing the export…see what protocols or security features are being used, and make sure that the version on the TX1 has that protocol.

This is probably overly general, and it isn’t from knowing samba, but there are many security protocols on various software which are capable of using multiple protocols, and those protocols are implemented as modules. I suspect that if the versions match, then there will probably be some sort of method for determining for example if rsa or dsa is used (those are just contrived examples from ssh keys). Other than configuration and making sure versions match with compatible options this should work (I know, famous last words) the same on the TX1 as it does from a desktop PC.

part of my question was how to do that.

To see package names currently installed with the word “samba” in them:

dpkg -l | grep -i 'samba'

To search the currently configured respositories for “samba-libs”:

apt search samba-libs

To search for all samba and a pager for easier browsing:

apt search samba | less -i
# Then search within for lines starting with "samba":
/^samba

There may be other repositories available, but not configured. It looks like the default repositories only use samba 2, but I don’t know what other repos are available, nor what other ways there are to install samba 3 (also, since I have not worked on samba, it is possible I am reading the version wrong).

Not sure, but does your kernel have CONFIG_CIFS_SMB2 ?

gunzip -c /proc/config.gz | grep CONFIG_CIFS_SMB2

If not set, it may not have SMB2 nor SMB3 filesystems support.

If it is not set, you may try to add this to your kernel. I haven’t tried this myself, though.

Here are all the info when I typed all the commands you gave:

gunzip -c /proc/config.gz | grep CONFIG_CIFS_SMB3
nvidia@tegra-ubuntu:~$ gunzip -c /proc/config.gz | grep CONFIG_CIFS_SMB2
# CONFIG_CIFS_SMB2 is not set

the shared folder is on a windows server 2019 and should be smb 3.1.1 protocol but I don’t know how to check on windows.

How do i change the config_cifs_smb2 ? because now it’s “is not set” and I guess it’s part of the problem.
I have to change something in /usr/src/linux-headers-4.4.38-tegra/fs/cifs ?

Looks like @Honey_Patouceul found the answer…missing CIFS.

When a kernel is built it uses a configuration. Not all drivers and features are installed on every machine. The file “/proc/config.gz” is a pseudo file and does not exist on the hard drive…this is a reflection in RAM of the running kernel telling you how it was configured. So basically you need to add the CONFIG_CIFS_SMB2 while keeping everything else the same from the config.gz.

There are two ways of adding a driver. One is to build a new kernel (then you would see a feature with “=y”), another is to just build a module which plugs in to the kernel (this is easier and less invasive…after building the module it is just a file copy to the right location…no flash operation is required).

The official documentation does say how to cross compile, but you can compile natively. Either way the first thing you need is the kernel source (headers alone are not enough for your purposes). Have you flashed before from your host PC? If so, then somewhere you will have directory “Linux_for_Tegra/”. Within this will be file “source_sync.sh”. This file can be copied anywhere and used from either the PC or from the Jetson to get the kernel source. You will need to know which release you are using (check “head -n 1 /etc/nv_tegra_release”). Assuming “R28.2” (and I don’t know if it is), then this will get kernel source in full:

./source_sync.sh -k tegra-l4t-r28.2

You should save a safe copy of the “/proc/config.gz” file somewhere for permanent reference. After a gunzip and rename to “.config” this will replace any step in any of the instructions where it suggests “make tegra21_defconfig”. Are you interested in compiling natively on the Jetson, or instead from the host PC? If the latter, then the Documentation download with the particular L4T release gives the instructions. Find your release here:
https://developer.nvidia.com/embedded/linux-tegra-archive

Note that the “/proc/config.gz” is an exact match to the running kernel with only one exception. That exception is the “CONFIG_LOCALVERSION” parameter. If the kernel is version “4.4.38”, then the result of the command “uname -r” will start with “4.4.38”; after that the suffix of “uname -r” is whatever the “CONFIG_LOCALVERSION” is. In the case of default kernels it is “-tegra”, and “uname -r” will show “4.4.38-tegra”. One could directly edit the “.config” file like this and be a perfect 100% exact match to the running system:

CONFIG_LOCALVERSION="-tegra"

Modules are always searched for in a subdirectory of:

/lib/modules/$(uname -r)/

If you have a driver in the form of a module, and if that driver were named “foo” (file “foo.ko”), and if that driver is found in the actual kernel source at “drivers/block/bar/”, then the module would go in the running system at “/lib/modules/$(uname -r)/kernel/drivers/block/bar/foo.ko”. You’d still need to reboot or run various commands to load the module, but after that the command “lsmod” should show the module any time it is actually loaded.

thanks for the well detailed explanation.
I am using the R28.2 release yes. I have flashed from my host pc.
I am performing this step on the host pc for now:
./source_sync.sh -k tegra-l4t-r28.2
it’s taking forever.

Ideally from the jetson tx1 and not from the host pc.

you are talking of the one on the tegra, not the host pc right ? I haven’t found a config.gz in the sources folder after avec performed the:

./source_sync.sh -k tegra-l4t-r28.2

what I don’t get for now, is where I modify anything related to cifs ?
because I flashed my tegra like two or three weeks ago, it was up to date.

Keep in mind that the “/proc/config.gz” file is a reflection of the running system and is not a real file. Thus the kernel currently running actually creates this file on the Jetson. When running an unmodified kernel you should copy this somewhere for safe backup…you are going to want to use it in the future even after you’ve updated.

Also write down the output of “uname -r” and remember this is associated with the config.gz you just copied. Probably it will be “4.4.38-tegra”, where “4.4.38” is the kernel version and the “-tegra” is a suffix. It is this suffix you will need to know later…between that suffix and the config.gz file you will be able to create an exact match to the existing environment (any changes are simple from there).

The source_sync.sh script downloads kernel source, you have to take a copy of the “config.gz” file from the first step, gunzip it, and put a copy in correct place. “correct place” depends on whether you use options to place compile output outside and keep the kernel source clean (and you should), or if you are just building directly in the kernel source (you can, but it is not advisable). Regardless of which location it is, then having that config file there by the name “.config” will cause this to be the default when you “make” anything.

I suspect you are going to feel a bit overwhelmed because I am telling you you must build a kernel module, but it isn’t too hard once you are set up. All you are doing is creating a file and then copying it to the correct directory. I will assume you are keeping your kernel source clean and building in an alternate temporary output file location natively from the TX1.

Make sure you have installed “libncurses5-dev” on the Jetson:

sudo apt-get install libncurses5-dev

For the purpose of an example, I assume you copied file “source_sync.sh” to “/usr/local/src/”, but it could be almost anywhere convenient, e.g., in a home directory. This would imply that when you ran source_sync.sh from “/usr/local/src/” it produced this subdirectory, which is the kernel source:

/usr/local/src/sources/kernel/kernel-4.4/

I will assume you set an environment variable (and be careful because this will be empty on any terminal you did not set this), and have the following, but you could just paste the full path in:

export SRC=/usr/local/src/sources/kernel/kernel-4.4

(test to see “echo $SRC” says “/usr/local/src/sources/kernel/kernel-4.4”)

You may have to create a temp file output location directory, but just use “mkdir” (or “sudo mkdir”) where needed. My example will be “/usr/local/src/build/”:

export TEGRA_KERNEL_OUT=/usr/local/src/build

(verify “echo $TEGRA_KERNEL_OUT” shows this)

In a similar manner you will create a temporary module output directory (similarly you may create this anywhere you want):

export TEGRA_MODULES_OUT=/usr/local/src/modules

(verify “echo $TEGRA_MODULES_OUT” is this)

From your backup copy of config.gz, after gunzip, rename it “.config” and place it in “$TEGRA_KERNEL_OUT”. I don’t know where your backup is, but it would go something like this (use sudo where needed…I actually change ownership of my TEGRA_KERNEL_OUT and TEGRA_MODULES_OUT to user “ubuntu” and compile as that user…the SRC directory can remain owned by root):

cp /where/ever/it/is/config.gz $TEGRA_KERNEL_OUT
cd $TEGRA_KERNEL_OUT
gunzip config.gz
mv config .config

Edit “.config”, find “CONFIG_LOCALVERSION”, and match the current suffix of the “uname -r” (probably “-tegra”). So it will read:

CONFIG_LOCALVERSION="-tegra"

Now you go to the actual source (and keep in mind if you use more than one terminal you need to have exported the TEGRA_KERNEL_OUT and other values in any terminal you use) and configure:

cd $SRC
# There is more than one config editor, I just like nconfig:
make nconfig
# Note you can search for symbols if you look at the list of hot keys at the bottom of the
# nconfig menu. Search for "CONFIG_CIFS_SMB2" or just "CIFS_SMB2". When you find it, then
# go there. Highlight it. Press the "m" key to select it as a module. Save and exit. Done
# with configuring. Next build.

Now increase TX1 performance to max for faster build:

sudo ~ubuntu/jetson_clocks.sh

Just so you know you do not need “make Image” since you are only adding a module configured to work with the existing kernel. However, I consider this a sanity check. You should do it anyway even if you don’t need it…at least one time. After that if you are confident and doing future module additions you don’t need to “make Image”. For sanity (and this takes time):

cd $SRC
# NOTE: That is a capital letter "o", not a zero:
make -j4 O=$TEGRA_KERNEL_OUT Image

There are all kinds of possible warnings, ignore them unless you get an error which terminates early. On success you will find “Image”:

find O=$TEGRA_KERNEL_OUT -name 'Image'

You also do not have to build all modules…but you should for sanity:
cd $SRC
make -j4 O=$TEGRA_KERNEL_OUT modules

make O=$TEGRA_KERNEL_OUT modules_install INSTALL_MOD_PATH=$TEGRA_MODULES_OUT

I don’t know the specific module name, but it would have “cifs” in its name:

find $TEGRA_MODULES_OUT -name '*cifs*'

That “.ko” file will be your driver/kernel module. Note that the existing system will have all modules somewhere under “/lib/modules/$(uname -r)/”. The location of any “.ko” file will be a mirror of where it is in the kernel source tree. Note that this directory will exist on the Jetson:

/lib/modules/$(uname -r)/kernel/

Since this is a file system type I suspect when you “find” the file name in the “$TEGRA_MODULES_OUT” it will be in some “fs/” (file system) subdirectory, and so the location is probably under:

/lib/modules/$(uname -r)/kernel/fs/cifs/

My system already shows “cifs.ko” there, but in theory you are building a different version…maybe its name is “cifs2.ko” (I don’t know, I didn’t actually build it). Most likely the file you just built would go there. If instead the file is found in a “cifs2/” directory (I don’t know if it is or not), then you’d make a “cifs2/” directory next to the “cifs/” directory (and then copy the cifs2 “.ko” file there). You’re fairly safe to put it in the wrong place, though it might or might not work.

To tell the system to update its module knowledge:

sudo depmod -a

You can use commands to then manually load the kernel without reboot, but it will be simplest to just reboot. Then test.

Note: Features as a module (where the module is loaded) can be seen with “lsmod”. Run this before you add the module. Likely the other version of cifs.ko will show up. After done and you reboot see if there is now the other version as well.

Even though this is correct for installing that module it doesn’t guarantee it was the source of the original problem. Maybe it is authentication. Or maybe it is this plus authentication. Perhaps you will now also need some configuration. Just don’t panic if this doesn’t do the job because it is still good to learn and is probably at least a subset of what is needed. From then on this driver will be available and you can rule that out as a cause of failure.

Btw, if you want to start over from scratch, then normally the “cd $SRC; make O=$TEGRA_KERNEL_OUT mrproper” would clean things out. However, there may be some out of tree stuff which is a result of some of the extra directories…feel free to recursively remove the content in “$TEGRA_KERNEL_OUT” to clean things before starting new. This is a big reason why building in a separate output directory is good.

Trivia: You’ll still be running the same kernel. Only the module will differ.