samba - Aug 2016 - Certain systems can no longer access samba post upgrade to 4.3.9

During an ubuntu 14.04 update samba was updated from 4.1.6 to 4.3.9.  We
had no problems with any windows system accessing the server prior to the
upgrade to 4.3.9.  It seems to affect access to the entire samba server as
no shares are able to be seen or accessed when trying to view \\servername
or \\servname.domain.local

The "fix" seems to be to use the fully qualified name, but after a
while
that will stop working and you have to change to the short name and vice
versa.  I am trying to correlate the times to see if there is a pattern,
but no pattern has emerged yet.

What is odd is if the short name is failing and you change to fully
qualified and the share comes up, you will then be able to use the short
name to pull up the share after you have made the successful connection to
the fully qualified name.

The one log entry that seems to identify systems with this issue is this,
repeated over and over:

[2016/08/29 08:35:56.694436,  0]
../source3/param/loadparm.c:1460(canonicalize_servicename)
  canonicalize_servicename: NULL source name!

[2016/08/29 08:35:57.694984,  0]
../source3/param/loadparm.c:1460(canonicalize_servicename)
  canonicalize_servicename: NULL source name!

[2016/08/29 08:35:58.694495,  0]
../source3/param/loadparm.c:1460(canonicalize_servicename)
  canonicalize_servicename: NULL source name!

The majority of our servers are not having any problems accessing the samba
shares, but a few key high use systems are having this issue.

Has anyone seen this error and may have an idea what may be causing and
possible system setting that may need to be changed/enabled in 4.3.9 to
allow all systems to connect reliably?

On Mon, Aug 29, 2016 at 11:41:53AM -0400, Jeff Hodge via samba
wrote:
> During an ubuntu 14.04 update samba was updated from 4.1.6 to 4.3.9.  We
> had no problems with any windows system accessing the server prior to the
> upgrade to 4.3.9.  It seems to affect access to the entire samba server as
> no shares are able to be seen or accessed when trying to view \\servername
> or \\servname.domain.local
> 
> The "fix" seems to be to use the fully qualified name, but after
a while
> that will stop working and you have to change to the short name and vice
> versa.  I am trying to correlate the times to see if there is a pattern,
> but no pattern has emerged yet.
> 
> What is odd is if the short name is failing and you change to fully
> qualified and the share comes up, you will then be able to use the short
> name to pull up the share after you have made the successful connection to
> the fully qualified name.
> 
> The one log entry that seems to identify systems with this issue is this,
> repeated over and over:
> 
> [2016/08/29 08:35:56.694436,  0]
> ../source3/param/loadparm.c:1460(canonicalize_servicename)
>   canonicalize_servicename: NULL source name!
> 
> [2016/08/29 08:35:57.694984,  0]
> ../source3/param/loadparm.c:1460(canonicalize_servicename)
>   canonicalize_servicename: NULL source name!
> 
> [2016/08/29 08:35:58.694495,  0]
> ../source3/param/loadparm.c:1460(canonicalize_servicename)
>   canonicalize_servicename: NULL source name!
> 
> The majority of our servers are not having any problems accessing the samba
> shares, but a few key high use systems are having this issue.
> 
> Has anyone seen this error and may have an idea what may be causing and
> possible system setting that may need to be changed/enabled in 4.3.9 to
> allow all systems to connect reliably?
Can you post your smb.conf, plus a debug level 10 log from one
of the machines having the problem ?

On Mon, Aug 29, 2016 at 6:13 PM, Jeremy Allison <jra at samba.org> wrote:
> On Mon, Aug 29, 2016 at 11:41:53AM -0400, Jeff Hodge via samba wrote:
> > During an ubuntu 14.04 update samba was updated from 4.1.6 to 4.3.9. 
We
> > had no problems with any windows system accessing the server prior to
the
> > upgrade to 4.3.9.  It seems to affect access to the entire samba
server
> as
> > no shares are able to be seen or accessed when trying to view
> \\servername
> > or \\servname.domain.local
> >
> > The "fix" seems to be to use the fully qualified name, but
after a while
> > that will stop working and you have to change to the short name and
vice
> > versa.  I am trying to correlate the times to see if there is a
pattern,
> > but no pattern has emerged yet.
> >
> > What is odd is if the short name is failing and you change to fully
> > qualified and the share comes up, you will then be able to use the
short
> > name to pull up the share after you have made the successful
connection
> to
> > the fully qualified name.
> >
> > The one log entry that seems to identify systems with this issue is
this,
> > repeated over and over:
> >
> > [2016/08/29 08:35:56.694436,  0]
> > ../source3/param/loadparm.c:1460(canonicalize_servicename)
> >   canonicalize_servicename: NULL source name!
> >
> > [2016/08/29 08:35:57.694984,  0]
> > ../source3/param/loadparm.c:1460(canonicalize_servicename)
> >   canonicalize_servicename: NULL source name!
> >
> > [2016/08/29 08:35:58.694495,  0]
> > ../source3/param/loadparm.c:1460(canonicalize_servicename)
> >   canonicalize_servicename: NULL source name!
> >
> > The majority of our servers are not having any problems accessing the
> samba
> > shares, but a few key high use systems are having this issue.
> >
> > Has anyone seen this error and may have an idea what may be causing
and
> > possible system setting that may need to be changed/enabled in 4.3.9
to
> > allow all systems to connect reliably?
>
> Can you post your smb.conf, plus a debug level 10 log from one
> of the machines having the problem ?
>
It seems a workaround is to to set guest ok = yes on the user share.  We
have not seen the error since we made that change.

We also changed another share from user share to one configured in the
smb.conf file and have not seen the issue on that server since yesterday.
This may be a more permanent fix as we did not have to set guest ok = yes
on its share.

I will try to get an output of the logs at log level 10, however I have
been unable to reproduce this in our Dev environment.  Which class do you
want me to set logging level 10 on, or to be safe just use all?

Here is the smb.conf file in case anyone sees anything in there:

[global]
security = ads
netbios name = server104
netbios aliases = server04
realm = DOMAIN.LOCAL
idmap config * : range = 500-10000000
idmap config * : backend = tdb
winbind enum users = no
winbind enum groups = no
winbind refresh tickets = true
template homedir = /home/%D/%U
template shell = /bin/bash
client use spnego = yes
domain master = no
create mask = 0664
directory mask = 0775
machine password timeout = 0
hosts deny = 172.17.4.0/255.255.255.0
interfaces = eth1
bind interfaces only = yes
winbind max clients = 1000
winbind max domain connections = 10
log level = 1

   workgroup = DOMAIN
   server string = %h server (Samba, Ubuntu)
   dns proxy = no
   log file = /var/log/samba/log.%m
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\s*\spassword:* %n\n
*Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
   pam password change = yes
   map to guest = bad user
   usershare allow guests = yes

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700
[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no


User share:

#VERSION 2
path=/home/DOMAIN/
commentusershare_acl=S-1-1-0:F
guest ok = yes