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

[Mason Schmitt]

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