Troubleshooting Professional Magazine
[ Troubleshooters.Com | Back Issues ]
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!
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 myuidAll 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:
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.
|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".
smbclient '//servername/homes' -UmyuidBe 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 servernameshould 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?.
|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.
|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.|
net view /workgroup:workgroupnameFrom Windows NT use this command:
net view /domain:workgroupnameAnd to trigger an election upon Samba startup, include the following in the global portion of smb.conf:
preferred master=yesTo 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=yesUsually 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.nmbNote that log.nmb is in different places in different distros. On Red Hat 6 it's in /var/log/samba.
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.
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.
[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:
|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.
[myprint] print ok=yes path=/var/spool/samba printer name=lp browseable=yesThis 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 %sHere %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 %sNow 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\myprintSo 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.
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:
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...
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.
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):