samba - Apr 2019 - Windows clients require reboot once a day in order to access mapped drives

On Fri, 26 Apr 2019 15:03:07 -0700
Mason Schmitt via samba <samba at lists.samba.org> wrote:
> Hey Rowland and Louis (and anyone else that has been following this
> thread),
> 
> It looks like the issue, with W10 clients needing to reboot each
> morning to regain access to samba mapped drives, has been worked
> around with a single smb.conf change.
> 
> The only change I made (which I did only to help with troubleshooting
> via packet capture) was as follows:
> OLD - smb encrypt = desired
> NEW - smb encrypt = off
> 
> So, while I'm happy that users aren't getting frustrated each
> morning, I'm less enthused about not having encryption for W10
> clients.  As mentioned earlier in this thread, this looks like a bug,
> but I don't know whether it's with samba or with W10.  Would you
like
> me to raise an issue in your bug tracker?
> 
> Thanks for your support with this guys :)
> 
Can you try commenting out the line, this should then (by my reading)
allow negotiation of encryption.

Rowland

>
> > It looks like the issue, with W10 clients needing to reboot each
> > morning to regain access to samba mapped drives, has been worked
> > around with a single smb.conf change.
> >
> > The only change I made (which I did only to help with troubleshooting
> > via packet capture) was as follows:
> > OLD - smb encrypt = desired
> > NEW - smb encrypt = off
>
> Can you try commenting out the line, this should then (by my reading)
> allow negotiation of encryption.
>
I have another file server, in a different domain, with a nearly identical
smb.conf to this one, which does not have an entry for "smb encrypt".
According to the man page, this means that it will have "smb encrypt
default".  W10 clients are not able to connect to shares, by name, on this
file server,  after having been idle overnight.  This is the same behaviour
that I was seeing in the other environment where I recently set "smb
encrypt = off".  I think this is fairly clear evidence that there is a bug
(either with the W10 client or with the samba file server).  Again, I'm
happy to file a bug report with samba's bug tracker if you think this is
the best course of action.

--
Mason

On Mon, 29 Apr 2019 11:44:22 -0700
Mason Schmitt <mason at ftlcomputing.com> wrote:
> >  
> > > It looks like the issue, with W10 clients needing to reboot each
> > > morning to regain access to samba mapped drives, has been worked
> > > around with a single smb.conf change.
> > >
> > > The only change I made (which I did only to help with
> > > troubleshooting via packet capture) was as follows:
> > > OLD - smb encrypt = desired
> > > NEW - smb encrypt = off  
> >
> > Can you try commenting out the line, this should then (by my
> > reading) allow negotiation of encryption.
> >  
> 
> I have another file server, in a different domain, with a nearly
> identical smb.conf to this one, which does not have an entry for "smb
> encrypt". According to the man page, this means that it will have
> "smb encrypt = default".  W10 clients are not able to connect to
> shares, by name, on this file server,  after having been idle
> overnight.  This is the same behaviour that I was seeing in the other
> environment where I recently set "smb encrypt = off".  I think
this
> is fairly clear evidence that there is a bug (either with the W10
> client or with the samba file server).  Again, I'm happy to file a
> bug report with samba's bug tracker if you think this is the best
> course of action.
The problem is, if it is a bug, where is it ?

Do you have any earlier versions of Windows ?
If so, does connecting from them work without setting 'smb encrypt' ?

Is there anything in the windows logs when the win 10 computers cannot
connect ?

Rowland