Project

General

Profile

Bug #11024

Setting SMB3 and higher protocol in CIFS service makes share unreadable

Added by Lilit Babalikhyan about 5 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Expected
Assignee:
John Hixson
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Not sure if this is a bug( maybe some additional setup is needed), but changing just one setting makes the share unreachable from windows 8 machine, without any warning from the system side.

To reproduce:
Create a dataset, user, set owner to that user, create a CIFS share with that dataset,
From windows 8 side, map that share and connect to with that user's credentials and make sure it is readable/writable after that.
The default SMB protocol in Services->CIFS-Server Maximum Protocol is SMB2 which has no problem to complete above operations.
When in the Services->CIFS->Server Maximum Protocol is set to SMB3 and up, the share is becoming unreadable from windows 8 machine (immediately)
Changing it back to lower level (SMB2_22 for example) makes share writeable immediately

More information on how to reproduce: http://docs.ixsystems.com/CIFS_SMB_Config

History

#1 Updated by Jordan Hubbard about 5 years ago

  • Assignee set to John Hixson

#2 Updated by John Hixson about 5 years ago

  • Status changed from Unscreened to Investigation

#3 Updated by John Hixson about 5 years ago

  • Status changed from Investigation to 15

Setting the maximum protocol to 3 shouldn't make any difference unless your minimum protocol is set too high. CIFS clients negotiate the protocol with the server based on what they can support. I am unable to reproduce this. If you can attach a debug file, it would help at least a little bit in possibly identifying the issue. System->Advanced->"Save Debug".

#4 Updated by Lilit Babalikhyan about 5 years ago

  • File debug.log added

Minimum protocol is not set...

There are bunch of var/log, maybe they will be more informative?

Would it help if you could access the VM I see the error: 10.5.0.171 as root, with usual password from office or through vpn it should be possible.
If you take a look at the settings in Services->CIFS, maybe you will have better idea what is wrong.
The share/user I can see the problem for is: "tomshare" owned by "tomford" with usual root password we use for root.
I just tried it again and verified that this share is still showing the problem.

I have attached the /var/log/debug.log

#5 Updated by John Hixson about 5 years ago

John Hixson wrote:

Setting the maximum protocol to 3 shouldn't make any difference unless your minimum protocol is set too high. CIFS clients negotiate the protocol with the server based on what they can support. I am unable to reproduce this. If you can attach a debug file, it would help at least a little bit in possibly identifying the issue. System->Advanced->"Save Debug".

If you can attach a debug file, it would help at least a little bit in possibly identifying the issue. System->Advanced->"Save Debug".

#6 Updated by John Hixson about 5 years ago

  • Status changed from 15 to Closed: Cannot reproduce

John Hixson wrote:

John Hixson wrote:

Setting the maximum protocol to 3 shouldn't make any difference unless your minimum protocol is set too high. CIFS clients negotiate the protocol with the server based on what they can support. I am unable to reproduce this. If you can attach a debug file, it would help at least a little bit in possibly identifying the issue. System->Advanced->"Save Debug".

If you can attach a debug file, it would help at least a little bit in possibly identifying the issue. System->Advanced->"Save Debug".

Well, with or without a debug file, I can't reproduce this. You have other issues. A debug would help identify your issue. The problem is not setting the protocol to SMB 3 however, because I can map a share created on 10.5.0.171 to windows 7 and windows 8 just fine with the max protocol set to SMB 3.

#7 Updated by Lilit Babalikhyan about 5 years ago

  • File debug-VM-IP171-20150818163459..tgz added
  • Status changed from Closed: Cannot reproduce to 15

#8 Updated by John Hixson about 5 years ago

Can we do a teamviewer? I'd like to see this. Using your very same machine, I am unable to reproduce this and I am not seeing anything in the logs.

#9 Updated by Lilit Babalikhyan about 5 years ago

I am logged into TeamViewer now. Check the slack for credentials

#10 Updated by John Hixson about 5 years ago

Lilit,

As previously stated, I am unable to reproduce your issue. Using your machine, using the very share you've stated has an issue (tomsshare), using the user you claim to be having issues with (tomford), I can successfully access and map on windows, freebsd and freenas. Are you logging in correctly? Are you typing the correct password? You don't have 'use default domain' checked so you do have to use the full login name with the short netbios name. I'm sorry I missed the TV session but I was requested to be on another call.

#11 Updated by John Hixson about 5 years ago

[root@VM-IP171 ~]# smbclient //10.5.0.171/tomsshare -U 'VM-IP171\tomford'
Enter VM-IP171\tomford's password:
Domain=[IXSYSTEMS] OS=[Unix] Server=[Samba 4.1.18]
smb: \> ls
. D 0 Tue Aug 18 17:06:07 2015
.. D 0 Tue Aug 18 16:31:22 2015
New folder D 0 Mon Aug 17 17:04:24 2015
tomcreation D 0 Mon Aug 17 16:30:10 2015
smb02 D 0 Mon Aug 17 17:02:18 2015
New Journal Document.jnt A 4544 Mon Aug 17 17:15:53 2015
New folder (2) D 0 Mon Aug 17 17:17:24 2015

64748 blocks of size 1024. 64640 blocks available
smb: \>

#12 Updated by Lilit Babalikhyan about 5 years ago

Yes, the above command works form me as well.

Here is my scenario:

The protocol in the Web GUI of 10.5.0.171 is set to SMB2
On windows explorer the "tomshare" is mapped and accessed with tomford's credentials. I see the directory content and can write into it.
From 10.5.0.171 Web gui, I change the protocol to SMB3
The tomshare immediately becomes not readable.
Change the protocol back to SMB2
The tomshare immediately becomes accessible like before

This is what I see right now.
I can reboot everything unmap/remap the drive and report the results if you think it is worth to do.
The reason I would not touch it now is to make sure you have something to work with in case you think it is a bug

Let me know

#13 Updated by John Hixson about 5 years ago

Lilit Babalikhyan wrote:

Yes, the above command works form me as well.

Here is my scenario:

The protocol in the Web GUI of 10.5.0.171 is set to SMB2
On windows explorer the "tomshare" is mapped and accessed with tomford's credentials. I see the directory content and can write into it.
From 10.5.0.171 Web gui, I change the protocol to SMB3
The tomshare immediately becomes not readable.
Change the protocol back to SMB2
The tomshare immediately becomes accessible like before

This is what I see right now.
I can reboot everything unmap/remap the drive and report the results if you think it is worth to do.
The reason I would not touch it now is to make sure you have something to work with in case you think it is a bug

Let me know

Lilit,

You are changing the protocol, this is expected. You have to unmap (or delete) the drive then remap it. I have confirmed this works as it should. If you were to force a protocol change using windows the same thing would occur. I do not see a bug here.

#14 Updated by Lilit Babalikhyan about 5 years ago

  • Status changed from 15 to Closed: User Config Issue

Yes, you are right. Disconnect/reconnect did the trick.
Thank you for taking time to investigate
Closing

#15 Updated by Lilit Babalikhyan about 5 years ago

  • Status changed from Closed: User Config Issue to Resolved

#16 Updated by Lilit Babalikhyan almost 5 years ago

  • Status changed from Resolved to Closed

Closing for consistency, this was not a bug

#17 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Seen in changed from Unspecified to N/A

#18 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to N/A

#19 Updated by Dru Lavigne almost 3 years ago

  • File deleted (debug.log)

#20 Updated by Dru Lavigne almost 3 years ago

  • File deleted (debug-VM-IP171-20150818163459..tgz)

Also available in: Atom PDF