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

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

> > 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'
?
>
Sorry, I should have mentioned that, rather than just implying it.  I do
have windows 7 clients on both networks and in both environments the win7
clients have never exhibited this behaviour.

Given that the workaround to the problem is disabling encryption in
smb.conf, Win7 clients don't support encrypted SMB connections and Win10
clients do support encrypted connections, it would seem there is some issue
with re-connecting domain authenticated SMB sessions that are using
encryption.  As you can see, looking back in this thread, the packet
capture shows that the client is not attempting to re-authenticate to the
domain.  I just don't know if that's because the client isn't
receiving
something it expects from the server, or whether the client just isn't
behaving according to the protocol spec.

> Is there anything in the windows logs when the win 10 computers cannot
> connect?
>
There is nothing in the log that jumps out at me.  I just spent the last
1/2hr filtering out cruft and found nothing that seemed odd.  That doesn't
mean Windows isn't reporting anything, but if it is, I couldn't find it.

--
Mason

On Mon, 29 Apr 2019 13:01:54 -0700
Mason Schmitt <mason at ftlcomputing.com> wrote:
> > > 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' ? 
> 
> Sorry, I should have mentioned that, rather than just implying it.  I
> do have windows 7 clients on both networks and in both environments
> the win7 clients have never exhibited this behaviour.
> 
> Given that the workaround to the problem is disabling encryption in
> smb.conf, Win7 clients don't support encrypted SMB connections and
> Win10 clients do support encrypted connections, it would seem there
> is some issue with re-connecting domain authenticated SMB sessions
> that are using encryption.  As you can see, looking back in this
> thread, the packet capture shows that the client is not attempting to
> re-authenticate to the domain.  I just don't know if that's because
> the client isn't receiving something it expects from the server, or
> whether the client just isn't behaving according to the protocol spec.
> 
> 
> > Is there anything in the windows logs when the win 10 computers
> > cannot connect?
> >  
> 
> There is nothing in the log that jumps out at me.  I just spent the
> last 1/2hr filtering out cruft and found nothing that seemed odd.
> That doesn't mean Windows isn't reporting anything, but if it is, I
> couldn't find it.
> 
As I said, where is the fault, is it something that Windows 10 is or
isn't doing, or is it Samba ?

Well, we cannot change Windows, so on that basis, I think you should
make a Samba bug report and let it work through the system.

Rowland

Hai, 

... 
> 
> As I said, where is the fault, is it something that Windows 10 is or
> isn't doing, or is it Samba ?
> 
> Well, we cannot change Windows, so on that basis, I think you should
> make a Samba bug report and let it work through the system.
> 
> Rowland
Well, yes, we can change windows, by allowing/disallowing SMB1. 
Which might help in detecting whats off..  

I would check 3 things here before this is reported as bug. 

Kerberos/Authentication. krb5.conf, Did you change the : clockskew or
renew_lifetime
Set only this : 
[libdefaults]
    default_realm = YOUR.REALM.TLD
    dns_lookup_kdc = true
    dns_lookup_realm = false

;; optinal. 
;    forwardable = true
;    proxiable = true
;    ticket_lifetime = 24h	<< one you can try as LAST option. 
;    ccache_type = 4



Are the pc's connected to multiple servers. Then on these servers run :
smbstatus -A
Check these outputs. 

The windows clients, do these have SMB1 still enabled or not? 
And what are the windows eventlogs telling ( post event id and part of
description ).

Now, you can try these also. I tested samba 4.9.6 and 4.10.2 on Debian 9. 

    smb encrypt = required
    client min protocol = SMB2
    client max protocol = SMB3



Greetz, 

Louis