• Ubuntu
• Swerdna
• openSUSE
• Open Source
• Open Sauce

Index Part I: Setting up the Infrastructure:

• • Preliminaries: Software and GUI configurators for Samba
• • Installing Name Resolution (for network browsing)
• • Installing Print Server Functionality
• • Installing Usershares Functionality
• • A Template for a Workgroup File and Print Server
• • Opening the UFW Firewall for Samba
• • Authentication and the Samba User Database

Index Part II: Defining and Using File Shares (for those who say: just show me the shares!)

• • Read-only Shares
• • Read-write Shares with Guest Access (requires no authentication)
• • Secure Read-write Shares; no Guest Access (requires authentication)
• • Special Purpose Modifications for Enhanced Privacy and/or Security

↑↑↑↑Preliminaries

Some of the material here is a repeat of material found also in the primer tutorial. I've included it to make this tutorial self contained and readable without reference to the other.

Samba software: Samba comes with a lot of functions, the chief of them being Samba client and Samba server. Samba client is installed by default but Samba server is not. For a fully functional workstation that shares and receives resources on a small business workgroup or a home LAN, you need packages smbclient, libsmbclient, samba-common, nautilus-share and samba. All except package samba are installed by default.

You can quickly check if all are installed by opening a Gnome terminal and running this command:

You should get a return listing the packages in the terminal window like this:

You can install any missing packages via System --> Administration --> Synaptic Package Manager.
[In Kubuntu GoTo: System Settings --> General --> Add and Remove Software].

Samba's configuration file: Samba's behaviour is controlled by its main configuration file, a simple text file named smb.conf, located at /etc/samba/smb.conf.

The file is made up of a number of sections called "stanzas". Each stanza begins with a name enclosed in square brackets [] on a new line. The [name] is followed by lines defining more parameters, one per line. Lines are made up of the parameter name on the left, an equals sign (=) and the value of the parameter on the right. Stanza names are case sensitive. Parameter names are case insensitive. Parameter values are sometimes case sensitive (e.g. the path in a filesystem) and sometimes not (e.g. yes is YES).

GUI configurators for Samba: There is a GUI editor for smb.conf, called swat, installable from Synaptic at System --> Administration --> Synaptic Package Management. It will strip any comment lines from the extensively-commented default installation of smb.conf, so I recommend that if you use swat, first you make a backup of smb.conf. If you want to adjust smb.conf, IMHO the easiest editors are the GUI text editors, gedit for Ubuntu and kate for Kubuntu. You can edit smb.conf easily with either of these command lines:

I recommend these Gnome and KDE editors for configuring Samba because they are the simplest and clearest available for implementing the simple recipes I've laid out here, significantly simpler that Swat. IMO gedit and kate are also safer than Swat.

↑↑↑↑Installing Name Resolution (for network browsing)

Name Resolution is the process whereby network names are resolved to IP addresses so network browsing can occur. The common ways of implementing this in Samba are discussed on a separate tutorial. Here I use only the most common method, Broadcast Name Resolution. This is the default used in a Microsoft Windows SOHO LAN. Broadcast Name Resolution is most effective in Samba when used with a Browse Master to coordinate and stabilise network browsing. You enable these functions for a Samba Server in the [global] stanza of the Samba configuration file, smb.conf located at /etc/samba/smb.conf.

This set of code boxes shows the lines in [global] of smb.conf that configure broadcast name resolution for a Samba server.

Three types are illustrated and you select according to the role to be played by the workstation, see below.

All of these are Local Master Browsers. They participate in elections to determine which workstation will collate the network names against IP addresses for the Workgroup and serve those naming data to the others. You can only have one Preferred Master in any Workgroup because they initiate elections if they are not the winning Master Browser in continual competition. All three types will beat a standard Windows 95/98, 2000, XP machine in elections. You do not have to use a Preferred Master on your Workgroup.

