• openSUSE Home
• Swerdna
• Ubuntu
• 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 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

Software RPMs: Add the openSUSE RPM repository for Samba. Go to Yast --> Software Repositories --> Add --> Specify URL. Choose a web address for your Suse version from the variety available on this Community link e.g. for 11.2 use this:
  http://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_11.2/
Then in Yast Software Management install/upgrade these RPMs:

• • For all Desktop Environments: samba, samba-doc, yast2-samba-client, samba-client, yast2-samba-server
• • Gnome users add this: nautilus-share
• • If you need cifs mounts (mapped drives) add cifs-mount

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: The openSUSE GUI editor for smb.conf is Located at Yast --> Network Services --> Samba Server. Stay away from the icon for Windows Domain unless you want to join a Domain. It's hard to undo that. Within the "Samba Server" layer there are confusing and complex tools to edit the various lines that appear in smb.conf and to create file and print shares. I firmly believe that area is for quite advanced users. The paradox is that advanced users prefer to edit the configuration files directly because they're only simple text files. If you want to adjust [global] in smb.conf, IMHO the easiest editors are the GUI text editors, gedit for Gnome and kwrite for KDE. 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.

There are two GUI configurators in Yast's Network Services area, one for "Samba Server" and one for "Windows Domain Membership". Do not poke around in "Windows Domain Membership" GUI if you are configuring a Workgroup. It will install properties in smb.conf that confuse the configuration. Avoid the area in the "Samba Server" GUI titled "Identity" because of it's tendency to install unwanted parameters into smb.conf. It's much easier to type the parameters you need using kdesu or gedit text editors.

In my personal opinion (based on my experience) there are safe GUIs and unsafe GUIs in Yast for manipulating the firewall for Samba. I only describe the "safe" ones here.

↑↑↑↑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 four 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. There are two daemons involved; viz: nmbd, the NetBIOS name server to provide NetBIOS over IP naming services to clients and smbd, the Samba server to provide SMB/CIFS services to clients. These are set to always on in Yast --> System --> System Services (Runlevels). Locate nmb and smb in the list on the LHS and toggle them to on (if they are off). If there is still a problem, switch to "Expert mode" and make sure they are checkmarked to start at runlevels 3 and 5.

You should restart both daemons in a console, nmbd first, smbd second, whenever you adjust Samba's settings. Here are the console commands:

FYI a few more options for rcnmb and rcsmb 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.

OpenSUSE devs have also included a share in the default smb.conf for storing and serving printer drivers to client machines, which I haven't reproduced here.

↑↑↑↑Installing Usershares

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 openSUSE at /var/lib/samba/usershares. In this tutorial I deal only with classical shares. Usershares are explained in a separate tutorial. Usershares are available in openSUSE commencing version 10.2, not before.

Gnome users make on-the-fly Usershares in Nautilus when they R-click on a folder and select "Sharing Options". For these to work in openSUSE, 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 included their configuration only because the default configuration in openSUSE is not optimal (in my opinion). If you don't need Usershares on your server, simply ignore the three lines or delete or comment them out as you prefer.

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

The default smb.conf conf installed in Suse/openSUSE 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. I haven't included the file shares that are supplied by default in openSUSE installations. You can include those if you wish -- and there are some more shares of a different nature discussed below.

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: Samba 3.2.6-0.1.134-2034-SUSE-CODE11. 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. Please see the tutorial titled:
openSUSE 10 and 11 Samba Print Server.
As an Administrator you can remove or leave the [printer] share to suit your needs.

↑↑↑↑ Opening the Firewall for Samba

There are several GUI tools in Yast for the firewall. Some are better than others. The following methods are the best in my experience. It's a two step process for openSUSE 11.1 and 11.2 and three steps for openSUSE 11.0.

Step 1: Place the network interfaces in the External Zone

You treat your interfaces as if everything external to an individual workstation is suspect, including your local LAN. Consequently you prevent all contacts except those that you specifically authorise. Hence the interfaces are placed into the External Zone. Go to Yast --> Security and Users --> Firewall --> Interfaces. Check and if necessary change zones for your network interfaces to External Zone.

Step 2: "Allowed Services" for Samba

Open Yast --> Security and Users --> Firewall. Select Allowed Services from the list in the left column. Make sure the panel is set to External Zone in the drop-down list in the top portion.

Now look at the drop-down list under the heading Service to Allow. Select Samba Server. Click the Add button and it will appear in the panel below the heading Service to Allow. Repeat the procedure to insert Netbios Server as a service in the panel. Repeat the procedure once again for openSUSE 11.1 and 11.2 and insert Samba Client in the panel [Note that 'Samba Client' is not available in openSUSE 11.0 and a different procedure is used for 11.0 (see next para)].

Step 3: Samba Client for openSUSE 11.0 alone (not for openSUSE 11.1 or 11.2)

Open Yast --> Security and Users --> Firewall. Select Broadcast from the list in the left column. The Broadcast configurator in the screenshot opens.

You set for Broadcast replies in the lower part titled Accepting the Broadcast Reply. There are three possible configurations, listed below:

Type 1 is where the firewall is closed to Broadcast replies. It must be changed.

Type 2 accept Broadcasts from all networks. See the screenshot to the right. This allows Samba and is acceptable in most cases. It's recommended for normal users. If there's an entry different from the screenshot, highlight it and select the button to delete it. If/when it's empty, click the Add button. 0/0 will appear in a network dialogue. Click Add again and the panel will appear as in the screenshot. Click Next to exit.

↑↑↑↑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, (su to root first):

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)

OpenSUSE comes with a group of default shares that generally are useful for the home LAN but perhaps not for business. They are discussed in the Samba LAN Primer.

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:users, 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 Yast --> Security and Users. Switch to the Groups Tab 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: 26 January 2009; last update 26 May 2010

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