Archive

Posts Tagged ‘Samba’

Install Samba Server on Red Hat Enterprise Linux/CentOS/Scientific Linux 6

March 26, 2011 7 comments

Recently the latest version of Scientific Linux 6 was released. Scientific Linux is a distribution which uses Red Hat Enterprise Linux as its upstream and aims to be compatible with binaries compiled for Red Hat Enterprise. I am really impressed with the quality of this distro and the timeliness with which updates and security fixes are distributed. Thanks to all the developers and testers on the Scientific Linux team!

In this post I will discuss installing Red Hat Enterprise Linux/CentOS/Scientific Linux 6 as a Samba server. The instructions should also be relevant to other Linux distros including CentOS. This example will rely on a local user database as the mechanism to provide security. In future posts I may discuss more complex scenarios including integrating the Samba server into Windows domains and Active Directory.

Let’s start off by installing the Samba server package and its dependencies:

# yum -y install samba

It is a good idea to set up a distinct group to allow access to the directory we will share. I will specify a group ID to prevent any overlap with the default groups created when individual users are added, which on most Linux distros these days start at 500 or 1000.

# groupadd -g 10000 fileshare

Now we will create a directory that will host our Samba share:

# mkdir /home/data

We need to modify the permissions on the directory to allow write access for users in our new group:

# chgrp fileshare /home/data
# chmod g+w /home/data

SELinux

UPDATE (5/10/2011): Recently I was setting up a Samba share on an existing file system that already contained files and I was unable to get SELinux configured to allow Samba to function correctly. This occurred even with using the -R option specified below to re-curse and relabel the existing files. So be aware that you may have problems like I did and you may need to set SELinux to permissive or disabled in the “/etc/selinux/config” file. In my case there were no denials logged in the “/var/log/audit/audit.log” so it was very difficult to troubleshoot.

Now we need to modify SELinux to allow access privilege to our new Samba share. By default this is denied and users will be unable to write files to the share. Details of the SELinux configuration needed can be found in the default config file “/etc/samba/smb.conf”.

Here are some good references regarding SELinux:

http://www.crypt.gen.nz/selinux/disable_selinux.html

http://wiki.centos.org/HowTos/SELinux

Now run the SELinux config command to allow user access to the Samba share directory. New directories and files created under our Samba share directory will be automatically inherit the SELinux context of the parent directory.  Use the -R option with “chcon” to re-curse if there are existing files in the directory you are sharing:

# chcon -t samba_share_t /home/data

Now we will create a user to access the Samba share. The command options specify to add the user to a supplementary group “fileshare”, do not create a home directory, and set the login shell to “/sbin/nologin” to prevent logins to the console. We only want the user access to the Samba file share:

# useradd -G fileshare -u 1000 -M -s /sbin/nologin aaron

Assign a password to this user, although the user shouldn’t have any console login privileges:

# passwd aaron

Now we need to set up our Samba configuration file.  I will move the existing config file and create a fresh copy to be more concise. But don’t delete it, as it contains a good amount of documentation so it is a handy resource if you want to add directives later.

Move the existing file and edit the new file:

# mv /etc/samba/smb.conf /etc/samba/smb.conf.bak

# vi /etc/samba/smb.conf

Now edit the new “smb.conf” file and add parameters like this:

[global]
workgroup = WORKGROUP
server string = samba
security = user
passdb backend = tdbsam
load printers = no

[data]
comment = data directory
path = /home/data
writeable = yes
public = no

The “global” section contains directives that apply to the whole Samba instance. We can define the workgroup or domain this server is a member of, what security mechanism to use (user, share, domain), and the password database type “tdb”. The old “smbpasswd” password file is no longer recommended for use on new installations. The “load printers” directive I set to “no” because I won’t be using the CUPS printing system and connection refused errors will show up in “/var/log/messages” unless this is specified.

The 2nd section (and on if you have more than one share) has details on each Samba file share. In this case the share is named “data”, we can define if it is writeable, and “public” defines whether users not in the Samba password database can access the share.

We should test the parameters of the “smb.conf” file to make sure there are no errors:

# testparm

Once you’ve run the “testparm” command and received no errors in the output you should be set to go. You may notice that some of the parameters won’t show in the output, this is fine and indicates that some are the Samba default. We’ll now make the Samba password for the user we are adding:

# smbpasswd -a aaron
New SMB password:
Retype new SMB password:

I received a bunch of output after entering the password that you can see below. From what I can tell this not a problem and it printed a message at the bottom that the user was added. Later when I fired up Samba and connected to the share with this user everything worked normally.

tdbsam_open: Converting version 0.0 database to version 4.0.
tdbsam_convert_backup: updated /var/lib/samba/private/passdb.tdb file.
account_policy_get: tdb_fetch_uint32 failed for type 1 (min password length), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 2 (password history), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 3 (user must logon to change password), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 4 (maximum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 5 (minimum password age), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 6 (lockout duration), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 7 (reset count minutes), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 8 (bad lockout attempt), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 9 (disconnect time), returning 0
account_policy_get: tdb_fetch_uint32 failed for type 10 (refuse machine password change), returning 0
Added user aaron.

To confirm that the user was added to the Samba tdb database use the “pdbedit” command:

# pdbedit -w -L

Now we need to make changes to the “iptables” firewall startup config file. Backup the file and edit:

# cp /etc/sysconfig/iptables /etc/sysconfig/iptables.bak

# vi /etc/sysconfig/iptables

Add the first line accepting packets on TCP/445. Be sure and add it above the last line of the “input” chain with the “Reject” target, that way the rule will be processed.

-A INPUT -p tcp --dport 445 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited

Now you can edit the “smb” daemon to start automatically, then start “smb”:

# chkconfig smb on
# service smb start

If you now switch over to a Samba/SMB client you should now be able to map a drive or browse the shares on the Samba server. If you want to browse the shares available you will need to manually enter something like “\\server1” or “\\192.168.100.1” without quotes in the address bar of Windows Explorer, the server won’t appear in Network Places. To enable full network browsing more configuration would be needed and you would probably need to enable the “nmb” daemon.

Happy Samba’ing!

Reference

http://www.howtoforge.com/fedora-13-samba-standalone-server-with-tdbsam-backend

Advertisements
Categories: Linux, Samba, Samba Tags: ,