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

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

I didn't go through all the conversations and I'm not sure if this will 
be of any help, I just wanted to inform that I've been using mapped 
drives with Windows 10 for ages and never had the problems you 
described. I also never added or changed the "smb encrypt" option. My 
Samba file server (AD member) was set up pretty much the way as is 
described in the official Wiki and it just works. I can confirm this for 
several versions from Samba 4.2.x to 4.9.x. And I never changed anything 
in the Windows 10 registry either.

Viktor

On 29.04.2019 22:15, Rowland Penny via samba wrote:
> 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
>
>

> > 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.
>
>
> 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.
>
I just submitted a bug report -
https://bugzilla.samba.org/show_bug.cgi?id=13921

--
Mason

Hi Viktor,

I didn't go through all the conversations and I'm not sure if this
will
> be of any help, I just wanted to inform that I've been using mapped
> drives with Windows 10 for ages and never had the problems you
> described. I also never added or changed the "smb encrypt"
option. My
> Samba file server (AD member) was set up pretty much the way as is
> described in the official Wiki and it just works. I can confirm this for
> several versions from Samba 4.2.x to 4.9.x. And I never changed anything
> in the Windows 10 registry either.
>
Would you be willing to share your config files?  I'd be curious to see
what's different between yours and mine.

Probably having the smb.conf and krb5.conf files from both a samba DC and
file server would be helpful.

--
Mason