Configuring Samba  on Red Hat

News

Summary  Recommended Links

Accessing Linux Shares from Windows

Samba Daemons Troubleshooting Samba problems Configuring samba Users
 Samba Daemons SMB Protocol Authentication  GUI configuration of samba on Red Hat Connecting from Windows 7 client to to Red Hat Samba shares Horror Stories Humor Etc

The key to configuring Samba is its configuration file, smb.conf. This configuration file can be very simple or extremely complex, and the rest of this book is devoted to helping you get deeply personal with this file. For now, however, we'll show you how to set up a single file service, which will allow you to fire up the Samba daemons and see that everything is running as it should be. In later chapters, you will see how to configure Samba for more complicated and interesting tasks.

RHEL  installation process automatically create an smb.conf configuration file. In addition several example files are included in the Samba distribution in the samba-3.0.x/examples/ directory. To test the server software, we'll use the following file, which you can create in a text editor of your choosing. It should be named smb.conf and placed in the /usr/local/samba/lib directory:[*]

[*] If you did not compile Samba, but instead downloaded a binary, check with the documentation for the package to find out where it expects the smb.conf file to be. Or, check the output from smbd -b and locate the value of the CONFIGFILE variable. If Samba came preinstalled with your Unix system, an smb.conf file is probably already somewhere on your system.

[global]
    workgroup = GARDEN
    encrypt passwords = yes
[test]
    comment = For testing only, please
    path = /export/tmp
    read only = no

This brief configuration file tells the Samba server to offer the /export/tmp directory on the server as an SMB share called test. Parameters in smb.conf are case-insensitiveópath is the same option as PATH. They are also whitespace-insensitive so that read only and ReadOnly are interpreted as the same parameter. Values, however, may or may not be case-insensitive, depending on their use. For example, a username or a directory path should be considered to be case-sensitive, yet Samba interprets Boolean value such as yes or no as case-insensitive strings.

Our server will operate as part of the GARDEN workgroup, of which each client should also be a part. If you have already chosen a name for your own workgroup, use the existing name instead of GARDEN in the previous example. In case you are connecting your server to an existing network and need to know the workgroup name, ask another system administrator or go to a Windows system in the workgroup and follow these instructions for Windows 2000/XP/2003:

We'll use the [test] share in the next chapter to set up the Windows clients. For now, you can complete the setup by performing the following commands as root on your Unix server:

# mkdir -p /export/tmp
# chmod 1777 /export/tmp			

 Encrypted Passwords

Password encryption is one of those areas where interoperability between Windows and Unix/Linux systems gets extremely messy. Both sides of the fence use a different nonreversible encryption algorithm, which means that you cannot generically convert Unix passwords to the LanMan or NT password hashes or vice versa.

There is even widespread misunderstanding about Windows support for password encryption and the associated NTLM challenge/response authentication protocol. The myth is that Microsoft added support for encrypted passwords only with the release of the Windows 95 network redirector update and Windows NT 4 Service Pack 3. The truth is that all Microsoft operating systems (including the DOS LanMan client) support NTLM authentication and therefore support at least one of these password encryption algorithms, either the LanManager or the NT password hashes. The misunderstanding stems from the fact that prior to these operating system updates, Windows clients would downgrade to sending the clear text of a password if the remote SMB/CIFS server did not support password encryption. Of course, there are ways to exploit this behavior and gain access to users' passwords. Therefore, Microsoft decided that it was a good idea to disable the capability to automatically fall back to clear text authentication. It can still be done, even on Windows 2003, but requires a registry setting change and a client reboot.

Samba 3.0 follows this same path to interoperability. Because Windows clients no longer send clear text passwords without explicit configuration changes, Samba defaults to requiring that you, as the administrator, create LanMan and NT password hashes for all the users who will be accessing your server. But as there is no way to convert the existing /etc/passwd entries to Samba's password format, you have to start from scratch.

Samba does support authenticating users against the system's /etc/passwd file, NIS passwd map, and PAM stack, but you must ensure that all clients have clear text authentication for CIFS connections enabled. As previously noted, this is not the default behavior in modern Microsoft clients. 

