The NetBIOS networking environment began as a joint project of Microsoft and IBM. It originally made use of a non-routable protocol (NetBEUI) that was intended only for small computer networks. NetBIOS itself was subsequently re-implemented over TCP/IP. NetBIOS over TCP/IP still bears the limitations of its original design (i.e., WINS). It's union with TCP/IP would never be described as harmonious. Still, Microsoft has promoted this overworked protocol as the “Common Internet File System,” and it is rare that NetBIOS can be entirely ignored in the networked enterprise, however unfortunate that may be.

Samba is a free implementation of NetBIOS over TCP/IP for UNIX. While there are problems with the design (it forks too many processes), Samba has seen enterprise-class usage and has withstood the associated challenges. The goal of the Samba project is to reproduce the entire network functionality of Windows NT within UNIX (which includes the ability to function as a domain controller).

Samba is an optional component that can be selected during system installation. If it is installed, the Linux system will be a fully operational NetBIOS file server when the system boots for the first time.

If you use Samba, the author would like you to send him a pizza. The Samba website at has information on how this might be accomplished. It can be a challenge; he lives in Australia. (And no, the author of this text has not yet sent his pizza, but will if he should have the misfortune of working in Windows in the future.)

Samba and Password Encryption

Microsoft doesn't like Samba. They have good reason not to like it; recent performance improvements in Samba have made it faster than the default configuration of Windows NT for file and print services on most hardware.

Microsoft dislikes Samba so much that they made password changes to Windows NT Service Pack 3 that prevent it from sharing unencrypted passwords with a Samba server. Samba's default settings are for unencrypted passwords, but these settings can be modified to circumvent this dastardly mischeviousness.

The new encrypted passwords are not compatible with the DES format used in /etc/passwd or /etc/shadow, so Samba must have its own distinct password file when encrypted passwords are enabled.

If connecting with either Windows NT Service Pack 3 or higher, or Windows 98 or higher, encrypted passwords must be implemented before these clients will function.

This is done by removing the comments from the following two lines (they are lines 65 and 66 in /etc/smb.conf):

encrypt passwords = yes
smb passwd file = /etc/smbpasswd

The Samba server must then be restarted by running the following command as root:

/etc/rc.d/init.d/smb restart

When this is done, no users will be allowed to login to the Samba server. Each user must be individually added to the new /etc/smbpasswd file by root. The method for doing so follows:

# smbpasswd -a luser
New SMB password:
Retype new SMB password:

The username luser must exist in the /etc/passwd database when the command is executed. When it is executed, the /etc/smbpasswd will be created with contents similar to the following:

# Samba SMB password file

Once the root user has created the entries in /etc/smbpasswd, individual users can change their Samba password by running the smbpasswd command with no arguments.

This procedure must be executed for each user on the system. On a new system, it should be part of the routine to establish a new user account.

However, on an older system where many accounts already exist, it might not be practical to migrate each individual user in this way. In such a case, there is a (rather awkward) method to migrate such users en masse.

To migrate an existing non-encrypted password file into /etc/smbpasswd, do not set the encryption option in /etc/smb.conf. First execute the following command as root:

cat /etc/passwd | /usr/bin/ > /etc/smbpasswd
chmod 600 /etc/smbpasswd

This operation will create an entry for each user in /etc/smbpasswd. They will have the following form:


These entries have no password, and the users cannot change them.

The following options must then be added to /etc/smb.conf:

update encrypted = yes
smb passwd file = /etc/smbpasswd

The Samba server must then be restarted by running the following command as root:

/etc/rc.d/init.d/smb restart

At this point, users can login to Samba using older, unencrypted clients (such as Windows 95), and the /etc/smbpasswd file will be populated with the encrypted passwords as the users connect.

When the migration is complete, the option:

update encrypted = yes

Contained in /etc/smb.conf can be replaced with:

encrypt passwords = yes

Samba will then switch to the encrypted versions only, and the newer clients can login.

A migration such as the one discussed above will require planning, timing, and forethought, especially for a large enterprise. It should be initiated several months before these newer clients enter a Samba network.

