Troubleshooters.Com and T.C Linux Library Present

Samba

Copyright (C) 1998, 1999, 2000, 2004 by Steve Litt, All rights reserved. Material provided as-is, use at your own risk.

Steve Litt is the author of the Universal Troubleshooting Process Courseware,
which can be presented either by Steve or by your own trainers.

He is also the author of Troubleshooting Techniques of the Successful Technologist,
Rapid Learning: Secret Weapon of the Successful Technologist, and Samba Unleashed.

Note: If your windows machine obtains its IP automatically through WINS using DHCP for WINS resolution, you must make your Linux machine a DHCP server.
Note: There is a document for renumbering and configuring the server.
Note: This document contains instructions on setting up Samba print shares with cups printing.
Note: Here are instructions on installing and configuring Samba from source on Red Hat type servers.

Hello World

The Hello World exercise allows you to see your Linux computer in Windows 95/98 Windows explorer, and nothing more. It involves merely creating a 3 line configuration file for Samba which maps Samba to your Windows machine's workgroup.
  1. Back up existing /etc/smb.conf.
  2. Create this ultra-simple /etc/smb.conf, which does nothing but allow Windows to see it:
  3. Restart Samba on the Linux box with this command:
  4. In Windows Explorer, doubleclick on Network Neighborhood, then on Entire Network, then on your workgroup, and see if you see your Linux computer. If not, Startbutton:find: and then type in the name of your Linux computer (linuxhost in this example), and if it finds it, double-click on it. It should now be visible in Explorer.
  5. Note that doubleclicking the linuxhost icon produces a blank screen on the right, in which you cannot create, copy or modify files. That's because you have not yet defined directories.
  6. When you can see the linuxhost icon in Windows Explorer, you know Samba is running correctly on your Linux machine, and you've completed the Hello World.
    7. [global]
       guest account = pcguest
       workgroup = MYWGRP

    [homes]
       comment = Home Directories
       browseable = no
       read only = no
       create mode = 0750
     

    		 Global Section
    Define guest account
    Define MS Win workgroup. Replace MYWGRP with the windows workgroup defined in Windows ControlPanel:Network:Identification_Tab:Workgroup_field. Note that for best results, the workgroup field should be 8 or less characters, and upper case.

Incriment: Create and Access a Free-to-All Directory

The purpose of this incriment is to create a directory which anyone can read or write, without supplying a password. This is important,because in order to use passwords with Samba and Win98 or Win95 SR2, other modifications need to be made. It consists primarily of creating the directory, with the proper permissions, on the Linux box, then adding a few lines to /etc/smb.conf.
  1. As root, create directory /scratch off the root.
  2. chmod 777 /scratch        #all rights to everyone
  3. Add the [scratchdisk] section to /etc/smb.conf as shown below:
  4. Restart Samba on the Linux box with this command:
  5. In Windows Explorer, doubleclick on Network Neighborhood, then on Entire Network, then on your workgroup, and see if you see your Linux computer. If not, Startbutton:find: and then type in the name of your Linux computer (linuxhost in this example), and if it finds it, double-click on it. It should now be visible in Explorer.
  6. Doubleclick the Linux computer to see the scratchdisk directory. If you can't see it, you may need to refresh Explorer with the F4 key.
  7. Navigate to the scratchdisk directory.
  8. Create directory mydir inside the scratchdisk directory, and navigate into mydir. If you get error messages, make sure directory /scratch exists on the Linux box, and that it has all permissions for all parties (drwxrwxrwx).
  9. In directory mydir, create text file mytext.txt, type in a couple lines with notepad, save it, exit notepad, and pull it up again, exit notepad again.
  10. On your linux box, do this command:
  11. You'll see the text you typed in. However, you might notice aberrations in the linefeeding, due to the different newline definitions in Windows and Linux.
  12. On your Linux box, do this command:
  13. You'll notice the file permissions to be -rwxr--r--, and the owner to be your guest account, pcguest. Since all persons accessing this directory will access it as user pcguest, this means anyone accessing the file through Samba will be able to modify the file. Note also that as of now, we've implemented no sharing, which means two users can't reliably modify the file at the same time.