There are no hard and fast rules for picking which Type to assign to a machine. Here are some good, working guidelines:

• • Type 1: Use this if you have a machine that is central to the operation of the Workgroup, like a business file server or central print server, or a home multimedia server to the family. If you have several machines that fill this role choose only one to be Type 1 and make the other/s Type 2. It's OK to toss a coin.
• • Type 2: Use this for all other servers (i.e other than the Preferred Master).
• • Type 3: Use this for client workstations that rarely share resources.
• • Regardless of its role, a lone Linux machine on a LAN should not be Type 3 (chose 1 or 2).

Setting the daemons: You should set Samba to start when the system boots. Go to System --> Services Settings and click "Unlock" for privileged access. Scroll to "Folder sharing service" and enable samba. You can do a quick check to see if samba is running with htis terminal command:

FYI a few more options for this command are: stop, start, restart, status.

↑↑↑↑Installing Print Server Functionality

If you're going to share a printer you must add six printer-oriented lines to the [global] stanza, together with a special purpose share called [printers]. These are illustrated in the code box to the right.

Ubuntu devs have also recommended an optional share [print$] for storing Windows printer drivers, which is reproduced just below.

↑↑↑↑Installing Usershares (optional for advanced servers)

There are two classes of Samba shares, Classical shares and Usershares. The configurations for classical shares are set out in separate paragraphs, one for each share, in smb.conf, the main configuration file. The configurations for Usershares are set out in separate text files, one for each share, in a special folder located in Ubuntu at /var/lib/samba/usershares. In this tutorial I deal only with classical shares. Usershares are explained in a separate tutorial.

Gnome users make on-the-fly Usershares in Nautilus when they R-click on a folder and select "Sharing Options". The directory /var/lib/samba/usershares must exist and have permissions 1770 (sudo chmod 1770); it should exist by default. To turn the usershare functionality on, make sure the three lines in the adjacent code box are added to [global] in smb.conf.

I don't go further into Usershares in this Tutorial and have mentioned them only because they exist by default in Ubuntu. If you don't need Usershares on your server, simply ignore the three lines or delete or comment them out as you prefer; ignore the concept entirely if you like.

↑↑↑↑A template for a Workgroup file and print server

The default smb.conf conf installed in Ubuntu / Kubuntu is not well configured for network browsing, Usershares or a Workgroup scenario in a dual Windows / Linux environment.

All the adjustments that I've covered above have been put into the default configuration file to create the smb.conf file on the right which you should use as the starting point for a professional Samba Server.

You should backup your existing smb.conf, replace it with the version on the right and use that as a Workgroup server template, adding or deleting resources as desired.

The template is configured as a Preferred Master Browser. Remember, you can only have one per Workgroup. You can easily downgrade the template to the other common form, Type 2, by deleting the line preferred master = yes and lowering the operating system level to os level = 33. Then use that for the other servers in the workgroup.

I've added the line server string = . Without that line the server icon will display in network browsers with a string beside the server's netbios name that's typically like this: "(netbiosname server (Samba, Ubuntu))"; quite a mouthful. You can turn that off with the "server string" parameter as shown or instead place any alternative text you would like to have displayed in between the quotes.

I won't discuss printer sharing any further here because it deserves a separate tutorial. As an Administrator you can remove or leave the [printer] share to suit your needs.

↑↑↑↑Opening the UFW Firewall for Samba

The default Ubuntu firewall is ufw (= uncomplicated firewall). The default state for the firewall is "disabled", i.e. open to everything. It's a very wise idea to firewall workstations.

Samba uses the following ports for workgroup communications: TCP 139, TCP 445, UDP 137 and UDP 138. If you're connecting in a domain environment you can include TCP 135, which is not used in a Workgroup (i.e. not in a SOHO LAN). You will see on the Net various ways to add firewall rules for these ports so Samba can traverse the ufw firewall. The method I give here is a very secure method. It opens the Samba workgroup ports only for the IP address range used on your Samba LAN. Here is a simple four step recipe for configuring Ubuntu's ufw firewall for Samba.