Mapping Users

Windows 95 and 98 differ substantially from Windows NT in their ability to make use of network resources. Windows NT will allow the user to change their login identity for a particular server; Windows 95 and 98 will allow only a single login identity for all network resources.

Because of this, it is sometimes convenient to translate an incoming username to a different UNIX user. To do so, uncomment line 79 in /etc/smb.conf:

  username map = /etc/smbusers

Then, populate /etc/smbusers with the translations:

# Unix_name = SMB_name1 SMB_name2 ...
#root = administrator admin
#nobody = guest pcguest smbguest
luser = FunnyWindowsUser
user2 = WindowsUser2 Otheruser diewindowsdie

The root and nobody users are not commented out of the /etc/smbusers file included in the standard Samba RPM distribution. It is advisable to remove them.

Samba and the Master Browser

In a Windows NT network, a centralized computer is responsible for maintaining a list of NetBIOS servers and their browsable shares. This computer is called the “Master Browser.”

If the Windows NT network has a “Domain Controller,” then the Domain Controller is the master browser for the network.

If there is no Domain Controller, then Windows NT Server computers will hold an “election.” The results of the election will determine which Windows NT system will be the Master Browser. If no Windows NT Server systems are available, Windows NT Workstation computers will converse and allocate one of their number as the master browser.

If it is improperly configured, Samba can repeatedly force these elections upon the network in an attempt to become the Master Browser, causing great contention with the true preferred Master Browser.

To halt this behavior, append the following to /etc/smb.conf:

domain master = no
local master = no
preferred master = no
os level = 0

Samba Server Components

The /etc/smb.conf file contains a number of important parameters and example configurations.

An option that deserves consideration is the workgroup name:

workgroup = MYGROUP

This name should be changed to the desired Domain name or Workgroup name for the network.

It is possible that a client will not be able to see a Samba server because it lies on the far side of a router. If this becomes a problem, an LMHOSTS file could be created on the client to direct queries for a host to a particular IP. The location of this file depends upon the Windows variant being used; it lies in \windows directory on Windows 95. Look for the file LMHOSTS.SAM (which is a sample LMHOSTS file with demonstrations of many of the common configurations); LMHOSTS should be placed in the same directory as the sample file.

To allow the client to see the Samba server, the LMHOSTS entry would have the following form:		remotehost	#PRE

If LMHOSTS files become inconvenient because of a large number of clients, the use of a WINS server (either on Samba or NT) should be investigated, especially in conjunction with DHCP. Samba has a number of options for WINS services; start with smb.conf for details.

It is also possible that a client cannot connect to the Samba server because the wrong protocols have been loaded. Samba requires TCP/IP support on the client, which is not loaded by default on some versions of Windows (Windows 95 specifically). To enable Windows 95 or 98 to use Samba resources, they must have “Client for Microsoft Networks” and “TCP/IP” loaded in the Network section of the Control Panel. Consult a Windows networking text for more details.

File Services

By default, as soon as the Samba server is activated, users can mount their home directories as drive letters on their Windows systems by using a share of the form:


Where remotehost is the remote Red Hat Samba server, and luser is any user on that host.

Should this behavior not be desired, remove the following section from /etc/smb.conf:

   comment = Home Directories
   browseable = no
   writable = yes

To create a public browsable area, add an entry of the following form:

# A publicly accessible directory, but read only, except for people in
# the "staff" group
;   comment = Public Stuff
;   path = /home/samba
;   public = yes
;   writable = yes
;   printable = no
;   write list = @staff

In order to create a set of users able to write to such a directory, an entry for staff must be created and populated with the selected users in /etc/group. Note also that the directory permissions must also be set to writable for the staff group, as UNIX permissions will still apply.

The following example demonstrates the “valid users” directive:

