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:
Right click on My Computer icon and select Properties.
The workgroup or domain name should be listed in the windows after selecting the Network Identification (or Computer Name) tab.
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
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.
|
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
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.
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.
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.
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.
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.
| 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 |
| 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
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 |
| 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 |
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 |
| 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 |
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 |
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.
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.
|
|
||||
| Bulletin | Latest | Past week | Past month |
|
How to Configure SAMBA on a Linux Server Linux Help
samba workgroups - Bing Videos (for OpenSuse)