Updated CIFS kernel module supporting 2.0 and greater

Hey all,

I have all my data located on a Windows 10 box, and for years I’ve just been using a cifs mount via fstab successfully. Either OSMC or the Win10 box, or both updated and I can no longer mount via cifs. Turns out it’s because MS removed SMB1.0 recently, and a solution to that would be to add an option -o vers=2.0 (2.1,3.0), but whenever I try

sudo mount -t cifs //mintee-pc/Movies /mnt/Movies/ -o username=mintee,vers=2.0

it barks back…

mount error(22): Invalid argument

Looks like this issue is due to a newer version of the cifs kernel module either not being built or just not available. I assume I could grab a module from raspbian, but I’m not certain that would work.

Is this someone has a fix for, or something that can be rolled out soon?


My understanding is we’ve supported this for some time, or we would
have had further reports.

If there’s a CONFIG_ option needed in the kernel, let me know and I’ll
get it added.

Which cifs module version do you have installed and which cifs-util version?

I’m away from the house now, but I’ll check when I get home tonight.

osmc@osmc:~$ modinfo cifs
filename: /lib/modules/4.9.29-10-osmc/kernel/fs/cifs/cifs.ko
version: 2.09
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: 20CE06ECC8A2A0DD76F28E7
intree: Y
vermagic: 4.9.29-10-osmc preempt mod_unload modversions ARMv6 p2v8
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)


osmc@osmc:~$ apt-cache showpkg cifs-utils
Package: cifs-utils
2:6.4-1 (/var/lib/apt/lists/mirrordirector.raspbian.org_raspbian_dists_jessie_main_binary-armhf_Packages) (/var/lib/dpkg/status)
Description Language:
File: /var/lib/apt/lists/mirrordirector.raspbian.org_raspbian_dists_jessie_main_binary-armhf_Packages
MD5: 935040b98485786df2e3f301255ff219

Reverse Depends:
  smb4k,cifs-utils 2:4.1
2:6.4-1 - samba-common (0 (null)) libc6 (2 2.17) libcap-ng0 (0 (null)) libkeyutils1 (2 1.4) libkrb5-3 (2 1.10+dfsg~) libtalloc2 (2 2.0.4~git20101213) libwbclient0 (2 2:4.0.3+dfsg1) smbclient (0 (null)) keyutils (0 (null)) winbind (0 (null)) smbfs (3 2:4.0~rc1-1)
2:6.4-1 -
Reverse Provides:


Suggests CIFS 2.0 is supported.

Your module version is 2.9 which, according to LinuxCIFSKernel - SambaWiki was introduced with kernel 4.7, so it’s quite recent.

My feeling is that your problem might lie elsewhere. Unfortunately, error 22 seems to be quite generic in nature.

Perhaps this thread might contain some helpful pointers.

1 Like

Nope, still a no go. I installed smbclient and tested with debug and received the error here.

protocol negotiation failed: NT_STATUS_CONNECTION_RESET

More info about this here.

Can anyone else try mounting a share from a Windows 10 Pro box?

HIgher debugging here.

