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

Hai, 

If i may suggest.. 

AD-DC, fine no changes needed. 
File server smb.conf, i made some changes, see below. 

I change the keytab and kerberos methode because your thinking that related to
the problem.
And i changed some settings below, which are moved from Global setting to Share
setting.

3 settings where defined as (S) as in, its a "share" setting, so put
it in the share definition.
Now i suggest, play with these 2:
    access based share enum = yes
    smb encrypt = desired

Other option try :  acl_xattr:ignore system acls = yes 
In place of acl_xattr:default acl style = windows 

Try as shown with the config below, then turn the smb encrypt off, try again.
Then the other, try again.  You know the drill.  ;-) test the 3 changes share
settings.

Stop and start samba after changing these settings ( no restart ).
Just to make sure everything is loaded as it should. 

(the file server's ) adjusted smb.conf


[global]

dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab

workgroup = REALM
security = ads
realm = REALM.EXAMPLE.COM

# Logging
log file = /var/log/samba/%m.log
log level = 3

idmap config REALM : range = 2000000-2999999
idmap config REALM : backend = rid
idmap config * : range = 10000-999999
idmap config * : backend = tdb

winbind use default domain = no
winbind refresh tickets = yes
winbind offline logon = yes
winbind enum groups = no
winbind enum users = no

username map = /etc/samba/user.map
bind interfaces only = yes
interfaces = lo eth0

vfs objects = acl_xattr
map acl inherit = yes
store dos attributes = yes

#disable netbios = yes
# just disable the start up of nmbd. 

template shell = /bin/false
template homedir = /srv/samba/Users/%U


[Users]
	  acl_xattr:default acl style = windows
        access based share enum = yes
	  smb encrypt = desired
        path = /srv/samba/Users
        comment = Share for user home dirs
        guest ok = no
        read only = no

[Shared]
	 acl_xattr:default acl style = windows
       access based share enum = yes
       smb encrypt = desired 
       path = /srv/samba/Shared
       guest ok = no
       read only = no

Greetz Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Mason Schmitt via samba
> Verzonden: donderdag 25 april 2019 5:29
> Aan: Rowland Penny
> CC: samba at lists.samba.org
> Onderwerp: Re: [Samba] Windows clients require reboot once a 
> day in order to access mapped drives
> 
> >
> > At this point I'm starting to get in over my head and could use
some
> > direction.  This looks like a Windows 10 client bug, but 
> given that I can't
> > see the full SMB conversation (due to encryption) I'm not 
> certain whether
> > the samba server is replying in the way the client expects. 
>  Can you or
> > someone else help me either find a work around or a 
> resolution?  Because
> > the Windows 7 clients (SMB2 not SMB3) don't exhibit this 
> behaviour, I'm
> > thinking that forcing all clients to downgrade to SMB2 
> would probably work
> > around the issue.  Can you confirm this?  If not, I can 
> just try it and see
> > what happens.
> >
> 
> I added "server max protocol = SMB2" to my smb.conf file.  
> After restarting
> smbd, I tried to connect using a windows 10 client and was 
> denied (error
> message on the client and server says that a parameter is 
> incorrect).  I
> rebooted the PC and tried again.  No go...  So apparently 
> it's not possible
> to force W10 to downgrade to SMB2?
> 
> I'm really hoping someone is able to give me something to go on here,
> because now I'm really stuck....
> 
> >
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
> 
>

Hi Louis,

Thanks for your willingness to help!

I change the keytab and kerberos methode because your thinking that
related
> to the problem.

dedicated keytab file = /etc/krb5.keytab
> kerberos method = secrets and keytab

I looked at these earlier in my process and according to the smb.conf man
page, it looks like these commands aren't meant to be used together (but it
won't hurt anything either).  When setting kerberos method = secrets and
keytab, it appears that samba will create it's own keytab file
(secrets.tdb) and look there for a valid ticket first and then fall back to
the system keytab file.  I don't tend to like having this sort of fallback
behaviour, because it increases complexity and adds variables to the
troubleshooting process, so I'm more inclined to set the kerberos method to
"secrets only", so that Samba only uses it's own secrets.tdb
keytab.  I
think I'll try this.


And i changed some settings below, which are moved from Global setting
to
> Share setting.
>
> 3 settings where defined as (S) as in, its a "share" setting, so
put it in
> the share definition.
> Now i suggest, play with these 2:
>     access based share enum = yes
>     smb encrypt = desired
>
I can move these items to share definitions and see what happens.  Have you
seen issues where moving settings from global to individual share
definitions resolves issues?  If so, that seems like a bug.


Other option try :  acl_xattr:ignore system acls = yes
> In place of acl_xattr:default acl style = windows
>
The first option, for ignoring system ACLs, is evil...  If you follow the
samba wiki's process for setting up a file share, using windows ACLs, but
you have "acl_xattr:ignore system acls = yes " in your smb.conf, it
will
not work.  However, if you have an existing share, that is already
correctly setup with windows ACLs, then you can add this line, after the
fact, and everything will keep working.  So, I'll give this suggestion a
miss.


Try as shown with the config below, then turn the smb encrypt off,
try
> again.
> Then the other, try again.  You know the drill.  ;-) test the 3 changes
> share settings.
>
I agree that turning smb encrypt off is a good thing to try.  It might help
me to see a clue in a packet capture, that would otherwise be obscured by
the encryption.  I did make this change last night, but I haven't had the
time to take a fresh packet capture yet.  I'll do this today and report
back my findings.

