Bug 339752 - enable max protocol SMB3
Summary: enable max protocol SMB3
Status: RESOLVED UPSTREAM
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: smb (show other bugs)
Version: 4.14.1
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
: 341514 384240 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-07 14:04 UTC by Pascal d'Hermilly
Modified: 2018-02-26 13:07 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pascal d'Hermilly 2014-10-07 14:04:55 UTC
Dolphin will not connect to a Windows 2012r2 server with encrypted transport. 
smbclient will only connect if I select max-protocol=SMB3

According to smbclients man page:
-m|--max-protocol protocol
           This allows the user to select the highest SMB protocol level that smbclient will use to connect to the server. By default this is set to NT1, which is the highest available SMB1 protocol. To connect using SMB2 or SMB3 protocol, use the strings SMB2 or SMB3 respectively. Note that to connect to a Windows 2012 server with encrypted transport selecting a max-protocol of SMB3 is required.

Reproducible: Always
Comment 1 Jan 2017-07-17 09:56:40 UTC
Dolphin seems still to not connect any Samba Server with SMB2 or SMB3 protocol.
Comment 2 Pascal d'Hermilly 2017-07-31 21:23:28 UTC
Microsoft says disable all SMBv1 after wannacry and petaya and just announced new flaw.
https://www.onmsft.com/news/microsoft-wont-patch-20-yr-old-smbv1-vulnerability-you-should-just-turn-the-service-off
Comment 3 Pascal d'Hermilly 2017-07-31 21:25:03 UTC
(In reply to Pascal d'Hermilly from comment #2)
> Microsoft says disable all SMBv1 [...]
Just to be clear. What I mean is that Dolphin only hooking up to smbv1 is/will become like not having smb.
Comment 4 suse 2017-08-27 18:36:05 UTC
Dolphin is using smbclient to access smb shares.
As written in comment #0, smbclient is using only NT1 (=SMB1) as maximum protocol.

see also
https://www.samba.org/samba/history/samba-4.1.0.html
"The default protocol for smbclient and smbcacls is still
SMB1 (the NT1 protocol dialect). An SMB2 or SMB3 connection
can be selected in one of two ways."

I see different solutions:
1. Wait until smbclient use SMB3 (or SMB2) as maximum protocol *per default*
2. Force kio-smb to use SMB3 (or SMB2)
3. create ~/.smb/smb.conf on your local machine:
[global]
    client max protocol = SMB3

I've tried solution #3 and it works.
Comment 5 Christoph Feck 2017-09-17 17:03:01 UTC
*** Bug 341514 has been marked as a duplicate of this bug. ***
Comment 6 Christoph Feck 2017-09-17 17:06:29 UTC
*** Bug 384240 has been marked as a duplicate of this bug. ***
Comment 7 suse 2017-09-18 17:39:13 UTC
The upcoming smbclient version 4.7 will change it's default behavior.
https://download.samba.org/pub/samba/rc/samba-4.7.0rc6.WHATSNEW.txt

> The default for "client max protocol" has changed to "SMB3_11",
> which means that 'smbclient' (and related commands) will work against
> servers without SMB1 support.

Let's keep the fingers cross that that change will fix the issue.
Comment 8 slartibart70 2017-10-09 16:23:45 UTC
Hi,
i'm using latest fedora26, kio 5.38 (testing repo).
Problem is, all windows machines can be accessed by smbclient, depending on the settings in /etc/samba/smb.conf with different results (smb2, smb3 etc)
So, this works as expected.

Trying the settings with a .smb/smb.conf does not work, in my opinion this file is not taken into account. Maybe the naming is incorrect? (.samba instead of .smb???)

Then, kio-slaves do access windows machines if win10 is used. kio refuses to connect if win7+security patches (NT1 is banned) is in place. 
Here, i do not have any control over the protocol being used with the modifications in /etc/samba/smb.conf. Testing was done with dolphin and krusader with identical results.

Not a long time ago, this was working (fedora26, approx. by the time the 4.12 kernel was distributed)

I would appreciate this being fixed instead of hoping (comment #7) that this will disappear by itself ... :-))))
Comment 9 Nate Graham 2017-10-28 15:10:49 UTC
Given that there is indeed an upstream fix that's been released, I think that should be what we rely on. No sense duplicating work that's already been done.