CentOS 6.8 And Samba

Home » CentOS » CentOS 6.8 And Samba
CentOS 12 Comments

Other than the original 6.8 release version 3.6.23-33, samba has not been functioning correctly for me under 6.8.

The symptoms are that about 6-7 days after starting the server, users start complaining that they can no longer open documents on their share. Upon inspection, I find several, sometimes nearly a dozen smb processes owned by a single user, on top of those run under root. Stopping the service does not stop these processes. They are only killable with SIGKILL, and after that, a service restart does not result in a functioning service, i.e. connections are refused, which can be verified easily with smbclient. The only cure is a server reboot. And it is not the same user id every time it happens. Useful logs of any type are not available.

I have tested -35 and -36, both show the same behaviour. This is a production server and I have no time for tinkering; downgrading to -33 and blocking samba updates is the only workaround for now.

12 thoughts on - CentOS 6.8 And Samba

  • 1. What is your output of testparm?
    2. If you run top, are any Samba related processes (winbindd, smbd, etc) consuming excessively high amounts of CPU?
    3. Have you considered cranking up or enabling logging to obtain some useful log info?
    4. Has this Samba server run correctly in the past? If so, has anything changed recently?
    5. You probably already know this but Samba 3.6.x is ancient. Have you considered running Samba 4.x? CentOS 6 repos have Samba 4.2.10 packages.
    6. Have you checked for corrupted Samba *.tbd files? Consider running tdbbackup:


  • No errors or warnings, apart from

    rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)

    I did not observe this, although the machine was running at a load of 1+ with no apparent culprit.

    Considered, yes, executed, no ;-)

    Yes, it always has, and works perfectly with -33. Timestamp on smb.conf shows it was last modified under 3.6.23-24, followed by updates to -25, -30, -35. With trial and error, I settled on -33 as last working version.

    Samba 4.x is an intimidating piece of software. If it can perfrom the same function and use the same config, I’m willing to try it.

    See 4. .tdb files look ok and tdbbackup gives no errors.

  • Without log messages or process table info, it’s hard to advise any further. Generally speaking, Samba4 can do everything that Samba 3.6 does. If your server is a domain member or standalone, it should be relatively straightforward.

    I migrated my Samba 3.6 servers to Samba4 when the badlock vulnerability was announced. My servers are AD domain members, so the migration was fairly simple. Without knowing which role (domain controller, domain member, standalone) your Samba server is providing, it’s difficult to comment on the complexity of migrating your server to Samba4.

    Consider spinning up a VM that is similar to your current server, including the same Samba 3.6 packages and your current smb.conf. See if you can replicate the problem your users are experiencing. Try upgrading the VM to Samba4 to see if the enabled features in your smb.conf file work with Samba4. Running testparm should tell you if it works (or not). When I performed my upgrade, I first had to discover which Samba 3.6.x packages were installed, then I had to remove those packages before installing the Samba4 packages. Backup your current smb.conf file prior to removing your Samba 3.6 packages. Check here for info on updating Samba: https://wiki.samba.org/index.php/Updating_Samba


  • I have another samba server and upgraded it to samba4. testparm returns clean with the old config (ROLE_DOMAIN_PDC) and starts up fine. smbclient seems to work fine.

    The next thing now is to try and make it a domain member so it can auth against AD.

    Thanks, Andrew, I appreciate the pointers.

  • You might want to take a look at “Integrating Red Hat Enterprise Linux 6 with Active Directory”. It’s the best document I’ve seen on this topic. I found that Samba/Kerberos/Winbind is the most complete solution for attaching a Samba fileserver in my AD environment. https://access.redhat.com/sites/default/files/attachments/rhel-ad-integration-deployment-guidelines-v1.5.pdf

    SSSD is really the way to go if you’re running CentOS 7, take a look at “Red Hat Enterprise Linux 7 Windows Integration Guide”:

    Below is my documentation on how to attach a RHEL/CentOS system to an Active Directory Domain using Samba/Kerberos/Winbind. This configuration will allow you to provide SMB file sharing and SSH logins for users in your AD domain. Note this works in my AD domain but there might be some additional settings required for your AD domain. Work closely with your AD domain administrator.

    The name of the example server in this document is server.example.com, substitute all values specific to your environment. Sample configuration files are included following these directions. The following packages should be installed:
    samba4, samba4-common, samba4-client, samba4-winbind, samba4-winbind-clients, krb5-workstation, openLDAP-clients

    1. Set NTP to use the correct server for your Active Directory domain:
    system-config-time Set the primary NTP server to be your domain/forest NTP server NTP_IP_address
    2. Make backups of and edit the following system configuration files:
    a. cp -p /etc/resolv.conf{,.bak}
    b. vi /etc/resolv.conf c. cp -p /etc/hosts{,.bak}
    d. vi /etc/hosts e. cp -p /etc/nsswitch.conf{,.bak}
    f. vi /etc/nsswitch.conf g. cp -p /etc/samba/smb.conf{,.bak}
    h. vi /etc/samba/smb.conf If you are editing a smb.conf file of a previously existing Samba fileserver, do not change the range value in the “idmap config * : range =” parameter i. cp -p /etc/krb5.conf{,.bak}
    j. vi /etc/krb5.conf
    3. Start the smb and winbind services:
    a. /etc/init.d/smb start b. /etc/init.d/winbindd start Note that smb and winbind daemons need to be set to start up on boot. In addition, the appropriate TCP ports will need to open on the system firewall if you are deploying a SMB/CIFS fileserver.
    4. Create a computer record in your Active Directory OU Computers container:
    For server.example.com create a computer record called server
    5. Initialize Kerberos and attach it to the Active Directory domain:
    a. kinit username b. net ads join -w EXAMPLE.COM -U username
    6. Verify the bind to AD is valid:
    a. net ads info b. net ads testjoin
    7. Create a Kerberos /etc/krb5.keytab file:
    net ads keytab create -U username
    8. Verify the contents of the Kerberos keytab file:
    klist -ke
    9. Add a share that has access restricted to an Active Directory group:
    a. mkdir /data b. vi /etc/samba/smb.conf After the [homes}, section add the following text:
    comment = Data Directory path = /data valid users = @”DOMAIN\AD_Group”
    writable = yes browseable = yes Substitute DOMAIN\AD_Group with an AD group that will be accessing this share. c. /etc/init.d/smb restart
    10. Enable home directory creation a. system-config-authentication b. In the Advance Options tab, check the “Create home directories on the first login” checkbox.
    11. Restrict SSH logins to a specific local and Active Directory groups Add this line to /etc/ssh/sshd_config:
    a. AllowGroups group_name Replace group_name with your local and AD group names. Note that the group names cannot have a space in the group name. Also make sure that at least one local group is added, otherwise you will not be able to SSH into your own server with a local account.
    12. Restart your server

    Sample files:

    /etc/resolv.conf search example.com nameserver IP_address

    /etc/hosts localhost.localdomain localhost IP_address server.example.com server

    /etc/nsswitch.conf passwd: files winbind shadow: files winbind group: files winbind hosts: files dns wins bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: nisplus automount: files aliases: files nisplus

    /etc/samba/smb.conf workgroup = example realm = EXAMPLE.COM
    server string = %h password server = *
    security = ads client use spnego principal = yes client use spnego = yes kerberos method = secrets and keytab server max protocol = SMB3
    client signing = auto server signing = auto machine password timeout = 0
    template shell = /bin/bash winbind use default domain = true winbind offline logon = false winbind refresh tickets = true idmap config * : range = 16777216-33554431

    default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log
    default_realm = EXAMPLE.COM
    default_keytab_name = /etc/krb5.keytab dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes
    kdc = kdc.example.com.:88
    kdc = IP_address admin_server = kdc.example.com kdc = IP_address
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM
    profile = /var/kerberos/krb5kdc/kdc.conf
    pam = {
    debug = false ticket_lifetime = 36000
    renew_lifetime = 36000
    forwardable = true krb4_convert = false


  • I already figured it out earlier this afternoon and have a working setup. Will review the above.

    [your setup instructions]

    Here, I’m not modifying any of the hosts/resolv.conf/nsswitch.conf files. This is not an integration exercise, only a samba fileserver with AD auth.

    winbindd(8) mentions “netlogon proxy only mode”, so I commented out all the range settings (after first verifying that it worked with them).

    I find it will not work without nmb.

    Brilliant, I didn’t know these commands.

    This is a step I was missing. What is the purpose of the keytab? Can it help with the default ticket FILE:/tmp/krb5cc_0 expiration?

    I’m also facing this problem, although everything seems to work fine. I’ve tested with smbclient and a Windows client.

    # net ads testjoin gss_init_sec_context failed with [Unspecified GSS failure. Minor code may provide more information: No credentials cache found]
    Join is OK

  • A Kerberos keytab contains Kerberos principals and encrypted keys which can be used to authenticate without entering a password. That should address your ticket expiration issue.

    Not sure what would cause that error message, nor have I experienced it. Looks like other people have seen it:

  • Am 14.09.2016 um 17:50 schrieb isdtor :

    If you have not done so already, I would definitely report this to upstream (bugzilla.redhat.com).

  • The bug report mentioned in the message you replied to indicates that the problem was fixed in samba’s master branch with this commit:


    That change isn’t included in samba 4.4, distributed in RHEL 7 (nor 4.2
    in RHEL 6), so you’ll probably need to patch the software yourself, or wait for a 4.5 or newer package (which won’t happen before the next point release, which is probably ~6 months away). If you’re a customer, you can also file a bug report and request that specific patch be reviewed as an enhancement for a future release.