# The following two entries demonstrate how to share a directory so that two
# users can place files there that will be owned by the specific users. In this
# setup, the directory should be writable by both users and should have the
# sticky bit set on it to prevent abuse. Obviously this could be extended to
# as many users as required.
;   comment = Mary's and Fred's stuff
;   path = /usr/somewhere/shared
;   valid users = mary fred
;   public = no
;   writable = yes
;   printable = no
;   create mask = 0765

Demonstrated below is the procedure for mapping these server resources on Windows clients. First, in Windows 98, “right click” on the My Computer Icon. From this menu, select Map Network Drive.

Select an empty virtual drive and enter the share to be mapped.

Provide the server password to complete the connection.

The procedure in Windows NT is slightly different.

Windows NT allows the user to “Connect As” (a feature sorely lacking in the Windows 95/98 releases).

Provide the server password to complete the connection.

Print Services

By default, all system printers are shared through Samba. This behavior is controlled by the following lines in /etc/smb.conf:

# if you want to automatically load your printer list rather
# than setting them up individually then you'll need this
   printcap name = /etc/printcap
   load printers = yes

Remove this section if this is not the desired behavior.

If it is removed, the following example from /etc/smb.conf can be used to share an individual printer:

# A private printer, usable only by fred. Spool data will be placed in fred's
# home directory. Note that fred must have write access to the spool directory,
# wherever it is.
;   comment = Fred's Printer
;   valid users = fred
;   path = /homes/fred
;   printer = freds_printer
;   public = no
;   writable = no
;   printable = yes

It is also possible to specify the print command that should be used:

comment = Laser Printer
path = /var/spool/samba
printer driver = "Generic Laser"
print command = lpr -P lp1 %s
public = no
writable = no
printable = yes

NetBIOS Client Services for Linux

Linux can participate as a client in Windows NT networks. It can access both file and printer shares.

File Services

If a remote server is running TCP/IP and has available shares, they can be accessed via the smbmount command (please note that the standard mount command is not used for this purpose).

The following command, when run by root, mounts a share called data on the remote host nthost on the local /mnt directory:

smbmount //nthost/data -c 'mount /mnt'

This command will first prompt for a password, then mount the share off /mnt.

This command assumes that there is a “root” user defined on the remote system, and that nthost is visible on the local network.

A different remote user name for accessing the remote host can be specified with the -U option:

smbmount //nthost/data -U luser -c 'mount /mnt'

Should the remote host not be easily visible on the local network, the -I option can be used to specify a host name or IP address:

smbmount //nthost/data -I -c 'mount /mnt'

The file permissions model on NT servers is usually much different from UNIX. If the NT server is using a FAT file system, there is no permissions on files. If the server is using NTFS, its security model is actually more flexible than UNIX, but it is not compatible. Options can be specified that control the user, group, file mode and directory mode that Linux will assign the mounted file system:

smbmount //nthost/data -U luser -I \
	-c 'mount /mnt -u 500 -g 500 -f 644 -d 755'

Print Services

Adding a Windows printer as a Linux system printer is relatively straightforward. As the root user under X-Windows, run the following command:


The Print System Manager will appear, as shown in Figure 8-1:

Select the “add” button, and the dialog in Figure 8-2 will be presented:

Select “Lan Manager Printer” and click “OK”:

Click “OK” on the warning dialog to continue:

Add the relevant information to the dialogs and click “OK”:

Any user should now be able to send output to the Windows printer with a command such as:

lpr -Plp0 /etc/passwd

If the NT printer has been installed as the default printer lp, the -P option above is unnecessary.

It is also possible to use a simple shell script to print to remote Windows printers. Record the following shell script in the file winprint:

	echo "print -"
	cat $*
) | /usr/bin/smbclient "\\\\$SERVER\\$SERVICE" $PASSWORD -U $SERVER -N

An example of using the winprint script could be:

winprint /etc/passwd /etc/group /etc/hosts

There is one extremely important point to make about these SMB printers. The username and passwords that are entered in the Print System Manager dialogs are saved and then sourced directly into a shell script. Because of this, a password of `"";rm -rf /' could be potentially disastrous. To be safe, limit the sharenames, usernames and passwords to alphanumeric characters ([A-Za-z0-9]).