If we change the "smb encrypt" setting from "default" to "required", clients are still able to list share names and connect to services without encryption (although actual file transactions seem to be blocked). This state remains until smbd is completely restarted -- not even a service reload using SIGHUP works. Conversely, if we change the "smb encrypt" from "required" to "default", clients continue to be denied unencrypted access to the Samba server until after a full smbd restart. For example: jmaggard@justin-rn626:~$ testparm -s 2>/dev/null | grep "smb encrypt" jmaggard@justin-rn626:~$ smbclient -mNT1 -g -L //localhost/documents Enter DISCOVERY\jmaggard's password: Disk|Documents| Disk|dr1| Disk|import| Disk|Music| IPC|IPC$|IPC Service ("justin-rn626") Disk|jmaggard|Home directory of jmaggard Reconnecting with SMB1 for workgroup listing. Workgroup|DISCOVERY|JUSTIN-RR4360 jmaggard@justin-rn626:~$ testparm -s 2>/dev/null | grep "smb encrypt" smb encrypt = required jmaggard@justin-rn626:~$ smbclient -mNT1 -g -L //localhost/documents Enter DISCOVERY\jmaggard's password: Disk|Documents| Disk|dr1| Disk|import| Disk|Music| IPC|IPC$|IPC Service ("justin-rn626") Disk|jmaggard|Home directory of jmaggard Reconnecting with SMB1 for workgroup listing. Workgroup|DISCOVERY|JUSTIN-RR4360 jmaggard@justin-rn626:~$ sudo systemctl restart smb jmaggard@justin-rn626:~$ smbclient -mNT1 -g -L //localhost/documents Enter DISCOVERY\jmaggard's password: Error returning browse list: NT_STATUS_ACCESS_DENIED Reconnecting with SMB1 for workgroup listing.
Hmmmm. You can only reproduce this with SMB1 - correct ? I'm guessing it doesn't happen with SMB2+. This might be an artifact of the way encryption is implemented in SMB1, which requires a tran2 call *after* the share connection, so this may be a "just implemented that way" kind of thing (i.e. it probably always did this for the SMB1 unix extensions encryption). If this causing a problem at customer sites, or just something you noticed ? Jeremy.
The "conversely" portion (required -> desire, enabled, or disabled) caused the complaint in the field, and that is reproducible on both SMB1 and SMB2. But you're correct, the first issue with upgrading the encryption requirement is not reproducible using SMB2.
Working on a fix...
Created attachment 13798 [details] Possible patch for master Jeremy, if you're curious, here's what I have... :) Not requesting formal review yet though.
Created attachment 13828 [details] Patch for 4.6 and 4.7 cherry-picked from master
Re-assigning to Karolin for inclusion in 4.7.next, 4.6.next.
(In reply to Jeremy Allison from comment #6) Pushed to autobuild-v4-{7,6}-test.
Pushed to both branches. Closing out bug report. Thanks!