Troubleshooters.Com Presents

Troubleshooting Professional Magazine

Volume 3, Issue 10, September 1999
Samba
Copyright (C) 1999 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Troubleshooting Professional Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

[ Troubleshooters.Com | Back Issues ]


CONTENTS

Editors Desk

By Steve Litt
My family settled in a new house when I was 7. My parents liked the neighborhood, the school system, and the house. I liked the wishing well.

Of course it wasn't a real wishing well. It was just a three foot space between the garage and the fence. Densely overgrown with weeds, it inspired fear and curiosity. I went in, and kept going in. Because every time I went in, I came out holding something cool. Marbles, a ball, whatever I wanted. Once I wished for a scooter, and sure enough it was 10 feet back in a heretofore unexplored section of the wishing well.

Of course any adult knows what happened. The last several owners had children, each of which left things behind. I was a teenager when we moved out of that house. Surely the child of the new owner found the cool toys I abandoned in that overgrown space.

Only a kid could think of it as a wishing well. It was a magical source of found dreams. It's the magic of childhood, all too brief -- never recaptured.

Until I found Linux.

I always wanted a web server. One came ready configured on my server. I wanted email. Sendmail's right there. And with a little configuration, there's DNS (named) to give name service to those things. I could build a network reminiscent of a tiny Internet right in my office. Diving into the the weeds of the CD and the Internet, I found dbi::dbd and postgreSQL to make a web app. The only thing left was to build a file server reminiscent of the Novell. Every fiber of my adult being told me that's not to be found in an overgrown corner of the yard.

But I covered my face and went on in. I came out of my Red Hat wishing well clutching a Samba file server. Files and printers accessible right there on Windows Explorer. No need to spend $5000 for NT Server 20 seat or Netware.

Everyone knows you can build a killer website or intranet with Open Source software. We all know Linux excels at any kind of TCP/IP networking. Many know you Linux provides reasonable desktop computers. But until a year or so ago, most felt getting Linux to replace NT or Novell as a file server was a wistful pipe dream. Then they heard about Samba, the GNU GPL'ed file server software running on Linux, BSD, and many other Unix flavors. Now everyone's talking about Samba. It's the Trojan horse that just might get Linux past the gatekeepers of the glass house.

This issue of Troubleshooting Professional Magazine introduces Samba, and references other sources of information. So kick back, relax, and enjoy this issue of Troubleshooting Professional. Explore your thoughts on change -- where you've been and where you're going, and the opportunities found along the way. And remember, if you're a Troubleshooter, Technologist, or free software user, this is your magazine. Enjoy!

Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist. He can be reached at Steve Litt's email address.

Samba in 10 Minutes

By Steve Litt
Let's assume you have a network in place and your Windows and Linux box can ping each other. If you've never set up Samba, create this proof of concept smb.conf after backing up your existing /etc/smb.conf:
 
encrypt passwords=yes
workgroup=workgroupname
netbios name=servername

[homes]

Italicized workgroupname should be replaced with the workgroup name from your Windows box's networking properties:Identification tab:Workgroup field. Use the same case as on that field. Italicized servername should be replaced with your Linux box's name, as revealed by the hostname command, less any domain name suffixes. Use the same case as revealed by hostname. For instance, if hostname displayed myserver.mydomain.cxm, you would simply replace servername with myserver.

Next set yourself up as a user on the Samba server. Let's say you use username myuid on the Windows box. Here's what you do:

/usr/sbin/useradd myuid
/usr/bin/passwd myuid
/usr/bin/smbpasswd -a myuid
All passwords should be the same as the one on the Windows PC. While they can be different, on a first try it's best to keep all passwords for myuid the same.

Now restart Samba. The command is slightly different on different Linux distros. Here's a partial list:
 
/etc/rc.d/init.d/smb restart
Red Hat
/etc/rc.d/init.d/samba restart
Caldera
/etc/init.d/samba restart
Debian

Now start Windows Explorer, and browse from Network Neighborhood to "Entire Network" to groupname to servername to your username, and browse. You'll notice you're actually browsing your Unix box's home directory. This is the result of the [homes] share you placed in smb.conf.

If you've had problems getting this far, read the Samba Troubelshooting article immediately following. Otherwise, congratulations on creating your first Samba setup.

