It is very possible (and easy) to have a fully functioning SMB server capable of seamlessly serving up content with its built-in networking tools to any Windows host. However, it is also possible that this installation, while it was password protected, was only protected via a username and password challenge and not with any other restrictions.

In this Daily Drill Down, we will look at some of Samba’s additional parameters that can be enabled via the smb.conf file to provide better security, as well as additional functionality for the software. I will also introduce you to the Samba nmblookup and testparm utilities that let you test your Samba configuration for syntax errors and other possible problems.


Part one, “Share files and control your domains in a heterogeneous network with Samba 2.2.2,” and part two, “Call SWAT or Webmin to administer your Samba 2.2.2,” of this series looked at some of the basic features of Samba and discussed some of the ways that it can be managed. The articles focus on the installation and configuration of a new Samba server, methods for making it an authentication server—or domain controller in Windows—and the installation of two GUIs used to manage the software.

First, the preliminaries
Before we actually begin this discussion, we need to establish a baseline to use for configuration. For this article, I will assume the following:

  • You are running Samba 2.2.2, and it resides in /usr/local/samba.
  • You have a Windows client that you can mess with. I am using a Windows 2000 Professional workstation for my testing.

For the purposes of this Daily Drill Down, let’s start with the following base configuration file (/usr/local/samba/lib/smb.conf):
       workgroup = SWG
       netbios name = PEAR
       server string = Samba process on Pear
       encrypt passwords = Yes
       logon path =
       preferred master = False
       local master = No
       domain master = False
       comment = Domain logon
       path = /usr/local/samba/netlogon
       browseable = No
       read only = No
       comment = Samba installation
       path = /usr/local/samba
       read only = No

Once you have this configuration in place, restart the Samba processes so that Samba can refresh itself, and then continue on to the fun part.

The fun part (a.k.a., restricting users)
Most IT people that I know have at least a small streak of “control freak” in them, and they generally put it to constructive use by properly restricting users in their environments and by setting up a sound security policy.

You can extend this trait, as well as your security policy, into your Samba installation via options in your smb.conf file. First, verify that you can connect to your Samba server from a Windows machine. On my Windows 2000 Professional workstation, I just browse to \\pear\slowe to do this. Pear is my Samba server and my user account is slowe. Since I have defined a [Homes] section in my smb.conf file, I am able to browse there.

You should see a few files in your home directory, possibly including .profile, .bash_profile, and .bash_history. At this point, you might be thinking to yourself that these files really don’t serve any purpose to a Windows user who is browsing to this Linux machine over an SMB connection. So let’s not allow them to be displayed over the [Homes] share.

First, browse to your home directory on the Samba server (see Figure A) \\pear\slowe.

Figure A
You should see files similar to the ones highlighted here.

Next, close that window and add the following line to the [Homes] section in your smb.conf file:
veto files = /.profile/.bash_*/

Restart the Samba processes to refresh its configuration, and then browse to the same share.

Figure B
The restricted files do not appear in the Home directory in the refreshed configuration.

As you can see in Figure B, the files that we placed in the veto list no longer appear as a part of the share. The files will be listed, however, if you navigate to this directory via a telnet or SSH connection and issue an lsal.

Note that placing the veto directive in the [Homes] section does not prevent the files in the restricted list from appearing in other shares. For example, as a test, I manually created a .profile in /usr/local/samba, which, as you can see from the initial configuration, has been shared as Samba for Windows clients. When I browse to \\pear\samba, I will indeed see .profile listed, since the [Samba] share is separate from the [Homes] share.

What do you do if you want to prevent a specific file from being shared over Samba for all shares? One option would be to place a veto directive in each share’s configuration. But, a better option is to place your veto directive in the [Globals] section. This will have the same effect as placing the directive in each and every share.

And to add one more point of confusion, let’s say that you want to veto certain files for all but one share. You can place the veto directive in the [Globals] section as we just discussed and then place the line veto files = in the share configuration and restart Samba. Your files will be vetoed for all shares, except for the shares that have their own veto directives.

A quick overview of veto files:

  • Purpose: Provide a mechanism for preventing specific files from being shared
  • Location in smb.conf: Either in [Globals] or a part of a share configuration
  • Parameters: UNIX style names are allowed, each file in the file list is separated by a / character, and the wildcards * and ? are allowed. By default, the filename is not case sensitive.
  • Example: Veto files = /.profile/.bash_*/

Restricting Samba access by IP address or range
My lab network is on the subnet (or /24). I have four machines active on it right now as listed in Table A.

Table A
IP Address Name Description slowe-nb My laptop running Windows 2000 Professional Pear My RedHat Linux 7.1 Samba Server scott-2ks A Windows 2000 Server scott-2kp A Windows 2000 Professional workstation
My lab network setup

For this exercise, we’re going to deny scott-2kp from accessing any Samba services, including shares and printers. To do this, make the following modifications to your /usr/local/samba/lib/smb.conf file:

  • Remove all veto files directives from the previous exercise.
  • In the [Globals] section, add a line hosts deny = and then restart the Samba processes. Of course, you will need to specify an IP address of an actual host on your own network.

When you try to browse to any of the shares on the Samba server from the restricted host, you will be greeted with a dialog box indicating that the network path could not be found.