With the completion of this increment, you've used your Samba-enabled Linux machine as a file server accessible from your Windows computer, although you've implemented no security.

Increment: Map a Network Drive to Scratchdisk

This short increment maps a drive to the scratchdisk directory, and allows you to copy files back and forth in a DOS box.
  1. In Windows Explorer, navigate through Network Neighborhood to the scratchdisk directory.
  2. Right-click the scratchdisk directory, choose Map network drive off the popup menu, and choose drive V. If V isn't available, pick another, and work the exercises with that drive instead. Make sure the Reconnect at login checkbox is checked. Click OK.
  3. Note that drive V now appears on your Windows Explorer tree, as if it's a local drive.
  4. Get to a DOS prompt.
  5. Type V: then press Enter, and note the prompt.
  6. Type dir to get a directory, and note that you see directory mydir, which you created earlier.
  7. Navigate to the mydir directory using command cd \mydir
  8. Type C: then press Enter, to get to the C drive.
  9. Create c:\junk on your Windows computer, then navigate to that directory.
  10. Do this command in DOS:
  11. Edit c:\junk\mytext.txt, add one more line of text, then save it.
  12. copy c:\junk\mytext.txt v:\mydir\mytext.txt
  13. type v:\mydir\mytext.txt
  14. Note that when you typed the text on V, the line you added showed up.
  15. Reboot your Windows computer, and note that your V: drive still appears in Windows explorer, and still contain \mydir\mytext.txt. Note that you really have created a fileserver.
With the completion of this increment, you've mapped a drive to your Samba system, stored and modified a file on that system, and had it persist through a reboot. It's absolutely a fileserver.

Increment: Access Your Home Directory on the Linux Box

This increment is the first to implement user level security. It simply allows the Windows user to access the home directory of the Linux user of that same name. Note, however, that because of changes to Windows in Service Release and later, this increment will succeed only with users of earlier Windows 95. The increment after this will address the Windows client problems.
  1. Make sure you have user myuid on the Linux box.
  2. Insert the [homes] section with its comment into /etc/smb.conf.
  3. Restart Samba on the Linux box with this command:
  4. In Windows, log out and log in as user myuid.
  5. In Windows Explorer, navigate network neighborhood down to the linuxhost computer and doubleclick it. You should now see your myuid directory.
  6. Doubleclick the myuid directory. You'll be asked for a password. Type in the password for myuid onthe Linux box. If you have early Windows 95, you'll see the contents of your home directory on the Linux box. If you have windows 95 Service Release 2 or later, or Win98, it will tell you the password was wrong.
  7. If you managed to see the myuid directory, you successfully finished this increment, whether or not you were able to navigate your home directory.
With the completion of this increment, you've implemented security. You'll see your home directory, but nobody elses home directory. You may not be able to navigate your home directory, but that isn't an error on your part, it's a change Microsoft implemented in Service Release 2 of Win95. The next increment will fix that problem. However, if you can already navigate your home directory, please skip the next increment.

Increment: Implement Samba Password Encryption

