Hello,
We had a bad experience with Samba 4 AD DC on FreeBSD 9.2 Release
recently that I thought I would share on this mailing list. As a result
of this experience we were forced to downgrade back to Samba 3.5 for
stability. We performed initial tests on Samba 4 and found it
adequate. But, once we brought it up for production, we noticed a deal
breaking issue. When browsing a share, 90% of the time, the Samba
process will get stuck in some kind of loop and start using 100% of the
CPU it is assigned to. After scouring through the mailing list archives
and googling it, we found two bug reports (10158 and 10358) of similar
issues. Hoping to correct this problem we applied the provided
patches. Unfortunately, neither solved our problem. Samba processes
were still getting stuck at 100% cpu usage. This problem would affect
multiple Samba processes, sparked by users browsing Samba shares. After
two processes reached 100% cpu usage, the entire Samba group of
processes would freeze, making all shares unresponsive and inaccessible,
forcing us to restart Samba. We started monitoring samba processes
through top and killed any that started to reach 100% cpu usage. This
practice, as you can imagine, made for a bad user experience. The
smb4.conf file we used is as follows....
# Global parameters
[global]
workgroup = STANCORPBSD
realm = ESRECO.NET
netbios name = FRODO
server role = active directory domain controller
dns forwarder = 107.1.251.82
server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl,
winbind, ntp_signd, kcc, dnsupdate, dns, smb
dcerpc endpoint servers = epmapper, wkssvc, rpcecho, samr,
netlogon, lsarpc, spoolss, drsuapi, dssetup, unixinfo, browser,
eventlog6, backupkey, dnsserver, winreg, srvsvc
idmap_ldb:use rfc2307 = yes
logon drive = p:
logon script = logon.bat
domain logons = Yes
preferred master = Yes
domain master = Yes
nsupdate command = /usr/local/bin/samba-nsupdate -g
printing = bsd
[netlogon]
path = /var/db/samba4/sysvol/esreco.net/scripts
read only = No
log level = 3
[sysvol]
path = /var/db/samba4/sysvol
read only = No
[home]
path = /a/standard/home
read only = No
[profiles]
path = /a/standard/profiles
read only = No
csc policy = documents
[data]
comment = Data Store
path = /a/standard/data
write list = @staff, @wheel, @ar
read only = No
create mask = 0777
directory mask = 0777
....
Needless to say, we will be conducting the acid test on any future Samba
4 deployments before they're put into production. We were hoping that
minimal initial testing would be adequate because the team that develops
Samba is widely known for it's quality releases, and the Samba 3.x
series has been nothing but rock solid stable for us, but as you can
see, we were burned by that assumption. As for now, the software is, as
the install process indicates, "..still experimental.." and we will
remain with Samba 3.x until future Samba 4 releases are available,
hopefully correcting the nasty CPU usage bug (most likely some kind of
loop) we ran into.
However, we are not discounting the possibility that there may have been
a configuration problem. We suspected a problem with using the ntvfs
file system as opposed to the s3fs because we were coming from s3fs. We
were forced to use ntvfs because we primarily use ZFS as the underlying
file system on FreeBSD. We also used the built-in DNS with a a
forwarding IP for our main DNS server.
System/Software information:
FreeBSD 9.2 release
Samba 4.1.4
The Samba software was installed through the FreeBSD ports system.
Any suggestions or ideas of why Samba 4.1.4 failed us are welcome. We of
course would like to provide any information that will help track down
and crush this bug, which does make the software unusable on FreeBSD, IMHO.
Regards,
Eric