Step 1: Turn on the ufw firewall

Here are some simple commands for manipulating ufw:

• • sudo ufw status: show the status of the firewall and list installed rules
• • sudo ufw disable: unload ufw and disable it at boot time too
• • sudo ufw enable: reload ufw and set it to load at boot time too

So switch it on permanently with the sudo ufw enable command.

Step 2: Turn on kernel connection tracking for Samba

The kernel has network connection tracking modules. The module for netbios-ns (UDP port 137) is not loaded by default. You must turn it on for Samba to penetrate the ufw firewall. The ufw default configuration file is /etc/default/ufw. Open it in a superuser text editor with this command: gksu gedit /etc/default/ufw. Locate this line towards the end of the file:

Add this fragment: nf_conntrack_netbios_ns, so it becomes like this:

save the file and reload the firewall to activate the change, with this terminal command: sudo ufw reload.

Step 3: Discover your Trusted Network

Your LAN communicates using a subnet of IP addresses like this example: 192.168.33,x where x takes values 1, 2, 3, and so on. The shorthand abbreviation for this whole range is 192.168.33.0/24. You want to allow the whole range through the firewall, so in that sense your so-called "Trusted Network" is 192.168.33.0/24 for this particular example. Take another example: maybe your IP address is 10.0.22.6. That means the workstations on your LAN would have IP addresses in the series 10.0.22.x where x takes values 1, 2, 3, and so on. Hence the Trusted Net is written as 10.0.22.0/24 for the LAN.

Let's run through it one more time from beginning to end, using my LAN. I first check my IP address with this terminal command: sudo ifconfig | grep Bcast. Here's the dialogue I get:

I've highlighted the IP address in red, 192.168.29.130, so the Trusted Net for my LAN is 192.168.29.0/24.

Step 4: Add firewall rules for Samba ports & your Trusted Network

Once you've figured out your Trusted Net, you add four firewall rules for ufw with these four console commands:

Of course, you modify "192.168.29.0/24" to match your situation.

Step 5: Check the configuration

You can interrogate ufw by running the command sudo ufw status. [If necessary reload ufw with command sudo ufw enable.] The "status" interrogation should yield a result like this:

Some people like to install and use the GUI interface for ufw, called Gufw. For your interest I've included a screenshot of Gufw when the rules have been added properly from the command line using the method in the code boxes above.

If you find you've made a mistake and need to re-do one or more of the rules, you can remove a rule using the delete command as in the example below (c.f. the top rule in the codebox above):

Gufu screenshots: Some people just hate the command line. They might be interested in these screenshots of installing the four rules using the GUI front end for ufw: TCP 139, TCP 445, UDP 137, UDP 138.

Firewall reference: UFW rules

↑↑↑↑Authentication and the Samba User Database

Access to Samba resources on the server first requires a decision by Samba software. Access to guests is given by including the directive guest ok = yes in the definition of the share in smb.conf, whereupon the guest assumes the rights and privileges of the (real) linux user with username nobody. If a share doesn't contain the directive guest ok = yes, then client access must be by way of authentication against a database of names and passwords stored in the Samba User Database. An administrator enters Samba users into the Database. The users must pre-exist as Linux users to be accepted. A user's Samba password can be different from the user's Linux password.

There are two important command line utilities, smbpasswd and pdbedit, for manipulating the Samba User database:

Add a user to the Database or change an existing user's password (as root) with smbpasswd:

Delete a user from the Database (as root) with smbpasswd:

List the users in the Database (as root) with pdbedit:

↑↑↑↑Part II: Defining and Using File Shares (Services)

I discuss a few shares in the Samba LAN Primer. The [homes] share there might be of interest in a business context. But here we'll discuss a finer grained suite for shares.

