|
|
Though Samba is quite simple to run, administrators should be aware of a few common problems. In this section, we describe some configurations you might want to make to your Samba installation. We pay particular attention to Samba security.
| Tip |
If you need more help on a problem not covered here, check the files in the /usr/share/doc/samba* directory. You can also look through the Samba mailing list archives at http://lists.samba.org/archive/samba. |
SMB and Samba were not made for file and printer sharing outside the LAN environment. If you suspect that someone is gaining access from outside of your private network to your Samba service, here is a checklist of things you can do:
Block perimeter firewalls-Every network feature that is intended for use on a private LAN should always begin with a strong firewall configuration on the perimeter of that LAN. Perimeter firewalls (those with connections to the outside world) should block ports 137, 138, 139, and 445 to external interfaces. However, computers on your LAN that you want to have Samba access should make those ports accessible.
Computers with external as well as internal connections to your private network can have different ports blocked or open on different interfaces.
In a home or small office situation, where a Samba server acts as a router, as well as a file/printer server, you can use iptables with the -i option to selectively allow or block access to a particular interface. For example, to identify an interface in a rule definition for the first Ethernet card, you would add -i eth0 to the options you give to the iptables command.
Block interfaces-Within Samba, you can define the interfaces it will use for browsing, name registration, and related NetBIOS communications. By default, Samba listens on all network interfaces available on the computer. You can identify interfaces by interface name (eth0), IP address with netmask (192.168.0.10/255.255.255.0), or CIDR-style IP address (192.168.0.10/24) in the smb.conf file. Here's an example:
interfaces = eth0
Block host access-You can block host access to the Samba service on your server in the /etc/samba/smb.conf file. Typically, the best way to do this is to allow access only to selected computer or group network addresses and deny all others. Here is an example:
host allow = 127.0.0.1 192.168.10.0/24 host deny = 0.0.0.0/0
This example allows connection to the Samba service from the local host or any computers on the 192.168.10 network (presumably your local LAN). Access from all other hosts is denied.
Block users and groups-As with blocking hosts, the best way to block unwanted users is to allow only selected users to have access to your Samba service. To do that, add a list of valid users or groups to your smb.conf file. For example:
valid users = mary, jim, bill, sarah, @marketing @sales
In this example, clients who successfully log in with the names mary, jim, bill, or sarah are allowed access. Likewise, users from the groups marketing and sales can also have access.
Other types of security are best described in terms of the security mode you are using.
The security mode you choose will have the most dramatic effect on who can connect to your shared directories and printers, as well as how you otherwise configure your Samba server. The following sections describe each mode, and mention some of the different challenges you may face depending on the security level you choose.
The share security level, which was once the default level used with Samba, is no longer encouraged. It may be useful in cases where an older Windows client needs to connect, but you can't get it to provide the proper type of username and password. However, the more secure alternative is to upgrade the client, and not leave your Samba installation vulnerable.
Modern Samba security is managed in user level. When a client tries to connect to a Samba server, the client sends username, password, and name of the client machine. Given the permissions set for that user, he or she will be able to mount any shares the server allows him to.
There are different subtypes of user authentication in Samba-domain, ADS, and server modes-as, well as plain user mode with a username/password pair.
With domain security, a domain member can sign on once to a primary Domain Controller's Security Account Manager (SAM) database. The client machine, rather than an individual user, is authenticated in this scheme. Thus, it is not the best solution for a Samba installation that must have individual verification, but it is useful for group workstations or relatively open networks.
If the Samba server is participating in an NT4 domain, which authenticates both the user and the machine, it can be set to act as a member server to provide members with a number of services:
A central location to authenticate for access to all member machines in the domain
Associated file ownership and access
Ability to use network logins
Ability to access network applications, based on the rights of the authenticated user
The Domain Controller server maintains Machine Trust Account information (referred to as a secret) that a client machine uses to authenticate. Note that NT4 domains do not use Domain Controllers, but rather Primary Domain Controllers.
| Note |
Not all Windows operating systems support Machine Trust Account information. Windows 95, Windows 98, Windows ME, and Windows XP Home cannot be full domain members. Windows NT, Windows 2000, and Windows XP Professional can be full domain members. In general, the business versions of Windows are more secure than the individual versions. |
Use the smb.conf file to set various options for domain mode security.
ADS mode takes advantage of Microsoft's Active Directory Service. In this mode, the Samba server can join an ADS domain and take advantage of Kerberos user authentication rather than NT-compatible authentication methods. If you choose to use ADS mode, you must specify values for the realm and security options in smb.conf, as in
realm = local.Kerberos.REALM security = ADS
With this security mode, the Samba server tries to use another SMB server, previously designated as a password server, to authenticate users. This server is specified in smb.conf with the password server option. This option takes the NetBIOS name of the password server machine.
| Caution |
Samba no longer recommends use of server security mode (user level security), for a number of reasons. For example, there is no way to ensure that the password server requested is the one that is ultimately used. Even if the proper password server is used, a given session may remain open for much longer than necessary. There are too many security compromises with this security mode for the modern safety-conscious installation. |
The special [homes] section offers special opportunities (and problems) related to shared home directories. Here are some problems you may encounter and potential ways around them.
Too much user access-Users who are allowed access to certain shared directories may get access to directories that they are not intended to share. Once users log in to a Samba server, they have the permissions of a Linux user. If users leave access to their /home directories open so other users can view or change their files in Linux, permissions are open from Samba as well.
The solution is to make sure that user Linux file and directory permissions are set to provide the Samba access you intend. For example, home directories should usually be closed to access by anyone but the owner of that directory (which they are by default). Guest users should not have access to the [homes] share. To solve the problem of unwanted access to home directories, add a users list to the global section of the smb.conf file:
valid users = %S
Then add the following line to the [homes] section:
only user = %S
Users can close permission to their own home directories while they are logged into Linux by typing chmod 700 $HOME.
Different home directory path-You may put your home directories somewhere other than /home. In that case, you can add a path option to the [homes] share. For example, to direct Samba that you store your home directories in /var/people (such as /var/people/sarah, /var/people/mike, and so on), you could add this line to smb.conf in the [homes] section:
path = /var/people/%S
When you use the [printers] section to share all the printers listed in the Samba server's /etc/printcap file, you may encounter some of the following common problems:
Can't see printers from client-Make sure the printable = yes option is set. Otherwise, Samba won't load the printers from the /etc/printcap file.
Don't want to share all printers-If you would rather share a limited number, but not all, of the printers in your /etc/printcap file, you can copy the printers you want to share to a different file. Then, for example, if you wanted to share printers listed in the /etc/prcap2 file, you could add the following to your [printers] section:
printcap name = /etc/prcap2
Printer settings are wrong-In most cases, you should set printer options (such as duplex, paper size, and so on) in the printer settings tool of the Windows clients. To try to have Samba generate Device Mode, you can add the line
This should be tested before putting it into service, however, since it can cause the client print spooler to crash.
One of the biggest tricks in Samba is getting names to address resolution to work properly. On a single LAN with a WINS server, you are likely to experience fewer problems than you would if you are trying to configure workgroups that cross multiple subnets or are simply broadcasting availability of services without a central place for resolving names.
Having a Samba name server is a good idea. Without one, Samba will just broadcast to ask who has the address for a client requesting service. If there are conflicting names on the network, this could cause problems. Here is how a Samba machine gets the IP addresses for the NetBIOS names it encounters:
Local NetBIOS hosts (lmhosts)-First, Samba checks the /etc/samba/lmhosts file. You can use this file to map a particular NetBIOS name to an IP address. For example, to map MYPC to address 192.168.0.5, you would add this line:
192.168.0.5 MYPC
TCP/IP hosts lookup (host)-Next, Samba uses the mechanism used to resolve any IP address on your system to find the IP address for the NetBIOS name it is looking for. The search uses the contents of the /etc/nsswitch.conf and /etc/host.conf files. By default, this will cause the /etc/hosts file to be checked, followed by NIS and DNS lookups.
WINS server (wins)-You should specify a WINS server to resolve NetBIOS addresses whenever possible. You can do that using the wins server option. If no WINS server is identified, Samba will skip this step.
Broadcast (bcast)-If the name is still not found, Samba will broadcast for the IP address of the computer it is trying to contact on any defined interfaces. (By default, it will use all known network interfaces, unless restricted by the interfaces parameter.)
You can change the order in which names and addresses are resolved using the name resolve order option. The following global option in the smb.conf file would cause the WINS server to be used before the default TCP/IP host lookup, but after any local names are resolved from the lmhosts file:
name resolve order = lmhosts wins host bcast
With no special configuration, most Windows SMB servers/clients just broadcast their NetBIOS names on the network using UDP broadcast packets. So in the default configuration, Windows file and printer sharing is restricted to the local LAN since broadcast messages will not, by default, cross subnet boundaries. There are two ways around this problem if you do not want to run a WINS server:
lmhosts-Add addresses to the Windows client's lmhosts file to identify the names and IP addresses of all computers it wants to communicate with outside of the local subnet.
Remote announce-A Samba client can force an announcement of itself on a remote network, using the remote announce option. That causes the Samba server to be put on the browse list of Windows clients on a remote network.
It is always more reliable, however, to assign a WINS server for SMB/Samba file and printer sharing. The WINS server can then route information about the Windows peer outside of the local LAN.
By default, TCP/IP names are used as NetBIOS names for Samba servers. If you want to identify your Samba server by a different NetBIOS name, use the netbios name option in smb.conf. You might need to do this if you have a particularly long host name. For example, to change the Samba server's NetBIOS name to TRICKSY, you could add the following line:
netbios name = TRICKSY
Some of the most common problems have simple solutions. If a client cannot connect to a server across the network, it might be something as simple as the server having stopped functioning or the client being configured improperly. There are different solutions for clients and servers under Linux and Windows.
Here are some things to check if you can't see a shared Windows folder from Linux:
File and Print Sharing-On the Windows machine, right-click on a folder. If no Sharing option appears on the menu, you probably need to turn on File and Print Sharing for the computer. From Windows, check that File and Print Sharing are turned on (from Control Panel ⇨ Network ⇨ File and Print Sharing, then select to give others access to your files and let others share your printers).
Sharing-If the Sharing option appears when you right-click, select it. Then turn on Share As and select the appropriate options for sharing the folder.
If you cannot connect to the Samba server from a Windows machine, consider some of these common reasons why you may not be able to connect:
Is Samba running?-Make sure that Samba is running:
# ps ax |grep smb 31406 ? S 0:00 smbd -D
If it's not, start it with the command service smb start, and set it to turn on automatically when your server starts up with the chkconfig smb on command.
Firewall-If you enabled the firewall feature on the Samba server when you installed Linux, you are probably blocking access to ports needed to provide the Samba service. Turn off your firewall temporarily by issuing the command iptables -F. If your client can connect, turn the firewall back on with service iptables restart. Then fix your firewall to allow connections on ports 137, 138, and 139 from the clients on your LAN to which you want to allow access.
Windows 98 clients may generate a particular sort of Samba error. If you open Network Neighborhood from a Windows 98 client and a pop-up window asks for a password to make this connection to Resource: \\server\IPC$, no password will work. The problem is that, instead of asking for a login name and password, Windows 98 automatically supplies your current Windows username and password in encrypted form to the Samba server. When that fails, Samba asks for another password. There are several possible solutions to this common problem:
Make sure that the same account name and password on the Windows 98 client is configured on the Samba server if you are using user level security.
If you prefer, you can map the Windows username to the Linux username by editing the /etc/samba/smbusers file. For example, to map Windows user chris to Linux user chrisn, add this line to /etc/samba/smbusers:
chrisn = chris
If the username and password are correct, but connections are still failing, check whether you are allowing encrypted passwords in the Samba server. Alternatively, you can change registry entries to enable plain text passwords.
| Tip |
Registry settings for various versions of Windows can be found in the /usr/share/doc/samba*/docs/Registry/ file. |
In most cases, Samba tends to be a minimal user of system resources. If you notice that Samba is causing performance problems on your server machines, you may want to tweak your installation so that it runs faster and more smoothly. There are two options in smb.conf that are of particular help in improving server performance:
Auto disconnect-If there are a lot of inactive connections to your Samba server, it can be a drag on performance. To disconnect after a certain number of minutes of dead time, you could set the deadtime parameter. For example, to disconnect a share from a client after an hour of inactivity, set this global option in the smb.conf file:
deadtime = 60
Limit connections-You can use the max connections option to limit how many connections are allowed to a particular service. For example, you could add the following to a share section in smb.conf to limit the maximum number of connection to 20:
max connections = 20
Samba assigns Linux file and directory permissions when someone tries to add, modify, or delete files and directories through SMB. You can change that behavior somewhat using some of the following settings in the smb.conf file:
Restrict directories-If users are able to get into a directory structure that you would rather keep them out of, you can use the dont descend option to restrict access to any point below a selected point in the file system. (This feature can be a bit flaky, so use standard Linux file permissions to restrict access in most cases.) Here's an example:
dont descend = /proc,/dev
Unexpected permissions for DOS users-You can change Samba's behavior from Linux to DOS-like when it comes to the rights to modify file and directory permissions. To do that, add the following to the global section:
dos filemode = yes
Problems changing file times from DOS-Check the dos filetime resolution and dos filetimes options.
Following symbolic links-By default, Samba will follow symbolic links that are in shares. To turn off that behavior, add the following line to a share definition:
follow symlinks = no
Forcing file/directory creation modes-You can force the file permissions used when someone creates a file or directory in a Samba share. Use the force create mode and force directory mode parameters. These parameters are used in conjunction with the create mask and directory mask options.
|
|