By default, Samba 3.0 enables the encrypt passwords option. For the sake of clarity, and because you may not be familiar with all of Samba's default settings, we add the following line to our smb.conf in the [global] section.

encrypt passwords = yes

The smbpasswd program (typically located in the directory /usr/local/samba/bin/ ) can be used to enter the username/password combinations of the Samba users into Samba's encrypted password database. For example, to allow Unix user lizard to access shares from a client system, use this command:

# smbpasswd -a lizard
New SMB password: <enter password for lizard>
Retype new SMB password: <re-enter password for lizard>
Added user lizard.
 

Samba requires that all users accessing the system be mapped to a valid Unix uid. This includes guest users, who are mapped to the specified guest acount.

 

When the first user is added, the program may output a message saying that the encrypted password database does not exist. Don't worry: it will then create the database for you. Make sure that the username/password combinations you add to the encrypted database match the usernames and passwords that you intend to use on the Windows client side. You must run smbpasswd for each client user that will authenticated access to the server. 

For a Windows user to gain access to Samba  services on a Linux system, the user must provide a Windows username and a Samba  password.

For a Windows user to gain access to Samba  services on a Linux system, the user must provide a Windows username and a Samba  password.

In some cases, Windows supplies the username and password for you. It is also possible to authenticate using other methods. For example, Samba  can use LDAP

Usernames

The supplied username must be the same as a Linux username or must map to a Linux username. Samba  keeps the username maps in /etc/samba/smbusers. Users with the same username on Linux and Samba  do not need to appear in this file, but they still need a Samba  password.

When you install Samba, smbusers  has two entries:

$ cat /etc/samba/smbusers
# Unix_name = SMB_name1 SMB_name2 ...
root = administrator admin
nobody = guest pcguest smbguest

The first entry maps the two Windows usernames (administrator  and admin) to the Linux username root. The second entry maps three Windows usernames, including guest, to the Linux username nobody: When a Windows user attempts to log in on the Samba  server as guest, Samba  authenticates the Linux user named nobody.

Passwords

Samba  uses Samba  passwordsónot Linux passwordsóto authenticate users. By default, Samba  keeps passwords in /etc/samba/smbpasswd. As Samba  is installed, authentication for root  or nobody  would fail because Samba  is installed without passwords: The smbpasswd  file does not exist.

Each of the configuration techniques described in this chapter allows you to add users to smbusers  and passwords to smbpasswd. You can always use smbpasswd  as discussed later in this section to add and change passwords in smbpasswd.

Note

When you attempt to connect from Windows to a Samba  server, Windows presents your Windows username and password to Samba. If your Windows username is the same as or maps to your Linux username, and if your Windows and Samba  passwords are the same, you do not have to enter a username or password to connect to the Samba  server.

Example

You can add the following line to smbusers  to map the Windows username sam  to the Linux username sls:

sls = sam

You can add the following line to smbusers  to map the Windows username sam  to the Linux username sls:

sls = sam

[Index Term: |JumpStart|configuring a Samba  server with system-config-samba][Index Term: |Samba|JumpStart, configuring a Samba  server with system-config-samba][Index Term: |Samba|system-config-samba  utility][Index Term: |system-config-samba  utility][Index Term: |Utility|system-config-samba]You can add a password for sls  to smbpasswd  with the following command:

# smbpasswd -a sls
New SMB password:
Retype new SMB password:
Added user sls.

Now when Sam uses the username sam  to log in on the Samba  server, Samba  maps sam  to sls  and looks up sls  in smbpasswd. Assuming Sam provides the correct password, he logs in on the Samba  server as sls.

Configuring a Samba  Server Using system-config-samba

The system-config-samba  utility can set up only basic features of a Samba  server. It is, however, the best tool to use if you are not familiar with Samba  and you want to set up a simple Samba  server quickly. The system-config-samba  utility performs three basic functions: configuring the server, configuring users, and setting up shares (directory hierarchies) that are exported to the Windows machines.

Tip: Make a copy of smb.conf

As installed, the /etc/samba/smb.conf  file has extensive comments. The system-config-samba  utility overwrites this file. Make a copy of smb.conf  for safekeeping before you run this utility for the first time.