The converse to the hosts deny directive is the hosts allow directive. A hosts allow directive lets you specify which hosts are allowed to use the Samba services and no others. For example, if you were to put a single IP address in the hosts allow directive, then only that IP address will have access to the Samba services. To prevent outside access, a good practice would be to explicitly allow your entire network and then to deny specific hosts on your network that should not be allowed access.

You should note that placing the hosts allow or hosts deny directives in a share configuration will allow you to disable particular shares for certain hosts.

A quick review of hosts allow and hosts deny:

  • Purpose: Allow access to Samba resources based on specific IP address or NetBIOS machine name
  • Location in smb.conf: Either in [Globals] or a part of a share configuration
  • Parameters: A list of IP addresses/subnet masks or NetBIOS machine names separated by a space or a comma (The EXCEPT keyword can be used to exclude a particular host from the list.)
  • Examples: Hosts deny =, Hosts deny = EXCEPT Hosts allow = slowe-nb, scott-2ks

Security based on users
At this point, you may be satisfied with the restriction capabilities that Samba provides. But there’s more. You can also prevent specific users from accessing Samba resources.

We’ll quickly touch on this via the following example:

  • Remove all hosts deny and hosts allow directives from smb.conf.
  • Add an invalid users = slowe line in the [Globals] section of your smb.conf file, substituting slowe with your user id.

Once you are done, when you try to browse to your home directory, you should be greeted with a login dialog box. You can, of course, enter a different username and password at this prompt, but the directive is useful for normal users that you need to restrict from certain resources.

The converse of this directive is valid users.

A quick review of the valid and invalid user directives:

  • Purpose: Provides a mechanism for preventing access by specific users
  • Location in smb.conf: Either in [Globals] or a part of a share configuration
  • Parameters: UNIX user IDs, separated by a comma or a space
  • Examples: Invalid users = slowe root Valid users = root slowe

Using these sets of directives, you will be able to secure your Samba server against unwanted users and machines, as well as filter which files are accessible to your Windows clients.

Utilities to help test the system
Samba comes with a number of utilities to assist with the setup and configuration of the server. One of these utilities, testparm, is useful for finding potential errors in your smb.conf file. This is a very simple utility to run. Simply type /usr/local/samba/bin/testparm at the command line and press [Enter].

The testparm utility will parse your smb.conf file and look for errors in syntax. Here is sample output from that utility with an intentional error thrown in for good measure.
Load smb config files from /usr/local/samba/lib/smb.conf
Unknown parameter encountered: “local maste”
Ignoring unknown parameter “local maste”
Processing section “[netlogon]”
Processing section “[homes]”
Processing section “[samba-dist]”
Processing section “[samba]”
Processing section “[htdocs]”
Processing section “[testuser]”
Loaded services file OK.
WARNING: You have some share names that are longer than 8 chars
These may give errors while browsing or may not be accessible
to some older clients
Press enter to see a dump of your service definitions

You can see that the output from testparm produced one warning and one error. The error was in the [Globals] section, and I left the r off master. The warning indicates that some share names are longer than eight characters, which can cause problems with older Windows clients. None of the new versions of Windows suffer from this problem.

The testparm utility can also take a hostname parameter, which allows you to test your hosts deny and hosts allow directives without the need for a Windows client. To test this, I will add a hosts deny = scott-2kp directive in the [Homes] section of my smb.conf file.

Now, issue a /usr/local/samba/bin/testparm hostname scott-2kp [Enter] at the command line. You will see the same information initially, but it will be followed by a parsing of all of the shares with the following output:
WARNING: You have some share names that are longer than 8 chars
These may give errors while browsing or may not be accessible
to some older clients
Allow connection from hostname (scott-2kp) to netlogon
Deny connection from hostname (scott-2kp) to homes
Allow connection from hostname (scott-2kp) to samba-dist
Allow connection from hostname (scott-2kp) to samba
Allow connection from hostname (scott-2kp) to htdocs
Allow connection from hostname (scott-2kp) to testuser

You should see the Deny connection information for the [Homes] share. This is a very quick way to make sure that there are no typos in your smb.conf file.

The final topic for this article is an overview of the nmblookup utility. Nmblookup gives a Samba administrator the ability to test network (and SMB) connectivity from the Samba server to a Windows host. Want to see all of the TCP/IP interfaces on a Windows machine? Issue a /usr/local/samba/bin/nmblookup -B slowe-nb ‘*’ command on your Samba server, replacing slowe-nb with a Windows machine name on your network. In my configuration, I get the following results when I run this command.
querying * on *<00> *<00> *<00> *<00>

Or maybe you want to see what NetBIOS names a particular Windows host had registered. Issue a /usr/local/samba/bin/nmblookup scott-2kpS [Enter] to get the following results.
querying scott-2kp on scott-2kp<00>
Looking up status of
        SCOTT-2KP       <00> –         B <ACTIVE>
        SLOWE           <00> – <GROUP> B <ACTIVE>
        SCOTT-2KP       <03> –         B <ACTIVE>
        SCOTT-2KP       <20> –         B <ACTIVE>
        SLOWE           <1e> – <GROUP> B <ACTIVE>
        SLOWE           <03> –         B <ACTIVE>

Okay, that’s enough of that. Issue a /usr/local/samba/bin/nmblookup to get a list of all of the available options.

Part four to provide overview of advanced configurations
This concludes part three of our Samba overview. Part four of the series will focus on more advanced Samba configurations that include joining a Samba server to an existing Windows 2000 domain, allowing Windows clients to use a Samba server to store their roaming profiles, and enabling printing support via Samba.