This increment changes Samba from "plain text" passwords to "encrypted" passwords. Before Service Release 2, Windows defaulted to plain text passwords. In SR2 and beyond, it defaulted to encrypted, thus clashing with Samba's default. We can fix the problem by re-defaulting Windows to plain text, or we can set up Samba to use encrypted. The latter is better, since only one machine needs modification. However, in certain cases changing Samba to accept encrypted passwords requires re-compilation of the Kernal. Since that action is clearly beyond the scope of this tutorial, if this increment doesn't work we'll walk you through a Windows registry change to re-enable plain text passwords.
 
  1. Add    encrypt passwords = yes and password level = 20 to the [global] section of /etc/smb.conf as shown below, and save.
  2. Type the following commands to make sure both myuid and MYUID users are in the system:
  3. For each id in the step above, do a passwd command to give it a password.
  4. Type the following command to put the password for user myuid into the smb password file:
  5. Restart Samba on the Linux box with this command:
  6. On your Windows machine, log out and log back in as user myuid, giving the same password as on the Linux machine. If your Windows machine already has a different password for myuid than the Linux machine, you'll be asked for a password when you try to access the myuid directory in Windows Explorer.
  7. When you can view create and change files on your myuid directory (please change only those you created from Windows, you've successfully completed this increment.

Troubleshooting

Make sure the smb password file is really being created. It's called smbpasswd, and in Red Hat 5.1 it's in the /etc directory. If there are problems, review the information in these pages (or their equivalents on your system) If there's still a problem, it's possible that your Linux must be recompiled to accept encrypted passwords, clearly beyond the scope of this tutorial. In that case, you may wish to fix it on the client end.

With the completion of this increment, you've implemented security on a user level, and allowed each user to access his or her Linux home directory from his or her Windows machine, based on the Windows login. Note especially, that the substantial obstacle of password compatibility has been addressed, making the rest of this tutorial much easier.

Increment: A Read-Write directory for certain users to share

This allows users myuid and clinton (you might need to create clinton) to share directory sharedir, identified to Windows as myshare.
  1. As root, create directory /sharedir
  2. As root, create user clinton if not created
  3. Add the myshare section, as shown in bold below.
  4. Restart Samba on the Linux box with this command:
  5. /etc/rc.d/init.d/smb restart
  6. In Windows Explorer, doubleclick on Network Neighborhood, then on Entire Network, then on your workgroup, and see if you see your Linux computer. If not, Startbutton:find: and then type in the name of your Linux computer (linuxhost in this example), and if it finds it, double-click on it. It should now be visible in Explorer.
  7. Doubleclick the Linux computer to see the scratchdisk directory. If you can't see it, you may need to refresh Explorer with the F4 key.
  8. Navigate to the scratchdisk directory.

Incriment: Access a Home Directory

The purpose of this incriment is to allow you to access a

[To be continued later]
 
 
Samba 2.0.6 an later ignore logon path= when placing Win9x profiles, placing them instead in the home directory for Win9x clients. This differs from 2.0.5a and before, where Win98 clients respected the logon path= parameter.

The change was made so that the net use /home command would work correctly (it was broken before 2.0.6). But the side effect was the breaking of logon path in Win9x. The problem is a basic incompatibility between NT and Win9x -- it's not a Samba bug.

I originally proposed a source code "reversion", in which both instances of:

pstrcpy(p2,lp_logon_home());
are changed to: 
pstrcpy(p2,lp_logon_path());
Unfortunately, this also reverts the inability to use net use /home. A new method has been developed which uses dualling Windows bugs to obtain consistently correct results on both NT and Win9x. The solution is to set logon home and logon path as follows, and everything will work right: 
logon home = \\%L\%U\profiles   
logon path = \\%L\profiles\%U

Configuring Samba Printers with cups (Mandrake)

Just set these two parameters:
printing = cups
printcap name = cups
On modern versions (definitely 3.0.1 and beyond, and probably 2.2.x), this is all you need to interface with CUPS. But on some of the earlier Samba versions that came with earlier Linux versions, Samba printer defaults didn't work with cups. So here's how to configure your printer with those older versions. Add the following to [printers] or any other printer share: 
# Following print command uses client side printer drivers.
print command = lpr-cups -P %p -o raw %s 

# Following print command using cups own drivers
# (use generic PostScript on clients).
; print command = lpr-cups -P %p %s 
lpq command = lpstat -o %p
lprm command = cancel %p-%j

Pushing Files to Windows from Linux

This section explains how a Linux box can push its files to a directory in a Windows box, and how to hook that push to a cron job. This section assumes that user farn exists on the windows box, and that it exports a share called foam. The Linux box doing the pushing is at 192.168.100.3. Because not everyone has Windows boxes at their disposal, I've simulated the Windows box with a Linux box at 192.168.100.2.

Create user farn

On both the server (192.168.100.3 in this example) and the client (either a windows box or a simulated windows box at 192.168.100.2), create user farn. On Linux boxen, be sure not only to create the user, but to add it to /etc/smbpasswd with the smbpasswd -a command.

Create the Share

If you're simulating a Windows box with a Linux box (say at 192.168.100.2), add the following share to smb.conf:

[foam]
valid users = farn
path = /home/farn/foam
available=yes
writeable = yes
browseable = no
printable = no

Create the Credentials File

The server will need a password for user farn on the client in order to perform the push. This presents a problem. It's an automated system, so you don't want to require user intervention in the form of typing in a password.

But for securities sake, do you want the password in a script, or worse yet, in /etc/fstab? Probably not. That's why both the smbclient and smbmount commands provide the option of using a credentials file, which is simply a file containing the user, password and workgroup. This file can be readable by the owner only, with no other permissions, and if smbpasswd is run by that owner, it can access the credentials file. Thesmbclient program uses the -A <credentialsFile> option followed by the name of the credentials file. The mount -t smbfscommand uses the -o credentials=<credentialsFile> option.

Here is the credentials file, /home/farn/creds, located on 192.168.100.3:

username = farn
password = secret
domain = mygroup

In the preceding, you'd obviously replace the word secret with the actual password for that user on the client, which should be the same as the password for that user on the server.

Create the Push File

The following, at /home/farn/litt.sh on 192.168.100.3 (the server), is the file that takes all files complying with filespec litt*.txt and pushes them to the client, tests against corruption, and then deletes the file:

#!/bin/bash

smbclient //192.168.100.2/foam -A /home/farn/creds -c "prompt;mput litt*.txt"
cd comps
smbclient //192.168.100.2/foam -A /home/farn/creds -c "prompt;mget litt*.txt"
cd ..

for i in litt*.txt ; do
        diff $i comps/$i
        mismatch=$?
        if test $mismatch -eq 0 ; then
                rm -f $i
                rm -f comps/$i
        else
                echo BAD FILE TRANSFER, ERROR $mismatch, file $i | mail -s PUSH_SYSTEM_FAILURE farn@localhost

        fi
done

Look what the preceding script does. It first uses smbclient to copylitt*.txt to the client. But did the copy really succeed? To find out, we use smbclient to copy back to a directory called comps below the current directory, and for each file matching litt*.txt, we compare. If they compare correctly, we delete the file both in the current directory and in comps below it. Otherwise, we send an email describing the failure.

The preceding works very well if the process on the client deletes the files after processing. But if the files remain, then each time the script runs, more and more files are copied to the comps directory. Although everything still works, this makes for a lot of processing and network traffic. Under such circumstances you might want a better script.

Making it a Cron Job

The activities described so far in this article give you a script calledlitt.sh that, when run as user farn from its home directory on the server, will push all files matching litt*.txt to the client machine, and delete them from the server. Now we want to make this a cron job so that it runs periodically.

Start by enabling user farn to add its own cron jobs to run under its own username. Insert the following line in /etc/cron.allow:
farn
Next, while logged in as user farn on the server, add a cron job. Run this command:
crontab -e
The preceding enables you to edit cron jobs for user farn. Add the following line:
* * * * * /home/farn/litt.sh
The preceding runs litt.sh every minute. Starting from the left, the five stars stand for:
  1. All minutes (0-59)
  2. All hours (0-23)
  3. All days of month (1-31)
  4. All months (1-12)
  5. All days of week (0-7, with 0 being Sunday, and 7 being an alternate for Sunday)
Every minute is great for testing, but here are some more realistic methods:

Cron command
 When it runs
 
0 * * * * /home/farn/litt.sh
 Every hour, on the hour
 
15 11 * * * /home/farn/litt.sh
 Every day at 11:15 am
 
59 23 * * 1 /home/farn/litt.sh
 Every Monday at 23:59
 
15 8,16 * * 1-5 /home/farn/litt.sh
 At 8:15am and 4:15pm every weekday
 
* 8-19/3 1-5 * * /home/farn/litt.sh
 Run every 3 hours, on the hour, between
8am and 7pm, during the first 5 days
of the month.





Backing Up Windows Clients

The Samba crew says you can use smbtar to do this. If you're able to get smbtar to work correctly, you're a better technologist than I. Here's how I back up an entire Windows share, called myshare, on a computer called wincli:
smbclient //wincli/myshare -Uslitt%secret -Tc - | gzip > wincli_myshare.tgz
In the preceding, you obviously substitute the share's password or a user's password for secret. Sometimes you might want to back up a single tree. That's easy too. The following backs up C:\My Documents\My Pictures, assuming the C drive is shared as //wincli/C. St
smbclient //wincli/C -Uslitt%secret -Tc - "My Documents/My Pictures" | gzip > wincli_c_mydocuments_mypictures.tgz
In the preceding, the name of the .tgz file is descriptive, but it could be anything. It could be tuba.tgz or earthquake.tgz.

Installing Samba 3.0.1

Samba 3.0.1 is the latest and greatest as of 1/16/2004. Fortunately, it's easy to install, and if you do a default install, it doesn't conflict with the Samba that came with your distro, although as soon as you're sure that Samba 3.0.1 is solid, you'll want to delete your distro provided older Samba.

By default, Samba 3.0.1 goes in the /usr/local/samba tree. Binaries, config files, documentation, and manpages are all in that tree. That's excellent because you can deinstall by simply removing the tree, although I prefer to create an rpm with the checkinstall program.

Correcting the Directories

I love the fact that by default Samba installs everything into the /usr/local/samba tree. But there are disadvantages. Nothing in that tree is in the path. Nothing in that tree is on the manpath. And if you're not careful, commands liketestparm and smbpasswd can access the wrong data files. You must correct everything.

First, place /usr/local/samba/bin in front of the executable path. That way a call to smbmount, for instance, will access the one in /usr/local/samba/bin, instead of the old one in /usr/bin. Instructions for changing the path are contained here.

Next, you need to see Samba's man pages, which are located in /usr/local/samba/doc/man. Edit your /etc/man.config file, and place the following line:
MANPATH /usr/local/samba/man
before all the other MANPATH entries. That pulls in the new Samba man pages before the old ones. If you must see the old onces, use the -M option for the man command.

Use Testparm Early and Often

Which smb.conf is your Samba really using? What shares do you really have? These are questions best answered by the testparm utility. It's best to call this utility with an explicit path so you know for sure which testparm you're using, in the event that you have two installed Samba versions.

Which smbpasswd?

When you use the smbpasswd utility, which copy of the smbpasswd password repository are you accessing? Unless you regularly use both Samba versions, it might be best to rename the old smbpasswd password repository file (typically /etc/samba/smbpasswd on Redhat derived distros).

Enabling SWAT

If your experience is anything like mine, SWAT won't work for a few reasons:
Edit the /etc/services file, and make sure there's a line like this:
swat    901/tcp      # Samba Web Administration Tool
Now you have the service, but you need xinetd to run it. Create the following /etc/xinetd.d/swat:

# default: off
{
        disable = no
        socket_type     = stream
        protocol        = tcp
        wait    = no
        user    = root
        server  = /usr/local/samba/sbin/swat
}

Restart service xinetd, and surf to http://localhost:901. You'll be greeted by a login screen. However, you won't be able to log in, even with the right root password. First perform the following:
smbpasswd -a root
It probably still won't work. Remember I compiled it with --with-pam? If you crank up the log level (place server_args = -d 2 in /etc/xinetd.d/swat), you'll see that it's a PAM error. The problem is lack of a /etc/pam.d/samba file. Go into /home/slitt/samba-3.0.1/packaging, and then into the directory corresponding to your distro, and copy the samba.pamdfile to /etc/pam.d/samba. Try it again, and it should work. If you cannot find a file remotely resembling samba.pamd for your distro, you can try one for a similar distro. Beyond that, troubleshoot.

Making a Real Startup File

This article earlier described a startup file called smbrestart, which does the job quite well. However, if you want a real startup file, consider getting the one in the packaging tree. For instance, let's say you're using Mandrake. As the root user, perform the following:
cp -p /home/slitt/samba-3.0.1/packaging/Mandrake/smb.init /etc/rc.d/init.d/smb
If you're using Redhat or Fedora, do the same with their entries in the packaging tree.

The new startup script will probably fail because, even though you've placed /usr/local/samba/bin in everyone's path, /usr/local/samba/bin is not on the path and therefore commands fail. The solution is to place the following two lines right after the code that includes /etc/init.d/functions:
PATH=/usr/local/samba/sbin:$PATH
export PATH
The preceding enables executables in /usr/local/samba/sbin to run, thereby enabling the startup script to run. If for some reason  /usr/local/samba/bin isn't on the path, you'd need to do the same for it in the /etc/rc.d/init.d/smb file.



























Back to Troubleshooters.Com * Back to Linux Library