Troubleshooting and SWAT information
When Murphy crashes your party, it's time to do some troubleshooting. The list below is by no means complete or seminal. It's simply a compliation of years of working with Samba, and many many hours tracking user's cries for help on the Samba mailing list.
- First and foremost, determine where exactly your problem lies and how it occurred. Is it on the server end, or the client? Did it occur in conjunction with something else? Can you isolate the problem? Did you check your network cables? Are you SURE it's Samba related (this one in particular has bitten me several times), can you perform the same action without difficulty from another workstation? Are the Samba daemons running?
- If you start the Samba daemons and they unexpectedly die, run the Samba testparm utility on your configuration file. Chances are you have a syntax error somewhere. As a matter of fact, experience has taught me that the two most common errors that cause Samba to stop running or lose functionality are: (1) typos in
smb.conf, and (2) incorrect permissions on a file or directory.
- The client can't save a profile to the PDC? Read the above again. And check your directory permissions.
- The client can't join the domain? Check to ensure user and machine accounts exist on the controller. If necessary, create them manually.
- If you try and join the domain, and get a "Cannot join domain..." or "Cannot create account, you already have a connection to the domain" message, check to ensure there are no existing mapped drives to the server. If there are, kill them by typing net use
* /din a command prompt window.
- If you can't join the domain, and you created the machine account manually, check to ensure you didn't forget to add the dollar-sign (
'$') after the machine name.
- If you can't join the domain, and are using the add
user scriptoption to automatically create machine accounts, double check the option. If nothing looks amiss, disable it, and manually create the machine account. Now try again.
- If all the above fails, go back through the tutorial and double check everything. Methodically. Again, the material presented here has been tripled checked. The
smb.conffile was moved to a clean install of Redhat, the directories and permissions were created/set as shown, and the controller was tested with a Windows XP client. Everything worked first time without error or incident.
- Finally, failing everything else, send a message to the Samba mailing list asking for assistance. Don't forget to detail your problem clearly, what you've tried so far, and enclose your configuration file. The list is populated by a lot of very fine people; someone will no doubt come to your rescue.
A lot of administrators accustomed to GUI configuration tools find working with a command line editor like vi or emacs both intimidating and frustrating. Situations like this are precisely what SWAT was designed to address. SWAT stands for Samba Web Administration Tool, and is bundled with the Samba package. In short, SWAT puts an easy to navigate interface on
smb.conf using any web browser. It also provides context-sensitive help for all options, and a link to the vast array of documentation shipped with Samba.
Unfortunately, convenience always comes at a cost. First and foremost, SWAT requires the root password to accomplish much of anything, and that password is transmitted in plain text. This dangerous security breach is offset somewhat by the fact that SSL/HTTPS can be used for remote connections (there's a HOWTO located at www.samba.org/samba/docs/swat_ssl.html). Second, SWAT has a habit of rearranging the order of entries in smb.conf when changes are saved. If you've got a carefully ordered configuration file complete with insightful comments, I do not recommend using SWAT.
Another difficulty with SWAT is that it's turned off by default and users unfamiliar with the landscape of Redhat seem to have a lot of trouble turning it on. This last problem is easy to fix.
The are two ways to enable SWAT, depending on whether your system is configured to use xinetd or inetd.
For systems running xinetd (RH 7.2 and, I believe, 7.1), the script
/etc/xinetd.d/swat must be edited (as root). Change the line that reads
disable = yes to
disable = no. If you want to access SWAT from a remote machine (a very bad choice on anything but a firewalled intranet), place a pound sign (
'#') in front of the line that reads only_from = localhost. Now re-start the xinetd daemon by typing service xinetd reload (again, as root). You should now be able to access the SWAT service directly from the local machine by typing
httpd://localhost:901, or from a remote host by substituting localhost for the host name.
On systems running inetd, two files must be edited. Ensure that
/etc/services contains the line:
Next, open /etc/inetd.conf and locate the line that reads:
swat stream tcp nowait.400 root /path/to/the/swat/binary swat
/path/to/the/swat/binary with the correct path. For example,
/usr/sbin/swat. Now restart the inetd service: service inetd reload. Follow the procedures in the paragraph above to connect to your server.