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

Rowland Penny rpenny at samba.org
Thu Apr 25 18:01:59 UTC 2019


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




More information about the samba mailing list