Steve Litt is the author of the newly released book, "Rapid Learning: Secret Weapon of the Successful Technologist". He  can be reached at Steve Litt's email address.

Samba Troubleshooting

By Steve Litt
The average call for help on comp.protocols.smb is a Troubleshooters nightmare. Here's a fictional example that's all too typical:
 
I can't see my Samba shares. One of you Samba gurus please help me. Here's my smb.conf

This is followed by a hundred or so lines of smb.conf.

The guy is viewing Samba as a huge, complex black box. Nothing could be farther from the truth. When confronted with a Samba problem, it takes maybe 2 minutes to isolate it to a subsystem. Divide and conquer. The first question is "does Samba work on the Linux box itself".

Does Samba Work on the Server

Try to access the homes share from the User ID you use on the Windows box:
smbclient '//servername/homes' -Umyuid
Be sure to use the same user id as on the Windows box after the -U. This will prompt you for a password, and if properly supplied will drop you to an smb: \> prompt, from which you can do commands like ls to prove you're seeing the home directory. Obviously, do no puts or deletes.
 
[root@mainserv /etc]# smbclient '//servername/homes' -Umyuid
Added interface ip=192.168.100.1 bcast=192.168.100.255 nmask=255.255.255.0
Password:
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.0.3]
smb: \>        

Now test browsing ability with this command:

smbclient -NL servername
should return any browseable shares, something like this:
[root@mainserv /etc]# smbclient -NL servername
Added interface ip=192.168.100.1 bcast=192.168.100.255 nmask=255.255.255.0
Domain=[MYGROUP] OS=[Unix] Server=[Samba 2.0.3]

        Sharename      Type      Comment
        ---------      ----      -------
        homes          Disk
        IPC$           IPC       IPC Service (Samba 2.0.3)

        Server               Comment
        ---------            -------
        SERVERNAME           Samba 2.0.3

        Workgroup            Master
        ---------            -------
        MYGROUP                                   

The preceding proved Samba is running and browseable, at least from the Linux box itself.

Note that if a share that should be browseable and is not, and if the following test succeeds, you probably have a browsability problem in smb.conf. Make sure the share has a browseable=yes, and use testparm to make sure that the global section has or defaults to browse list=yes. It's also handy to place browseable=yes in the global section.

If, after the above remediation attempts, either of the previous smbclient tests is still failing, continue on to Other Server Tests. Otherwise, Continue on to Does Samba Work on the Windows Client?.

Other Server Tests

If both the previous tests worked correctly, the problem is not on your Linux box or Samba setup. It's either in your network or your Windows box. However, if they don't work, the problem is on your Linux box, so you'll need more tests:
 
testparm tests your /etc/smb.conf for errors, and displays such errors and warnings. Fix all errors and warnings before further troubleshooting.
ps ax | grep smbd Checks for a running smbd. Without one, Samba doesn't work. If no smbd is found, restart samba as described in the Samba in 10 Minutes article. If it won't restart correctly, troubleshoot *that* problem before continuing.
ps ax | grep nmbd Checks for a running nmbd. Without one, Samba doesn't work. If no nmbd is found, restart samba as described in the Samba in 10 Minutes article. If it won't restart correctly, troubleshoot *that* problem before continuing.
ping the server's IP address Usually a loss of network connectivity will not prevent local Samba usage, but this is too easy a test to ignore. Fix this connectivity problem before continuing.

Once smbclient can browse and access shares on the Linux box, it's time to troubleshoot from Windows.

Does Samba Work on the Windows Client?

 
ping the server's IP address Without connectivity you cannot use Samba (nor any other network app). Fix this connectivity problem before continuing.
net use * \\servername\homes This accesses the home directory. Without this ability you cannot browse nor use Samba in any way. If this fails where smbclient '//servername/homes' -Umyuid succeeded on the server, it points to a problem with the username or netbios naming. Be sure you have a valid netbios name=servername line in the global portion of your smb.conf. Make sure that you've entered the same username and password through smbclient that you're using on the Windows machine. 
net view \\servername This tests browsing ability. This is very unlikely to fail if the previous test and the browsing test on the Linux box succeeded. However, if this is the case, troubleshoot as necessary. Note that Win9x has browsing problems in Windows Explorer, so if this succeeds where Windows Explorer failed, it's a problem with Win9x's Explorer's interaction with Samba. Note that Win NT does not have these problems.
browse Windows Explorer/network neighborhood/workgroup/servername/username for the home directory. This often doesn't work even though the net view \\servername does. In this case it's a problem with Explorer needing a master browser but not triggering an election for one. See the section on triggering a browser election.

