Re: [Samba] Samba 4.6.2 member server errors
- Date: Mon, 23 Oct 2017 22:35:22 -0400 (EDT)
- From: Tom Diehl via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] Samba 4.6.2 member server errors
On Mon, 23 Oct 2017, Rowland Penny via samba wrote:
On Mon, 23 Oct 2017 13:56:27 -0400 (EDT)
On Fri, 20 Oct 2017, Rowland Penny via samba wrote:
On Fri, 20 Oct 2017 17:00:01 -0400 (EDT)
On Mon, 16 Oct 2017, Rowland Penny via samba wrote:
It seems to be treating computers as users (I could be barking up
the wrong tree here), can you post the contents
of /etc/hosts, /etc/hostname, /etc/resolv.conf
and /etc/nsswitch.conf from the domain member
Here you go:
# cat /etc/resolv.conf
search kmg.mydomain.com mydomain.com
I would remove 'mydomain.com' from the search line.
I also take it that '10.224.135.7' is a DC in the
'kmg.mydomain.com', if it isn't, remove this nameserver.
Yes, 10.224.135.7 is a DC.
The 2 name server ip addresses are the 2 dc's.
# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain
172.30.0.8 vfs1.kmg.mydomain.com vfs1
I would remove 'localhost.localdomain', there is no such thing as
# cat /etc/hostname
The hostname should just be 'vfs1', it shouldn't be the FQDN.
# cat /etc/nsswitch.conf
passwd: files winbind
group: files winbind
hosts: files dns myhostname
I would remove 'myhostname'
bootparams: nisplus [NOTFOUND=return] files
services: files sss
netgroup: files sss
aliases: files nisplus
I would remove the two 'sss' instances
I did net cache flush and rebooted. No change. Still getting the
kerberos errors and winbind not going to sleep when no one is in the
I am wondering if I were to remove the member server from the domain,
delete the tdb and ldb databases and then rejoin the domain if that
Is there a db that tracks the kerberos information that I could reset?
Besides the added work and the downtime, is there a down side to
doing this? If I understand correctly all of the important
information is stored in the DC's. Is this correct?
I have the following in the smb.conf on the member servers:
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config KMG:backend = ad
idmap config KMG:schema_mode = rfc2307
idmap config KMG:unix_nss_info = yes
idmap config KMG:range = 10000-999999
Unless I missed it, you have never said what OS this is.
It is Centos 7.4. They are VM's running on a vmware hypervisor.
In case it matters, There are 2 physical hosts. 1 DC and 1 Fileserver
on each physical hosts. When we are done the migration we will have total
of about 150 users split fairly evenly across the 2 physical hosts.
How did you get to 4.6.2, did you install it directly or was it an
upgrade from a previous Samba version.
This is a new domain. 2 self compiled 4.7.0 DC's and 2 member servers built
using the latest 4.6.2 rpms supplied with Centos 7.4 and configured as file
All were fresh installs.
Data is being migrated from a 10 year old samba 3.6 NT4 domain.
We chose to remove all of the windows 7 machines from the old NT4 domain
and join them to the new AD domain. All of the data is being rsync'd from
the old machines to the new file servers and permissions reset as necessary.
We did this to avoid problems associated with a classic upgrade and with
the exception of this problem it has gone well.
You said this is the only Unix domain member exhibiting this problem,
so you could try the windows fix, wipe the OS and start again ;-)
Well I think it is operating normally. There are 2 identical member servers
but only the server with the problem has data and users on it at this time.
The other one is currently in a different building and awaiting a move to
a new facility. Once it is in place, it is slated to go into production.
Light testing seems to show it is operating normally but given this issue,
I am not sure what it will do once I start transferring data to it and
loading it up.
Provided you use the same smb.conf as on the other Unix domain members,
you should have no problems.
Modulo the shares the smb.conf files are the same.
Just back everything up and leave the domain:
net ads leave -U Administrator
That is what I thought. Thanks for confirming that.
To unsubscribe from this list go to the following URL and read the