Permissions & Access: Access to a share is dictated by both the Linux permissions and Samba's access permissions. For example, if the Linux permissions are set for a directory to be readable only by the owner but the Samba permissions are set for read-write access to the world, the combined result will be that only the directory owner will gain entry to the share over the network and then only with read permissions. Generally, if two different options are presented by Linux and Samba permissions, the more restrictive of them will apply as the final result. The Linux Administrator must consider both aspects when setting up a share.

I have prepared and linked in a side tutorial on the use of the console commands chown (to change ownership) and chmod (to change permissions).

Structure: Each share is defined in a separate stanza in smb.conf. Shares are signified/started by putting the share name between square brackets on a new line (as in the example below) and following that with lines that define the properties.

The ShareName is what you see in your network browser and it's case sensitive. It may contain spaces although I generally avoid spaces because they can complicate path names for a remote user. The text on the comment line is displayed in network Browsers when you hover your mouse on the icon for the share. You don't have to have a comment line and I won't mention it again in this tutorial. Locate the shared directory anywhere sensible that suits you. It's wise for security purposes to make the owner a user other than root.

↑↑↑↑Read-only shares

The files in Share #2 are publicly available to any legitimate or illegitimate network user. The files in Share #1 are restricted to authenticated users. You can restrict access further by using the valid users parameter (see further down for full discussion).

↑↑↑↑Read-write Shares with Guest Access (requires no authentication): the two shares immediately below allow all network users to create, read, copy and delete content.

When a guest creates an object in the shared directory using Share #3, the objects become owned by user:group = nobody:nobody. This quaint result often causes administrative difficulties. To avoid it, make the shared directory in the name of a normal Linux user, e.g. anthony, and include the line force user = anthony in the stanza for the share. Objects created over the network will then be in the name of user:group = anthony:anthony, which is administratively very tidy. The Linux owner you choose does not have to be a member of the Samba user database.

↑↑↑↑Secure Read-write Shares; no Guest Access (requires authentication): users can create, read, copy and delete content. Share #5 leads off with a basic working share. The other examples show variations and specific purpose shares. All the shares from here on can only be accessed by members of the Samba user database.

↑↑↑↑Special Purpose Modifications for Enhanced Privacy and/or Security

Restricting the user group with valid users: Suppose you have a small group of network users, e.g. the Accounts Department comprised of Bill, Ethel and Starshine and you want a private share where they can keep they can keep sensitive financial documents and data. You simply ensure that they are all members of the Samba user database and then you include the valid users parameter in the stanza defining the share for the Accounts Department as follows:

This parameter can be included in all shares where network users gain access through authentication against the Samba user database. It works with the following example Shares: #1, #5, #6, #7 and #8.

Using valid users in Share #8 might seem strange, but: even though a user might assume the persona of the force user, first that user has to authenticate and if not in the valid users list, no access will be granted.

This concept can be conveniently extended to large numbers of valid users. Suppose a Chemistry Professor has 300 students who access subject-specific material. The administrator can set up a special group, e.g. the chemstudy group and create a share name [ChemUsers]. Then add the following line to the [ChemUsers] share:

This share is now restricted to all authentic users of the chemstudy group. To organise the group go to System --> Administrtaion --> Users and Groups and "unlock" to get admin privileges. Click Manage Groups --> Add Group and add the group chemstudy, at the same time enrolling all the appropriate usernames. This device works for shares where network users gain access through authentication

Limiting write access with write list: Suppose you have a share where a limited number of editorial users establish and maintain files for a broader audience. You want the broader audience to have read-only access while still allowing the group of editors read-write access. Include these lines in the stanza defining the share:

With this share, all authentic users can read the files, but only the named group can alter them. If the editorial members are numerous, you might prefer to define the write list in terms of a special group as demonstrated above in the chemistry example.

The End

Take it easy.

Swerdna: 4 July 2009

Articles Index

• Ubuntu
• Swerdna
• openSUSE
• Open Source
• Open Sauce