Triggering a Browser Election

You can often trigger a browser election from Windows 9x with this command:
net view /workgroup:workgroupname
From Windows NT use this command:
net view /domain:workgroupname
And to trigger an election upon Samba startup, include the following in the global portion of smb.conf:
preferred master=yes
To trigger an election on Samba startup and pretty much guarantee that the Samba server will become the main browser, add the following lines to the global portion of smb.conf:
preferred master=yes
os level=65
local master=yes
domain master=yes
Usually a browser election is won within 30 seconds of the event starting it. You can real-time witness the winning of a browser election by viewing the output of the this command:
tail -f log.nmb
Note that log.nmb is in different places in different distros. On Red Hat 6 it's in /var/log/samba.

DIAGNOSIS.txt

This article's purpose was pretty much to explain preliminary Samba troubleshooting in divide and conquer terms. However, the correct way in the Samba world is to follow Andrew Tridgell's predefined diagnostic located in file DIAGNOSIS.txt, which is available in the distribution documentation. On Red Hat 6 it's at /usr/doc/samba-2.0.3/docs/textdocs/DIAGNOSIS.txt. Follow this ten step predefined diagnostic, and do not continue past a step that fails. If you get stumped and need tech support, be sure to send them the results you obtained in this predefined diagnostic.

Finer Testing

The testing in this article and in DIAGNOSIS.txt helps you narrow the problem to the nearest subsystem within two minutes. Often other steps are necessary to further narrow it. Typically these involve editing smb.conf and restarting samba. Please keep in mind that the easiest, quickest and most reliable tests involve small smb.conf files, not a 200 line whopper. Remember standard Troubleshooting tactics such as divide and conquer, finding commonalities, and exploiting differences.

If it's a live server that cannot be restarted or experimented with, try to reproduce the problem on a different machine and troubleshoot it there.

Summary

Samba brings heartache to those who panic and think of Samba as a black box. Those who see it as a system where you can easily make your own testpoints and have many software tools typically solve Samba problems within an hour.

Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist. He can be reached at Steve Litt's email address.

Samba Server Side Automation

By Steve Litt
This DP manager insisted the Windows half of the process run the Unix half of the process. The sysadmin could find no way except to run the Unix half as a once an hour cron job, meaning if the Windows half is kicked off at the wrong time, there's a 59 minute delay. If only I knew then what I know now.

Seems like one time or another everyone needs to kick off a Unix process from a Windows process, and nobody knows how to do it. One easy way is with Samba's Server Side Automation (SSA for short). There are two forms of SSA, exec and pseudo printer.

Exec Server Side Automation

Here's an example of Exec SSA in an smb.conf share:
 
[faculty]
read only=yes
write list=%U
root preexec=mkdir 0770 /faculty/%U & chown %U:%U /faculty/%U &
path=/faculty/%U
browseable=yes


This sets up a share called [faculty], visible in Network Neighborhood due to the browseable=yes. The %U is a substitution macro, for which Samba substitutes the username, resulting in the fact that each user gets his own directory under this share.

But what creates the directory? Of course, the sysadmin could create a new user script to create that directory every time a user is added. But that's a pain. So Samba's root preexec= parameter creates the directory with proper permissions and ownership upon first access to the share. If the directory's already there it's no big deal.

Here are the four parameters of Exec type SSA:
 
Parameter Function
preexec Run the process upon initial access to the share
root preexec Same as preexec, except do the process suid root
postexec Run the process upon disconnection of the share
root postexec Same as postexec, except do the process suid root

preexec and postexec can do only what Unix and Samba permissions allow, hence their usefulness is limited. The root versions can do pretty much anything, but of course if configured wrong create a security breach. The best strategy is to try for the less powerful versions, switching to the more powerful versions if necessary.