osmc@bedroomosmc:~$ smbclient -L -U mintee -d5
INFO: Current debug levels:
all: 5
tdb: 5
printdrivers: 5
lanman: 5
smb: 5
rpc_parse: 5
rpc_srv: 5
rpc_cli: 5
passdb: 5
sam: 5
auth: 5
winbind: 5
vfs: 5
idmap: 5
quota: 5
acls: 5
locking: 5
msdfs: 5
dmapi: 5
registry: 5
scavenger: 5
dns: 5
ldb: 5
lp_load_ex: refreshing parameters
Initialising global parameters
INFO: Current debug levels:
all: 5
tdb: 5
printdrivers: 5
lanman: 5
smb: 5
rpc_parse: 5
rpc_srv: 5
rpc_cli: 5
passdb: 5
sam: 5
auth: 5
winbind: 5
vfs: 5
idmap: 5
quota: 5
acls: 5
locking: 5
msdfs: 5
dmapi: 5
registry: 5
scavenger: 5
dns: 5
ldb: 5
Processing section “[global]”
doing parameter workgroup = WORKGROUP
doing parameter dns proxy = no
doing parameter log file = /var/log/samba/log.%m
doing parameter max log size = 1000
doing parameter syslog = 0
doing parameter panic action = /usr/share/samba/panic-action %d
doing parameter server role = standalone server
doing parameter passdb backend = tdbsam
doing parameter obey pam restrictions = yes
doing parameter unix password sync = yes
doing parameter passwd program = /usr/bin/passwd %u
doing parameter passwd chat = Enter\snew\s\spassword:* %n\n Retype\snew\s\spassword:* %n\n password\supdated\ssuccessfully .
doing parameter pam password change = yes
doing parameter map to guest = bad user
doing parameter usershare allow guests = yes
pm_process() returned Yes
added interface eth0 ip= bcast= netmask=
Netbios name list:-
Client started (version 4.2.14-Debian).
Enter mintee’s password:
Connecting to at port 445
Socket options:
SO_SNDBUF = 44800
SO_RCVBUF = 341760
session request ok
protocol negotiation failed: NT_STATUS_CONNECTION_RESET

Well, turns out it’s a little issue on both sides. I’m running Windows 10 Insider prerelease 170624-1334 and from a post here someone states…

it seems that a recent update to windows 10 pro insider preview build 16232.rs_prerelease.170624-1334 included a change that required me to add vers=3.0 to mount a share that was previously working without it.

For whatever reason, the current cifs module built in osmc’s version of raspbian doesn’t support the ‘vers’ flag, so I can’t get around the fix regardless. I was able to successfully browse the server using smbclient //mintee-pc/Movies -m SMB3 after adding the following fields to my smb.conf in the [global] section

client min protocol = SMB2
client max protocol = SMB3

I’m over it, and ended up mounting the shares with sshfs.

Attached image was about the time I lost my mind, and quit for the evening. Enjoy the legit error message.

So changing Min and Max to SMB3 and then mounting via fstab doesn’t work?

1 Like

Nope, not via the cifs module. Only smbclient. Odd, I know.

Kernel mount doesn’t use smb.conf

1 Like

I have the same issue here. The CIFS components of (Raspi) OSMC do not support the “vers” option of CIFS mount. The generic Raspbian from the foundation does. That the module has version has 2.09 does not mean that CIFS 2.0 is supported and the version of CIFS supported with the “vers” option is 3.

So it would be very helpful if the “vers” option would be supported as SMB1 should not be used anymore, e.g. for security and performance reasons.

It’s being worked on. A potential test kernel might be available in the next 24 hours

I just ran a few quick tests and it seems that the “vers=” option is being parsed but the only value I’ve found that it will accept is “1.0”. Even “vers=1” returns error 22.

@mintee @dillthedog, @sam_nazarko has put a kernel in staging that fixes the issue. If you want to test it follow these instructions otherwise it should most likely be published in the coming days.

I’d appreciate it if you could test this and provide feedback before we release this as an update to other users. To test this update:

Login via the command line2
Edit the file /etc/apt/sources.list
Add the following line: deb http://apt.osmc.tv jessie-devel main
Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.

Here my success

osmc@osmc:~$ sudo mount -t cifs // /mnt/test/ -o username=IEUser,vers=3.0
Password for IEUser@//  *****
osmc@osmc:~$ ls -lah /mnt/test/
total 16M
drwxr-xr-x 2 root root 4.0K May 13 19:22 .
drwxr-xr-x 6 root root 4.0K Jul 29 13:19 ..
-rwxr-xr-x 1 root root  282 Jul 22  2016 desktop.ini
-rwxr-xr-x 1 root root 176K May  6 19:55 Firefox Installer.exe
-rwxr-xr-x 1 root root 1.2M May 13 19:16 OperaSetup.exe
-rwxr-xr-x 1 root root  15M May  6 21:18 TeamViewer_Setup.exe

Confirmed working for me! Great job all, that was quick!

Thanks for confirming.
Remember to change back the devel repository so that you are not being surprised with some future testing stuff. The current testing kernel will remain installed and just be replaced with the official fixed one during the next regular update.