Can you post the full fstab and output of grab-logs -A?
If I can reproduce it here I can fix things.
The error was not triggered by fstab (fstab is empty) but manually by the following commands (both same result).
For production i use systemd units to mount the folders, but it is all the same result.
sudo mount -t cifs "//win-server/Tv and Movies" "/mnt/movies" -o vers=3.0,user=marco,uid=1000,gid=1000,pass=<password>
sudo mount -t cifs "//win-server/Tv and Movies" "/mnt/movies" -o vers=3.0,seal,user=marco,uid=1000,gid=1000,pass=<password>
Hi,
Thanks for the feedback.
I think the problem comes from when we tried to backport CIFS 3 encryption support.
We can remove it and I suspect it will resolve the problem but then encryption will be gone for v3.0.
A backport doesn’t look trivial, but I can see I can take some fixes from 5.1 which will improve things. This likely won’t fix the crashes though.
To rule out a Debian Bullseye issue, can you try the following update which reverts the attempt to implement the latest SMB3 patches for 4.9:
- Login via the command line
- Run the following command to add the staging repository:
echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list - 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 remove /etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.
With these fixes we are back to SMB3.0 not working with the following error:
mount error(13): Permission denied
dmesg:
[ 56.862769] CIFS VFS: SMB3 encryption not supported yet
[ 56.865487] CIFS VFS: SMB3 encryption not supported yet
[ 56.867124] CIFS VFS: cifs_put_smb_ses: Session Logoff failure rc=-13
[ 56.867404] CIFS VFS: cifs_mount failed w/return code = -13
regardless if the command contains seal or not.
My guess is, that the vero is incorrectly reporting encryption support and the server is trying to hold it to that promise.
I made a Network dump that confirms this:
This is the Negotiate Protocol Request of the Vero. It signals it supports encryption
Frame 64: 172 bytes on wire (1376 bits), 172 bytes captured (1376 bits)
Ethernet II, Src: Shenzhen_28:51:c6 (c4:4e:ac:28:51:c6), Dst: SuperMic_0d:ea:1e (ac:1f:6b:0d:ea:1e)
Internet Protocol Version 4, Src: 192.168.103.67, Dst: 192.168.103.200
Transmission Control Protocol, Src Port: 48394, Dst Port: 445, Seq: 1, Ack: 1, Len: 106
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
SMB2 Header
Negotiate Protocol Request (0x00)
[Preauth Hash: fdb5d90aa540f89323c8bdb1d3c8eb088bcafe229c2946d1387c429e0acc443a27e87ef9…]
StructureSize: 0x0024
Dialect count: 1
Security mode: 0x01, Signing enabled
Reserved: 0000
Capabilities: 0x00000057, DFS, LEASING, LARGE MTU, PERSISTENT HANDLES, ENCRYPTION
.... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
.... .... .... .... .... .... .... ..1. = LEASING: This host supports LEASING
.... .... .... .... .... .... .... .1.. = LARGE MTU: This host supports LARGE_MTU
.... .... .... .... .... .... .... 0... = MULTI CHANNEL: This host does NOT support MULTI CHANNEL
.... .... .... .... .... .... ...1 .... = PERSISTENT HANDLES: This host supports PERSISTENT HANDLES
.... .... .... .... .... .... ..0. .... = DIRECTORY LEASING: This host does NOT support DIRECTORY LEASING
.... .... .... .... .... .... .1.. .... = ENCRYPTION: This host supports ENCRYPTION
Client Guid: f8784df9-73fe-d64a-a129-18d8c68ee5d5
NegotiateContextOffset: 0x00000000
NegotiateContextCount: 0
Reserved: 0000
Dialect: SMB 3.0 (0x0300)
However during the Session Setup request it no longer indicates encryption support:
(I have no idea if this flag is relevant at this point of the negotiation I will have to check a working rpi3 image, nevertheless indicating encryption support in the session setup request without actually supporting it, can’t be right)
Frame 67: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits)
Ethernet II, Src: Shenzhen_28:51:c6 (c4:4e:ac:28:51:c6), Dst: SuperMic_0d:ea:1e (ac:1f:6b:0d:ea:1e)
Internet Protocol Version 4, Src: 192.168.103.67, Dst: 192.168.103.200
Transmission Control Protocol, Src Port: 48394, Dst Port: 445, Seq: 107, Ack: 175, Len: 124
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
SMB2 Header
Session Setup Request (0x01)
[Preauth Hash: 0f26b4b5f5619fec230bfecded6b04cb2df498285aa6478de28fda1ab8d1008ad3c198ec…]
StructureSize: 0x0019
Flags: 0
Security mode: 0x01, Signing enabled
Capabilities: 0x00000001, DFS
.... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
.... .... .... .... .... .... .... ..0. = LEASING: This host does NOT support LEASING
.... .... .... .... .... .... .... .0.. = LARGE MTU: This host does NOT support LARGE_MTU
.... .... .... .... .... .... .... 0... = MULTI CHANNEL: This host does NOT support MULTI CHANNEL
.... .... .... .... .... .... ...0 .... = PERSISTENT HANDLES: This host does NOT support PERSISTENT HANDLES
.... .... .... .... .... .... ..0. .... = DIRECTORY LEASING: This host does NOT support DIRECTORY LEASING
.... .... .... .... .... .... .0.. .... = ENCRYPTION: This host does NOT support ENCRYPTION
Channel: None (0x00000000)
Previous Session Id: 0x0000000000000000
Blob Offset: 0x00000058
Blob Length: 32
Security Blob: 4e544c4d5353500001000000250208e000000000000000000000000000000000
This probably leads to the windows server expecting an encrypted connection and then rejecting further unencrypted logon atempts.
For reference this is the working SMB 2.1 Negotiate Protocol Request where no encryption support is naturally specified.
Frame 244: 172 bytes on wire (1376 bits), 172 bytes captured (1376 bits)
Ethernet II, Src: Shenzhen_28:51:c6 (c4:4e:ac:28:51:c6), Dst: SuperMic_0d:ea:1e (ac:1f:6b:0d:ea:1e)
Internet Protocol Version 4, Src: 192.168.103.67, Dst: 192.168.103.200
Transmission Control Protocol, Src Port: 48398, Dst Port: 445, Seq: 1, Ack: 1, Len: 106
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
SMB2 Header
Negotiate Protocol Request (0x00)
[Preauth Hash: a05ee66fc7355309fbdab836ca07dbd408ac7fe1ccd42088204b7034c43009246dae1cf4…]
StructureSize: 0x0024
Dialect count: 1
Security mode: 0x01, Signing enabled
Reserved: 0000
Capabilities: 0x00000000
.... .... .... .... .... .... .... ...0 = DFS: This host does NOT support DFS
.... .... .... .... .... .... .... ..0. = LEASING: This host does NOT support LEASING
.... .... .... .... .... .... .... .0.. = LARGE MTU: This host does NOT support LARGE_MTU
.... .... .... .... .... .... .... 0... = MULTI CHANNEL: This host does NOT support MULTI CHANNEL
.... .... .... .... .... .... ...0 .... = PERSISTENT HANDLES: This host does NOT support PERSISTENT HANDLES
.... .... .... .... .... .... ..0. .... = DIRECTORY LEASING: This host does NOT support DIRECTORY LEASING
.... .... .... .... .... .... .0.. .... = ENCRYPTION: This host does NOT support ENCRYPTION
Client Guid: 8bcf541d-3923-f14d-9596-cef78a7e4bd2
NegotiateContextOffset: 0x00000000
NegotiateContextCount: 0
Reserved: 0000
Dialect: SMB 2.1 (0x0210)
Ok so I checked, with a working raspbian image with kernel 5.14 The encryption flag is not set after the initial Negotiate Protocol Request (and it still results in an encrypted connection). So this seems to be the only time windows checks for it.
Now the question is, is it easily changed to set this flag to 0 (and will it work the with unencrypted SMB3.0)
Ok i digged into the mainline 4.9 kernel and I think I found the problem.
smb2ops.c line 1925+
struct smb_version_values smb30_values = {
.version_string = SMB30_VERSION_STRING,
.protocol_id = SMB30_PROT_ID,
.req_capabilities = SMB2_GLOBAL_CAP_DFS | SMB2_GLOBAL_CAP_LEASING | SMB2_GLOBAL_CAP_LARGE_MTU | SMB2_GLOBAL_CAP_PERSISTENT_HANDLES | SMB2_GLOBAL_CAP_ENCRYPTION,
.large_lock_type = 0,
.exclusive_lock_type = SMB2_LOCKFLAG_EXCLUSIVE_LOCK,
.shared_lock_type = SMB2_LOCKFLAG_SHARED_LOCK,
.unlock_lock_type = SMB2_LOCKFLAG_UNLOCK,
.header_size = sizeof(struct smb2_hdr),
.max_header_size = MAX_SMB2_HDR_SIZE,
.read_rsp_size = sizeof(struct smb2_read_rsp) - 1,
.lock_cmd = SMB2_LOCK,
.cap_unix = 0,
.cap_nt_find = SMB2_NT_FIND,
.cap_large_files = SMB2_LARGE_FILES,
.signing_enabled = SMB2_NEGOTIATE_SIGNING_ENABLED | SMB2_NEGOTIATE_SIGNING_REQUIRED,
.signing_required = SMB2_NEGOTIATE_SIGNING_REQUIRED,
.create_lease_size = sizeof(struct create_lease_v2),
};
In particular .req_capabilities: [...] | SMB2_GLOBAL_CAP_ENCRYPTION
this then probably gets used by SMB2_negotiate in smb2pdu.c line 431
req->Capabilities = cpu_to_le32(ses->server->vals->req_capabilities);
would it be possible to remove theis single CAP from the smb_version_values smb3* structs?
I am trying to compile my own cifs.ko to test this, wish me luck 
Yep this works:
Frame 70: 172 bytes on wire (1376 bits), 172 bytes captured (1376 bits)
Ethernet II, Src: Shenzhen_28:51:c6 (c4:4e:ac:28:51:c6), Dst: SuperMic_0d:ea:1e (ac:1f:6b:0d:ea:1e)
Internet Protocol Version 4, Src: 192.168.103.67, Dst: 192.168.103.200
Transmission Control Protocol, Src Port: 49030, Dst Port: 445, Seq: 1, Ack: 1, Len: 106
NetBIOS Session Service
SMB2 (Server Message Block Protocol version 2)
SMB2 Header
Negotiate Protocol Request (0x00)
[Preauth Hash: 9c9cb2a9aa18e84fa647edc52e13c0844fd00ec48d4943680200b2f1500bef868cd72fea…]
StructureSize: 0x0024
Dialect count: 1
Security mode: 0x01, Signing enabled
Reserved: 0000
Capabilities: 0x00000017, DFS, LEASING, LARGE MTU, PERSISTENT HANDLES
.... .... .... .... .... .... .... ...1 = DFS: This host supports DFS
.... .... .... .... .... .... .... ..1. = LEASING: This host supports LEASING
.... .... .... .... .... .... .... .1.. = LARGE MTU: This host supports LARGE_MTU
.... .... .... .... .... .... .... 0... = MULTI CHANNEL: This host does NOT support MULTI CHANNEL
.... .... .... .... .... .... ...1 .... = PERSISTENT HANDLES: This host supports PERSISTENT HANDLES
.... .... .... .... .... .... ..0. .... = DIRECTORY LEASING: This host does NOT support DIRECTORY LEASING
.... .... .... .... .... .... .0.. .... = ENCRYPTION: This host does NOT support ENCRYPTION
Client Guid: fe161845-6ab6-5a44-ac8a-032ce0f31d3f
NegotiateContextOffset: 0x00000000
NegotiateContextCount: 0
Reserved: 0000
Dialect: SMB 3.0 (0x0300)
So removing SMB2_GLOBAL_CAP_ENCRYPTION from those structs should work.
Note that the SMB3.1.1 struct already misses this flag, since it uses a seperate method to negotiate encryption (different Ciphers etc.) but that is probably not important undtil proper encryption support is here anyway. Probably not until a newer kernel will be supported?
1 Like
Thanks for investigating.
Did you build this on the latest OSMC Vero kernel? If so this confirms that the changes I made previously should indeed be reverted and we should include your fix only; at least until / if we are able to backport CIFS in a better way.
Probably not – our next kernel would be 5.4 based.
I compiled 4.9.269-21-osmc
And yes with the change to 5.4 it should then hopefully work without further issues
Great work investigating and solving even.
I will integrate these changes early next week.
Thanks
Sam
Sorry for the delays.
I’ve got this change integrated now.
To test this update:
- Login via the command line
- Run the following command to add the staging repository:
echo 'deb http://apt.osmc.tv bullseye-devel main' | sudo tee /etc/apt/sources.list.d/osmc-devel.list - 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 remove /etc/apt/sources.list.d/osmc-devel.list after updating.
This will deactivate the staging repository. You can do so with the following command:
sudo rm /etc/apt/sources.list.d/osmc-devel.list.
Please note that we will automatically disable this update channel after 14 days on your device in case you forget to do so to ensure that your system reverts to the stable update channel.
Sorry for the even bigger delay 
Is this change mainlined by now, or do you still need feedback if it is fixed in the devel branch?
These changes are in the stable kernel now for some time.
great, as far as I can tell it works, so a very late thanks
You’re welcome. Our next kernel 5.15 will have further SMB improvements, but we’ve achieved pretty much all we can regarding SMB backports with this kernel version.