Exec SSA is great for Samba setup and termination processes, but it's a stretch to use them for anything else. The reason is that share access doesn't necessarily start and finish when expected. If a drive letter is permanently mapped, preexec will run soon after (Windows) boot and no other time. Similarly, if three drive letters are mapped to directories within a share, all three would need to be deleted before postexec would run.

Preexec and postexec are great for setup and teardown. In their root invocations, they're great for creating directories. One common use is to create a directory below /home/username for the Samba share, so the unwitting Windows user doesn't delete all his dot files. But they're ill suited to requests like the one to have the Windows process spawn the Unix one. Pseudo printers are best for that.

Pseudo Printer Server Side Automation

Printer shares are designated simply by the existance of a print ok=yes (or printable=yes). Here's the simplest possible printer share that creates no warnings in testparm:
[myprint]
print ok=yes
path=/var/spool/samba
printer name=lp
browseable=yes
This makes a printer called myprint visible in network neighborhood. It prints to the Unix printcap printer named lp, and it temporarily spools files in directory /var/spool/samba. Doubleclicking this printer in Windows allows you to create a Windows printer definition for it, thus making it printable from within Windows applications. Or even without doing that, you can simply use this command:

echo "Hello World^L" | \\myserver\myprint

This will print the phrase Hello World on a page, and because of the formfeed char at the end, will formfeed the printer. Note this all assumes that printcap printer lp is a straight through text printer.

So much for the Samba printer review. Samba printing is not rocket science. What they really do is call a command, called the "print command", represented by the print command= smb.conf parameter. Using

testparm | grep -i "print command"
you can find the default print command, which is usually something like this:
print command = lp -c -d%p %s; rm %s
Here %p is a substitution macro for the service's home directory, while the %s is a substitution macro for the file to be printed. There's nothing to say the print command need involve lp, lpr, or any other print related command. It can be anything. Hence the pseudo printer. So let's change it a little by adding our own print command:
[myprint]
print ok=yes
path=/var/spool/samba
printer name=lp
browseable=yes
print command=./unixprocess %s
Now the file goes to the unixprocess program (via command line arg) instead of to the printer. So if your Windows process creates a file called 1002c.txt, after writing and closing that file it can spawn the unix process to be run on that file with this simple command (assuming the Windows process to be a C program):
system("copy 1002c.txt \\\\myserver\\myprint");
Note the double backslashes are a C'ism, and that if you printed that command directly on the command line it would look like this:
copy 1002c.txt \\myserver\myprint
So the next time someone asks you how to spawn a Unix process from a Windows process, just tell them about the October 1999 Troubleshooting Professional Magazine.
Steve Litt wrote the "Samba" chapter in the newly released book, "Red Hat Linux 6 Unleashed", which is available at any bookstore. He  can be reached at Steve Litt's email address.

Other Samba Information

By Steve Litt

The articles in this issue of Troubleshooting Professional just scratch the surface. It gives you enough to understand the other Samba documentation. The more you learn about Samba, the more interesting it becomes. Its capabilities are almost limitless, and new features are incorporated with every new Samba version. I'll bet I could write a thousand page book on Samba. As a matter of fact, if enough readers show interest in it I just might do that. But for now, here are some of the places I recommend you look for Samba information:

Distribution Documentation

Your Samba distribution is packaged with all sorts of documentation. While it's not "intuitive", if read thoroughly and often it yields a wealth of information. The most helpful documentation is in the textdocs directory, and is in text form. This is where you'll find such essentials as: In addition to the textdocs directory, the faq directory has the Samba Server FAQ. There you'll find Samba-Server-FAQ.html and Samba-meta-FAQ.html and sambafaq.html, all three excellent. Make sure they're included in your browser bookmarks.

Man Pages

The king of all Samba man pages is man smb.conf. Other highly valuable ones are the smbd, nmbd, smbpasswd, and smbclient.

SWAT

Never log into SWAT as root unless you fully intend to change smb.conf with it. An accidental change from SWAT instantly and permanantly changes smb.conf. So log into SWAT as another user, and browse without worry. Swat gives access to great htmlized man pages, as well telling your configuration of almost every configuration option, and giving access to help on each.

www.samba.org

This is the most authoritative Samba information existent, straight from the Samba project. If you like Samba as much as I do, you'll spend hours there.

samba@samba.org

