Hello, There are some surprises when trying to connect Windows 10 (up-to-date circa Dec 2016) to Samba (4.5.2) with 'smb encrypt = desired' as a config option. I've made a grid of some of the combinations 'smb encrypt = desired' settings below. The biggest surprise is that if 'smb encrypt = desired' is set globally and in the share, Windows 10 cannot connect at all, but if 'smb encrypt = required' globally then Windows 10 can connect. "Connecting" was tested by first logging out of Windows, restarting the smbd daemon, logging in to Windows, opening Explorer, and typing the URL (UNC?) into the address bar. No credentials were saved in Credential Manager. browse - specify hostname, but not share name - \\smb.physics.wisc.edu select - browse shares as above, then select the share name in Explorer direct - specify hostname and sharename - \\smb.physics.wisc.edu\smb G - global S - per share browse | select | direct smb encrypt (no G, no S) = '' Y | Y | Y smb encrypt (G, no S) = required Y[0] | Y | Y smb encrypt (no G, S) = desired Y[4] | N[1] | Y smb encrypt (G and S) = desired N[3] | N/A | N[2] smb encrypt (G, no S) = desired N[3] | N/A | N[2] [0] Successful login needed before shares are visible. [1] Error message is "multiple connections to a server or a shared resource by the same user, using more than one user name, are not allowed. Disconnect all [...]" [2] Error message is "The specified server connot perform the requested operation" [3] Error message is "Check the spelling of the name. Otherwise there might be a problem with your network." [4] Browsing shares connection not encrypted. When trying to enter a share, possibly Samba/Windows tries to create an encrypted connection leading to [1]. If it is not possible to renegotiate encryption, then the unencrypted connection should be used instead (remember that 'smb encryption = desired'). Below is testparm output (for the smb encrypt (no Global, only per share) = desired case): [global] realm = PHYSICS.WISC.EDU server string = %h server workgroup = PHYSICS max log size = 100000 syslog = 0 panic action = /usr/share/samba/panic-action %d kerberos method = secrets and keytab map to guest = Bad User security = ADS server signing = required hostname lookups = Yes dns proxy = No idmap config * : backend = tdb [smb] path = /srv/smb inherit acls = Yes inherit permissions = Yes read only = No smb encrypt = desired vfs objects = btrfs streams_xattr Thanks for your work! Chad.
We think that kerberos authentication might be needed to reproduce this bug. Ralph tested with a standalone server and found no problems: browse | select | direct smb encrypt (no G, no S) = '' Y | Y | Y smb encrypt (G, no S) = required Y | Y | Y smb encrypt (no G, S) = desired Y | Y | Y smb encrypt (G and S) = desired Y | Y | Y smb encrypt (G, no S) = desired Y | Y | Y
I see those errors that you see, when I change the configuration without rebooting the client. With a rebootet client after making the config changes things are working as expected.