Manually Configuring a Samba Server

The /etc/samba/smb.conf file controls most aspects of how Samba works and is divided into sections. Each section begins with a line that starts with an open bracket ([), includes some text, and ends with a close bracket (]). The text within the brackets identifies the section. Typical sections are

[globals] Defines global parameters
[printers] Defines printers
[homes] Defines shares in the homes directory
[share name] Defines a share (you can have more than one of these sections)

smb.conf comments

As installed on a Fedora/RHEL system, the /etc/samba/smb.conf sample configuration file contains extensive comments and commented-out examples. Comment lines in smb.conf can start with either a pound sign (#) or a semicolon (;). The sample file uses pound signs to begin lines that are intended to remain as comments and semicolons to begin lines that you may want to mimic or use as is by removing the semicolons. The following segment of a smb.conf file contains two lines of true comments and seven lines beginning with semicolons that you may want to uncomment and make changes to:

# A private directory, usable only by fred. Note that fred requires
# write access to the directory.
;[fredsdir]
;   comment = Fred's Service
;   path = /usr/somewhere/private
;   valid users = fred
;   public = no
;   writable = yes
;   printable = no

Assuming the global parameters in smb.conf are set properly, you need to add a share for a Windows system to be able to access a directory on the local Linux system. Add the following simple share to the end of the smb.conf file to enable a user on a Windows system to be able to read from and write to the local /tmp directory:

[tmp]
        comment = temporary directory
        path = /tmp
        writable = yes
        guest ok = no

The name of the share under Windows is tmp; the path under Linux is /tmp. Any Windows user, including guest, who can log in on Samba, can read from and write to this directory, assuming that the userís Linux permissions allow it. The Linux permissions that apply to a Windows user using Samba are the permissions that apply to the Linux user that the Windows user maps to.

Parameters in the smbd.conf File

The the smb.conf man page and the Help feature of swat list all the parameters you can set in smb.conf. The following sections identify some of the parameters you are likely to want to change.

Global Parameters
interfaces A SPACE-separated list of the networks that Samba uses. Specify as interface names (such as eth0) or as IP address/net mask pairs (page 443). Default: all active interfaces except 127.0.0.1
server string The string that is displayed in various places on the Windows machine. Within the string, Samba replaces %v with the Samba version number and %h with the hostname.

Default: Samba %v

Fedora/RHEL: Samba Server
workgroup The workgroup that the server belongs to. Set to the same workgroup as the Windows clients that use the server. This parameter controls the domain name that Samba uses when security (page 762) is set to DOMAIN.

Default: WORKGROUP

Fedora/RHEL: MYGROUP
 
Security Parameters
encrypt passwords YES accepts only encrypted passwords from clients. Windows use encrypted passwords by default. This parameter uses smbpasswd to authenticate passwords unless you set security to SERVER or DOMAIN, in which case Samba authenticates using another server.

Default: YES

Samba defaults to storing encrypted passwords in the smbpasswd file if you do not set up passdb (a password database). Storing passwords in the smbpasswd file is sensible on servers with fewer than 250 users. For high-load servers, consult the Samba HOWTO collection for information about configuring a database back end.
guest account The username that is assigned to users logging in as guest or mapped to guest; applicable only when guest ok (page 765) is set to YES. This username should be present in /etc/passwd but should not be able to log in on the system. Typically guest account is assigned a value of nobody because the user nobody can access only files that any user can access. If you are using the nobody account for other purposes on the Linux system, set this variable to a name other than nobody. Default: nobody
hosts allow Analogous to the /etc/hosts.allow file (page 447), this parameter specifies hosts that are allowed to connect to the server. Overrides hosts specified in hosts deny. A good strategy is to specify ALL in hosts deny and to specify the hosts you want to grant access to in this file. Specify hosts in the same manner as in hosts.allow. Default: none (all hosts permitted access)
hosts deny Analogous to the /etc/hosts.deny file (page 447), this parameter specifies hosts that are not allowed to connect to the server. Overridden by hosts specified in hosts allow. If you specify ALL in this file, remember to include the local system (127.0.0.1) in hosts allow. Specify hosts in the same manner as in hosts.deny. Default: none (no hosts excluded)
map to guest Defines when a failed login is mapped to the guest account. Useful only when security is not set to SHARE.

Never: Allows guest to log in only when the user explicitly provides guest as the username and a blank password.

Bad User: Treats any attempt to log in as a user who does not exist as a guest login. This parameter is a security risk because it allows a malicious user to retrieve a list of users on the system quickly.

Bad Password: Silently logs in as guest any user who incorrectly enters his or her password. This parameter may confuse a user when she mistypes her password and is unknowingly logged in as guest because she will suddenly see fewer shares than she is used to.

Default: Never
passwd chat The chat script that Samba uses to converse with the passwd program. If this script is not followed, Samba does not change the password. Used only when unix password sync is set to YES. Default: * new * password * %n\n*new*password* %n\n * changed *
passwd program The program Samba uses to set Linux passwords. Samba replaces %u with the userís username. Default: /usr/bin/passwd %u
security Specifies if and how clients transfer user and password information to the server. Choose one of the following:

USER: Causes Samba to require a username and password from users or Windows when logging in on the Samba server. With this setting you can use

  • username map to map usernames to other names
  • encrypt passwords (page 760) to encrypt passwords (recommended)
  • guest account (page 761) to map users to the guest account

SHARE: Causes Samba not to authenticate clients on a per-user basis. Instead, Samba uses the system found in Windows 9 x, in which each share can have an individual password for either read or full access. This option is not compatible with more recent versions of Windows.

SERVER: Causes Samba to use another SMB server to validate usernames and passwords. Failing remote validation, the local Samba server tries to validate as though security were set to USER.

DOMAIN: Samba passes an encrypted password to a Windows NT domain controller for validation.

ADS: Instructs Samba to use an Active Directory server for authentication, allowing a Samba server to participate as a native Active Directory member. (Active Directory is the centralized information system that Windows 2000 and later use. It replaces Windows Domains, which was used by Windows NT and earlier.)

Default: USER
unix password sync YES causes Samba to change a userís Linux password when the associated user changes the encrypted Samba password. Default: NO
update encrypted YES allows users to migrate from cleartext passwords to encrypted passwords without logging in on the server and using smbpasswd. To migrate users, set to YES and set encrypt passwords to NO. As each user logs in on the server with a cleartext Linux password, smbpasswd encrypts and stores the password in /etc/samba/smbpasswd. Set to NO and set encrypt passwords to YES after all users have been converted. Default: NO
username map The name of the file that maps usernames from a client to usernames on the server. Each line of the map file starts with a server username, followed by a SPACE, an equal sign, another SPACE, and one or more SPACE-separated client usernames. An asterisk (*) on the client side matches any client username. This file frequently maps Windows usernames to Linux usernames and/or maps multiple Windows usernames to a single Linux username to facilitate file sharing. A sample map file is shown here:
$ cat /etc/samba/smbusers
# Unix_name = SMB_name1 SMB_name2 ...
root = administrator admin
nobody = guest
sam = sams

[Index Term: |Samba|browser parameters][Index Term: |Samba|logging parameters]Default: no map

Fedora/RHEL: /etc/samba/smbusers
Logging Parameters
log file The name of the Samba log file. Samba replaces %m with the name of the client system, allowing you to generate a separate log file for each client.

Default: none

Fedora/RHEL: /var/log/samba/%m.log
log level Sets the log level, with 0 (zero) being off and higher numbers being more verbose. Default: 0 (off)
max log size An integer specifying the maximum size of the log file in kilobytes. A 0 (zero) specifies no limit. When a file reaches this size, Samba appends a .old to the filename and starts a new log, deleting any old log file.

Default: 5000

Fedora/RHEL: 50
 
Browser Parameters

The domain master browser is the system that is responsible for maintaining the list of machines on a network used when browsing a Windows Network Neighborhood or My Network Places. SMB (page 1106) uses weighted elections every 11Ė15 minutes to determine which machine will be the domain master browser.

Whether a Samba server wins this election depends on two parameters: First, setting domain master to YES instructs the Samba server to enter the election. Second, the os level determines how much weight the Samba serverís vote receives. Setting os level to 2 should cause the Samba server to win against any Windows 9 x machines. NT Server series domain controllers, including Windows 2000, XP, and 2003, use an os level of 32. The maximum setting for os level is 255, although setting it to 65 should ensure that the Samba server wins.

 

domain master YES causes nmbd to attempt to be the domain master browser. If a domain master browser exists, then local master browsers will forward copies of their browse lists to it. If there is no domain master browser, then browse queries may not be able to cross subnet boundaries. A Windows PDC (Primary Domain Controller) will always try to become the domain master and may behave in unexpected ways if it fails. Refer to the preceding discussion. Default: AUTO
local master YES causes nmbd to enter elections for the local master browser on a subnet. A local master browser stores a cache of the NetBIOS (page 1095) names of entities on the local subnet, allowing browsing. Windows machines automatically enter [Index Term: |Samba|communication parameters][Index Term: |Samba|share parameters]elections; for browsing to work, the network must have at least one Windows machine or one Samba server with local master set to YES. It is poor practice to set local master to NO. If you do not want a computer to act as a local master, set its os level to a lower number, allowing it to be used as the local master if all else fails. Default: YES
os level An integer that controls how much Samba advertises itself for browser elections and how likely nmbd is to become the local master browser for its workgroup. A higher number increases the chances of the local server becoming the local master browser. Refer to the discussion at the beginning of this section. Default: 20
preferred master YES forces nmbd to hold an election for local master and enters the local system with a slight advantage. With domain master set to YES, this parameter helps ensure that the local Samba server becomes the domain master. Setting this parameter to YES on more than one server causes the servers to compete to become master, generating a lot of network traffic and sometimes leading to unpredictable results. A Windows PDC (Primary Domain Controller) automatically acts as if this parameter is set. Default: AUTO
 
Communication Parameters

 

dns proxy When acting as a WINS server (page 1115), YES causes nmbd to use DNS if NetBIOS (page 1095) resolution fails.

Default: YES

Fedora/RHEL: NO
socket options Tunes the network parameters used when exchanging data with a client. The Fedora/RHEL setting is appropriate in most cases. Default: TCP_NODELAY
wins server The IP address of the WINS server that nmbd should register with. Default: not enabled
wins support YES specifies that nmbd act as a WINS server. Default: NO
 

Share Parameters

Each of the following parameters can appear many times in smb.conf, once in each share definition.

 

available YES specifies the share as active. Set this parameter to NO to disable the share, but continue logging requests for it. Default: YES
[Index Term: |Samba|[homes] share][Index Term: |Samba|browsing Linux shares from Windows][Index Term: |Samba|home directories, sharing][Index Term: |Samba|Linux shares|accessing from Windows]browseable Determines whether the share can be browsed, for example, in Windows My Network Places.

Default: YES

Fedora/RHEL: NO
comment A description of the share, shown when browsing the network from Windows.

Default: none

Fedora/RHEL: varies
guest ok Allows a user who logs in as guest to access this share. Default: NO
path The path of the directory that is being shared.

Default: none

Fedora/RHEL: various
read only Does not allow write access. Default: YES
 

The [homes] Share: Sharing Usersí Home Directories

Frequently users want to share their Linux home directories with a Windows machine. To make this task easier, Samba provides the [homes] share. When you define this share, each userís home directory is shared with the specified parameters. In most cases, the following parameters are adequate:

[homes]
        comment = Home Directories
        browseable = no
        writable = yes

These settings prevent users other than the owners from browsing home directories, while allowing logged-in owners full access.

SELinux

If the system is running SELinux with a targeted policy and you want to allow users to share their home directories as explained in this section, you must turn on the SELinux setting SambaAllow Samba to export user home directories as displayed by system-config-selinux (page 416) in the Boolean tab.


Recommended Links

Top Visited

Bulletin Latest Past week Past month
Google Search



How to Configure SAMBA on a Linux Server Linux Help

samba workgroups - Bing Videos (for OpenSuse)