I'm also going to try dropping the kerberos ticket lifetime way down, to
see if the symptoms appear earlier.  I'm trying to confirm that the SMB
session expiration does actually have something to do with kerberos ticket
renewals and not some other SMB session timer.

 --
Mason

On Thu, 25 Apr 2019 10:24:01 -0700
Mason Schmitt via samba <samba at lists.samba.org> wrote:
> dedicated keytab file = /etc/krb5.keytab
> > kerberos method = secrets and keytab  
> 
> 
> I looked at these earlier in my process and according to the smb.conf
> man page, it looks like these commands aren't meant to be used
> together (but it won't hurt anything either).  When setting kerberos
> method = secrets and keytab, it appears that samba will create it's
> own keytab file (secrets.tdb) and look there for a valid ticket first
> and then fall back to the system keytab file.  I don't tend to like
> having this sort of fallback behaviour, because it increases
> complexity and adds variables to the troubleshooting process, so I'm
> more inclined to set the kerberos method to "secrets only", so
that
> Samba only uses it's own secrets.tdb keytab.  I think I'll try
this.
When you set 'kerberos method = secrets and keytab', Samba will first
check 'secrets.tdb' (which isn't a keytab) then the system keytab.

The default is to just check the secrets.tdb

You only need a keytab on disk (usually /etc/krb5.keytab) if something
else needs to read the keytab (NFS etc) and in this case you would need
these lines:
    kerberos method = dedicated keytab
    dedicated keytab file = /etc/krb5.keytab


> 
> 
> And i changed some settings below, which are moved from Global
> setting to
> > Share setting.
> >
> > 3 settings where defined as (S) as in, its a "share"
setting, so
> > put it in the share definition.
> > Now i suggest, play with these 2:
> >     access based share enum = yes
> >     smb encrypt = desired
> >  
> 
> I can move these items to share definitions and see what happens.
> Have you seen issues where moving settings from global to individual
> share definitions resolves issues?  If so, that seems like a bug.
Anything that is really meant for a share can usually also be put into
[global]. This will mean that it will affect everything and you may not
want this.
 
> 
> 
> Other option try :  acl_xattr:ignore system acls = yes
> > In place of acl_xattr:default acl style = windows
> >  
> 
> The first option, for ignoring system ACLs, is evil... 
Not really, it all depends on how you set the ACL's and where from ;-)

I have the feeling that you think the ACL's can only be shown by
'ls'
or 'getfacl' because they are only stored in two places, but if you set
them from Windows, they are also stored in a 'EA'. This means that,
provided you only have Windows clients, you can set 'acl_xattr:ignore
system acls = yes' and get better NT ACL support.

> If you follow
> the samba wiki's process for setting up a file share, using windows
> ACLs, but you have "acl_xattr:ignore system acls = yes " in your
> smb.conf, it will not work.  However, if you have an existing share,
> that is already correctly setup with windows ACLs, then you can add
> this line, after the fact, and everything will keep working.  So,
> I'll give this suggestion a miss.
> 
Louis, can you confirm this ? If you can I will update the wiki.
 
Rowland

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Rowland Penny via samba
> Verzonden: donderdag 25 april 2019 20:02
....
> 
> 
> > If you follow
> > the samba wiki's process for setting up a file share, using
windows
> > ACLs, but you have "acl_xattr:ignore system acls = yes " in
your
> > smb.conf, it will not work.  However, if you have an existing share,
> > that is already correctly setup with windows ACLs, then you can add
> > this line, after the fact, and everything will keep working.  So,
> > I'll give this suggestion a miss.
> > 
> 
> Louis, can you confirm this ? If you can I will update the wiki.
Well, first i need to know which one is used: 
>From : https://wiki.samba.org/index.php/Samba_File_Serving
https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
Or 
https://wiki.samba.org/index.php/User_Home_Folders

Hmm, but i've seen some things and yes, there is something off.. 
Not that im saying its wrong, but is not setup as on a real windows server. 
I'll verify it, next week i'm buzy with a new ubuntu server to setup, 
i'll test a bit on that one because that one i can easy snapshot and only as
the base setup at the moment.

Ow, i test with samba 4.10.2 then, that ok? Or do you preffer an other version. 

But yes we need a change there. 

@rowland 
Please reminde me next week, or i'll forget it. 

And, yes, kingsday ( use to be queensday) 
You want to see holland go crazy.. Well. It looks like this. 
https://www.google.com/search?q=konings+dag+holland&tbm=isch&source=iu&ictx=1&fir=bxHbcoa7RM93FM%253A%252CLKg30MNvzNkVzM%252C%252Fg%252F11b7nx2x3l&vet=1&usg=AI4_-kQLmla4v33a8tt6Hmp6TrEUGjo2Dw&sa=X&ved=2ahUKEwia6_eKgO7hAhULyqQKHQxICsYQ_B0wDnoECAwQBg#imgrc=_&vet=1

:-) 

Greetz, 

Louis

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 :)

-- 

Mason

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