Web lists-archives.com

Re: [Samba] Windows clients require reboot once a day in order to access mapped drives

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.


On 29.04.2019 22:15, Rowland Penny via samba wrote:
On Mon, 29 Apr 2019 13:01:54 -0700
Mason Schmitt <mason@xxxxxxxxxxxxxxxx> 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.


To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba