How to Install and Test SAMBA

Step 0: Read the man pages

The man pages distributed with SAMBA contain lots of useful info that will help to get you started. If you don't know how to read man pages then try something like:

$ nroff -man smbd.8 | more

Other sources of information are pointed to by the Samba web site, http://www.samba.org

Step 1: Building the Binaries

To do this, first run the program ./configure in the source directory. This should automatically configure Samba for your operating system. If you have unusual needs then you may wish to run

root# ./configure --help

first to see what special options you can enable. Then executing

root# make

will create the binaries. Once it's successfully compiled you can use

root# make install

to install the binaries and manual pages. You can separately install the binaries and/or man pages using

root# make installbin

and

root# make installman

Note that if you are upgrading for a previous version of Samba you might like to know that the old versions of the binaries will be renamed with a ".old" extension. You can go back to the previous version with

root# make revert

if you find this version a disaster!

Step 2: The all important step

At this stage you must fetch yourself a coffee or other drink you find stimulating. Getting the rest of the install right can sometimes be tricky, so you will probably need it.

If you have installed samba before then you can skip this step.

Step 3: Create the smb configuration file.

There are sample configuration files in the examples subdirectory in the distribution. I suggest you read them carefully so you can see how the options go together in practice. See the man page for all the options.

The simplest useful configuration file would be something like this:

	[global]
	   workgroup = MYGROUP

	   [homes]
	      guest ok = no
	      read only = no

which would allow connections by anyone with an account on the server, using either their login name or "homes" as the service name. (Note that I also set the workgroup that Samba is part of. See BROWSING.txt for details)

Note that make install will not install a smb.conf file. You need to create it yourself.

Make sure you put the smb.conf file in the same place you specified in theMakefile (the default is to look for it in /usr/local/samba/lib/).

For more information about security settings for the [homes] share please refer to the document UNIX_SECURITY.txt.

Step 4: Test your config file with testparm

It's important that you test the validity of your smb.conf file using the testparm program. If testparm runs OK then it will list the loaded services. If not it will give an error message.

Make sure it runs OK and that the services look reasonable before proceeding.

Step 5: Starting the smbd and nmbd

You must choose to start smbd and nmbd either as daemons or from inetd. Don't try to do both! Either you can put them in inetd.conf and have them started on demand by inetd, or you can start them as daemons either from the command line or in /etc/rc.local. See the man pages for details on the command line options. Take particular care to read the bit about what user you need to be in order to start Samba. In many cases you must be root.

The main advantage of starting smbd and nmbd using the recommended daemon method is that they will respond slightly more quickly to an initial connection request.

Step 5a: Starting from inetd.conf

NOTE; The following will be different if you use NIS or NIS+ to distributed services maps.

Look at your /etc/services. What is defined at port 139/tcp. If nothing is defined then add a line like this:

netbios-ssn 139/tcp

similarly for 137/udp you should have an entry like:

netbios-ns 137/udp

Next edit your /etc/inetd.conf and add two lines something like this:

		netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd 
		netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd

The exact syntax of /etc/inetd.conf varies between unixes. Look at the other entries in inetd.conf for a guide.

NOTE: Some unixes already have entries like netbios_ns (note the underscore) in /etc/services. You must either edit /etc/services or /etc/inetd.conf to make them consistent.

NOTE: On many systems you may need to use the "interfaces" option in smb.conf to specify the IP address and netmask of your interfaces. Run ifconfig as root if you don't know what the broadcast is for your net. nmbd tries to determine it at run time, but fails on some unixes. See the section on "testing nmbd" for a method of finding if you need to do this.

!!!WARNING!!! Many unixes only accept around 5 parameters on the command line in inetd.conf. This means you shouldn't use spaces between the options and arguments, or you should use a script, and start the script from inetd.

Restart inetd, perhaps just send it a HUP. If you have installed an earlier version of nmbd then you may need to kill nmbd as well.

Step 5b. Alternative: starting it as a daemon

To start the server as a daemon you should create a script something like this one, perhaps calling it startsmb.

		#!/bin/sh
		/usr/local/samba/bin/smbd -D 
		/usr/local/samba/bin/nmbd -D

then make it executable with chmod +x startsmb

You can then run startsmb by hand or execute it from /etc/rc.local

To kill it send a kill signal to the processes nmbd and smbd.

NOTE: If you use the SVR4 style init system then you may like to look at the examples/svr4-startup script to make Samba fit into that system.

Step 6: Try listing the shares available on your server

$ smbclient -L yourhostname

You should get back a list of shares available on your server. If you don't then something is incorrectly setup. Note that this method can also be used to see what shares are available on other LanManager clients (such as WfWg).

If you choose user level security then you may find that Samba requests a password before it will list the shares. See the smbclient man page for details. (you can force it to list the shares without a password by adding the option -U% to the command line. This will not work with non-Samba servers)

Step 7: Try connecting with the unix client

$ smbclient //yourhostname/aservice

Typically the yourhostname would be the name of the host where you installed smbd. The aservice is any service you have defined in the smb.conf file. Try your user name if you just have a [homes] section in smb.conf.

For example if your unix host is bambi and your login name is fred you would type:

$ smbclient //bambi/fred

Step 8: Try connecting from a DOS, WfWg, Win9x, WinNT, Win2k, OS/2, etc... client

Try mounting disks. eg:

C:\WINDOWS\> net use d: \\servername\service

Try printing. eg:

C:\WINDOWS\> net use lpt1: \\servername\spoolservice

C:\WINDOWS\> print filename

Celebrate, or send me a bug report!

What If Things Don't Work?

If nothing works and you start to think "who wrote this pile of trash" then I suggest you do step 2 again (and again) till you calm down.

Then you might read the file DIAGNOSIS.txt and the FAQ. If you are still stuck then try the mailing list or newsgroup (look in the README for details). Samba has been successfully installed at thousands of sites worldwide, so maybe someone else has hit your problem and has overcome it. You could also use the WWW site to scan back issues of the samba-digest.

When you fix the problem PLEASE send me some updates to the documentation (or source code) so that the next person will find it easier.

Diagnosing Problems

If you have installation problems then go to DIAGNOSIS.txt to try to find the problem.

Scope IDs

By default Samba uses a blank scope ID. This means all your windows boxes must also have a blank scope ID. If you really want to use a non-blank scope ID then you will need to use the 'netbios scope' smb.conf option. All your PCs will need to have the same setting for this to work. I do not recommend scope IDs.

Choosing the Protocol Level

The SMB protocol has many dialects. Currently Samba supports 5, called CORE, COREPLUS, LANMAN1, LANMAN2 and NT1.

You can choose what maximum protocol to support in the smb.conf file. The default is NT1 and that is the best for the vast majority of sites.

In older versions of Samba you may have found it necessary to use COREPLUS. The limitations that led to this have mostly been fixed. It is now less likely that you will want to use less than LANMAN1. The only remaining advantage of COREPLUS is that for some obscure reason WfWg preserves the case of passwords in this protocol, whereas under LANMAN1, LANMAN2 or NT1 it uppercases all passwords before sending them, forcing you to use the "password level=" option in some cases.

The main advantage of LANMAN2 and NT1 is support for long filenames with some clients (eg: smbclient, Windows NT or Win95).

See the smb.conf(5) manual page for more details.

Note: To support print queue reporting you may find that you have to use TCP/IP as the default protocol under WfWg. For some reason if you leave Netbeui as the default it may break the print queue reporting on some systems. It is presumably a WfWg bug.

Printing from UNIX to a Client PC

To use a printer that is available via a smb-based server from a unix host you will need to compile the smbclient program. You then need to install the script "smbprint". Read the instruction in smbprint for more details.

There is also a SYSV style script that does much the same thing called smbprint.sysv. It contains instructions.

Locking

One area which sometimes causes trouble is locking.

There are two types of locking which need to be performed by a SMB server. The first is "record locking" which allows a client to lock a range of bytes in a open file. The second is the "deny modes" that are specified when a file is open.

Record locking semantics under Unix is very different from record locking under Windows. Versions of Samba before 2.2 have tried to use the native fcntl() unix system call to implement proper record locking between different Samba clients. This can not be fully correct due to several reasons. The simplest is the fact that a Windows client is allowed to lock a byte range up to 2^32 or 2^64, depending on the client OS. The unix locking only supports byte ranges up to 2^31. So it is not possible to correctly satisfy a lock request above 2^31. There are many more differences, too many to be listed here.

Samba 2.2 and above implements record locking completely independent of the underlying unix system. If a byte range lock that the client requests happens to fall into the range 0-2^31, Samba hands this request down to the Unix system. All other locks can not be seen by unix anyway.

Strictly a SMB server should check for locks before every read and write call on a file. Unfortunately with the way fcntl() works this can be slow and may overstress the rpc.lockd. It is also almost always unnecessary as clients are supposed to independently make locking calls before reads and writes anyway if locking is important to them. By default Samba only makes locking calls when explicitly asked to by a client, but if you set "strict locking = yes" then it will make lock checking calls on every read and write.

You can also disable by range locking completely using "locking = no". This is useful for those shares that don't support locking or don't need it (such as cdroms). In this case Samba fakes the return codes of locking calls to tell clients that everything is OK.

The second class of locking is the "deny modes". These are set by an application when it opens a file to determine what types of access should be allowed simultaneously with its open. A client may ask for DENY_NONE, DENY_READ, DENY_WRITE or DENY_ALL. There are also special compatibility modes called DENY_FCB and DENY_DOS.

Mapping Usernames

If you have different usernames on the PCs and the unix server then take a look at the "username map" option. See the smb.conf man page for details.