THE Samba mailing list, sponsored and heard by the Samba project members. After exhausting your research and troubleshooting options, this is where you ask those impossible questions. Be sure your DIAGNOSIS.txt results, and a small smb.conf reproducing your symptom. Be sure to answer questions too. Keep yourself in the black.

comp.protocols.smb

The preeminent Samba newsgroup, often listened to by Samba team members and other interested parties.  After exhausting your research and troubleshooting options, this is where you ask those impossible questions. Be sure your DIAGNOSIS.txt results, and a small smb.conf reproducing your symptom. Be sure to answer questions too. Keep yourself in the black.

Books

Until I write a Samba book, these are the two I can wholeheartedly recommend:

Red Hat Linux 6 Unleashed

Specifically, chapter 14, entitled Samba. This excellent chapter from an excellent book goes into much deeper detail than this Troubleshooting Professional Magazine issue. I can vouch for the quality of this chapter -- I wrote it. I also wrote the chapters on DNS, tcl/tk and Python. If you're serious about Linux, this is a must-have book. Incidentally, a less distro dependent version of this book, called Linux Unleashed, Fourth Edition, is due out October 22, 1999. I wrote the same four chapters in that book.

Teach Yourself Samba in 24 Hours

Samba team members Gerald Carter and Richard Sharpe wrote this outstanding book. If you're looking for an explantion of the things you see in the distro documentation, along with some excellent examples, this book is for you.

I won't write a Samba book until and unless I can do better than this book, and these guys set the bar awfully high. But you just never know. Stay tuned...

Steve Litt wrote the "Samba" chapter in the newly released book, "Red Hat Linux 6 Unleashed", which is available at any bookstore. He  can be reached at Steve Litt's email address.
 

Linux Log: Samba: The Trojan Horse into the Glass House

Linux Log is a regular column in Troubleshooting Professional Magazine, authored by Steve Litt. Each month we'll explore a facet of Linux as it relates to that month's theme.
Linux is as corporationally incorrect as they come. Its so lacks respect for capitalism that it's free. With source code. If it bombs, there's nobody to sue. The only people the glass house gang can blame are the ones they see in the mirror.

Sure, the big iron boys know it's more reliable than the Redmond Albatross. And they know it's a great web server for a small to moderate ISP. But you can't replace an NT file server with a Linux box.

Samba's changed all that. It allows any Linux box to act as a file server. Eyes light up all over the glass house. "The litigation department's been hounding us for a server but it's not in the budget. Let's take a hand me down desktop machine, make it a Samba server, and give it to them. Then maybe they'll leave us alone.". And that's how the Linux camel (or is he a penguin) gets his nose in the tent.

It soon becomes appearant the Samba server is outperforming its $300/user NT cousins. More Samba servers. If you've got one guy in IT who understands UNIX, that's all you need. Because Linux and Samba seldom break, and they're easy to administer for a knowledgeble person. Then someone from IT changes jobs, and finds himself heading IT in a small organization with a small budget. Add on Samba servers are one thing. But they can't replace an NT PDC.

Oh yes they can! As of Samba 2.0.5a you can configure Samba as an NT PDC, meaning it will act as a login server for both Windows 9x and Windows NT machines. Unless you're married to MS Exchange or MS SQL Server, there's no reason for an NT server. He calls his buddies in his old big iron deparment, and tells them the news. They smile. Contrary to public image, they hate Microsoft and fantasize about throwing Microsoft out the door.

Samba is the Trojan horse conquering the corporation for Linux.

Steve Litt is the author of the newly released book, "Rapid Learning: Secret Weapon of the Successful Technologist". He  can be reached at Steve Litt's email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue, with issues coming out monthly. We look for articles that pertain to the Troubleshooting Process. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

All submissions become the property of the publisher (Steve Litt), unless other arrangements are previously made in writing. We do not currently pay for articles. Troubleshooters.Com reserves the right to edit any submission for clarity or brevity. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

I (your name), am submitting this article for possible publication in Troubleshooters.Com. I understand that this submission becomes the property of the publisher, Steve Litt, whether or not it is published, and that Steve Litt reserves the right to edit my submission for clarity or brevity. I certify that I wrote this submission and no part of it is owned by, written by or copyrighted by others.
After that paragraph, write the title, text of the article, and a two sentence description of the author.
 

URLs Mentioned in this Issue