From: www.itworld.com

Skirting some common Samba problems

by Richard Sharpe

March 23, 2001 —

 


There I was, in the middle of a Samba class -- and nothing was working! Half the class had Linux boxes running Samba, and the other half had Windows 98, which had been installed by the company we rented the machines from. Each pair of delegates had configured their Samba server and Windows 98 client in a unique workgroup, and the Windows users were trying to see their Samba servers from Network Neighborhood in Windows 98. Alas, all their clicking on Network Neighborhood failed to get any results.


With my credibility crumbling, I quickly fired up Ethereal (see Resources) and checked out what was happening on the wire. The reason for the problem was obvious -- and isn't it always! The Windows 98 clients had NetBEUI on them because the rental company had used Ghost to install the same image on them all; that image had NetBEUI as well as TCP/IP configured. NetBEUI was the default protocol and the Windows 98 clients were using it to browse the network. Samba does not yet work with NetBEUI, so it was not taking part in the browsing at all.




The fix was simple, of course: remove NetBEUI from each of the Windows 98 clients, restart them, and voilà! everyone could browse the network and see the Samba servers.



This is but one of the many problems that new and old users of most distributions of Samba encounter. On the Linux mailing list where I usually hang out, LinuxSA (see Resources), we see the same set of problems all the time. In this article, I'll outline some of these problems and suggest ways to recognize and -- most importantly -- fix them.


File and print services

Samba is a very popular open source server package with which Linux system can provide file and print services (also known as shares) for Windows clients of all types. Current versions of Samba (2.0.7) have rudimentary Primary Domain Controller (PDC) support, while Samba TNG can perform most PDC functions, even for Windows 2000 clients. Samba implements the Server Message Block (SMB) protocol, a complex protocol that was developed by IBM in 1984.



Samba ships with all Linux distributions that I am aware of, but, because of distribution cycles, the version that ships can often be behind the version available at the Samba Website.



Samba is used by many people around the world on a daily basis in a production capacity. Perhaps this is because of Samba's open source nature, the fact that it ships with Linux distributions, or because of the Samba team's efforts to supply a product that is quite compatible with Windows NT.



If your Samba server is correctly configured, you will see one or two copies of nmbd running, along with one copy of smbd plus one copy of smbd for each connected user. You can check whether these services are running with the following command:




ps ax | grep mbd




In addition, the smbstatus command can be very useful.



Password problems

Samba is a very complex package with many options and features, which can cause problems for new and old Samba users alike. Indeed, whole books have been written about Samba (see Resources for a selection). While many efforts have been made to make the versions (2.0.6 and 2.0.7) included with currently shipping Linux distributions easier to use out of the box, there are still problems that both casual and more experienced users are likely to encounter.


Without doubt, the problem we see most often on the LinuxSA mailing list has to do with encrypted passwords. The messages usually go something like this: "I just installed Red Hat 6.2 and saw that Samba was running, so I tried to browse the network from my Windows system and got a message about needing a password for IPC$. What did I do wrong? And what is this IPC$ anyway?"



This cry for help was most likely sent after these users got the error shown in Figure 1.

Figure 1. Windows wants a password for the IPC$ share

This problem is caused by encrypted passwords! More specifically, it is caused by different default configurations in Samba and Windows:



  1. Versions of Window 95 with the VREDIR update (and shipping versions after OSR2), Windows 98, Windows NT 4.0 SP3 and above, and Windows 2000 all send encrypted passwords by default, regardless of what the server says it can handle. When using encrypted passwords, Windows uses a complex challenge/response scheme to ensure that neither plain-text passwords nor password equivalents are sent across the wire.
  2. By default, Samba uses plain-text passwords, and Samba versions 2.0.0 and above require that users authenticate before they use resources on the server. When a client sends an encrypted password, Samba tries to match the response Windows sent with the user's password hash in the passwd file, and authentication fails. The result is a message like that in Figure 1.




There are two solutions to this problem, and you can implement both very quickly:



The first possibility is to apply one of the registry hack files from your Samba installation to your Windows systems to stop the latter from sending encrypted passwords. These files are kept in /usr/doc/samba-$version/docs, and have names like Win98_PlainPassword.reg. Simply copy the appropriate files to a floppy with:



cd /usr/doc/samba/2.0.7/docs

mcopy Win98_PlainPassword.reg A:



Of course, if you don't have the mtools installed, now might be a good time to install them so that you can use the mcopy command.



Once you have copied the correct file(s) to a floppy, take the floppy to your Windows machines and double-click the file. This will install the registry patch into Windows. Make sure that you use the correct patch file if have you have put several onto the floppy. Unfortunately, you must also reboot Windows at this point. When your Windows machine comes back up, it will use plain-text passwords, and the previous error message will be a thing of the past (as long as the username and password you used to log on to your Windows client is the same as that on your Samba server).



Be aware, though, that your network is now using plain-text passwords, and if anyone is snooping with a sniffer like Ethereal, all passwords will be compromised.



The alternative is to convert your Samba server to use encrypted passwords. You can do this by adding the following lines to the [global] section of your smb.conf file (found in /etc/smb.conf).




encrypt passwords = yes

smb passwd file = /etc/smbpasswd



Next, you must populate the smbpasswd file with the accounts that you want to have access to your Samba. You can do this with the following command:




smbpasswd -a <user>



You will also need to set passwords for all the users you have added to your smbpasswd file. Use the smbpasswd command again:




smbpasswd <user>



Make sure you enter the correct password for your new user and confirm it when asked.



Every entry in the smbpasswd file must have a corresponding entry in the /etc/passwd file (or wherever you keep your account information), because Samba bases access permission checks on the Linux account associated with the user. So, before adding new entries to your smbpasswd file, you will want to check that these users have accounts under Linux.



After finishing the above steps, restart Samba (samba restart will do it under most Linux distributions). At that point, you should be able to browse your Samba server, provided the password you used to log on to your Windows system is the same as that for your account on your Samba server.



Note that it may take a few minutes for the browse list to become available from your Samba server.



Oh, by the way, that IPC$ is a special internal share that is used by Windows clients for browsing and a number of other purposes.


Upgrading into trouble


There is another type of password problem that you might encounter. It happens when you upgrade from a version of Samba prior to 2.0.0 to Samba 2.0.0 or later. This could happen when you upgraded from Red Hat 5.1 to 6.0, for example.



Under versions of Samba prior to 2.0.0, the default security level was server (i.e., security = server). When a Samba server is set to use share-level security, anyone can potentially access shares on the server without a password. This is especially true if you have created a guest account, and you have configured public access for all shares.


However, once you upgrade to Samba 2.0.0 or above, the default configuration of Samba changes to security = user, and you might get a message similar to the one in Figure 1 above when trying to access shares after the upgrade. Of course, in this case, the error message will not mention IPC$. Rather, it will mention the name of the share you tried to access.



This problem will only occur if you omitted the security= parameter from your smb.conf file. Because this file is so daunting, lots of people prefer to deal with it as little as they can and accept the defaults. However, the default smb.conf supplied with most distributions prior to Samba 2.0.0 had the security parameter commented out! This meant that your server operated in share-level security; public access to your shares worked, and users did not need to worry too much about accounts.



From Samba 2.0.0, the default for this parameter changed to user-level security (i.e., security = user), and public access to shares no longer worked in the same way. The likely result was that your users started getting messages similar to that in Figure 1 after you upgraded either Samba or Linux.



There is a way to provide public shares, however. It involves setting the following parameter in your smb.conf file and restarting Samba:




map to guest = bad user



This parameter tells Samba that whenever authentication fails because a user does not have an account on your Samba server, and as long as the share the user is trying to access is listed as being public (public = yes, or guest ok = yes), then the user's access request should be mapped to the guest account. As long as you have a valid guest account configured, public access will be allowed.



Browsing problems


Perhaps the next biggest Samba complaint goes something like this: "I have just installed Samba and set the workgroup on my Windows PCs to the same as my smb.conf file, but I cannot browse the network. I keep getting a message like 'Unable to browse the network.' How do I fix this?"



Usually, this request for help is caused by the error shown in Figure 2.


Figure 2. Windows cannot browse the network



This problem is less likely to occur with Samba 2.0.6 and beyond; it results from a poor set of browsing defaults in Samba. It can be caused by one of the following conditions:


  1. There is no master browser on your network. If Samba is the only SMB server in your network, this problem is likely a result of configuration problems on your Samba server. We will discuss these configuration problems in more detail below.
  2. nmbd is not running on your Samba server. Because nmbd implements the first part of the browsing protocol, you will not be able to browse your network if it is not running. If this is the case, you should investigate why nmbd is not running. The first place to look is the logfile it creates, which is usually in /var/log/samba/log.nmb. Of course, if nmbd is not running, plenty of other things will not work with Samba, either.



While it would take too much space to explain the whole browsing protocol, there are some parameters you should set in the [global] section of your smb.conf file to ensure that browsing works:




os level = 33

local master = yes

preferred master = yes



Prior to Samba 2.0.6, these parameters were by default set to:




os level = 0

local master = no

preferred master = no



The latter settings will prevent your Samba server from becoming a master browser in your network. If this is the case and your Samba server is the only SMB server in your network, browsing simply will not work if your Windows systems are all running Window 9x.



The defaults for Samba 2.0.6 and beyond are much more sensible, and are set to:



os level = 20

local master = yes

preferred master = yes



Important note: Some books suggest that you also set domain master = yes. This is poor advice if an NT PDC and your Samba server are in the same domain/workgroup. It can often cause the NT PDC to stop functioning as a PDC. If that occurs, you will have lots of angry NT administrators chasing you when they find out what has caused their NT network to come crashing down.



Finally, Samba only supports file sharing over TCP/IP, while other products, like NT, provide for file sharing over NetBEUI and IPX as well. Some users have multiple protocols configured on their Windows systems, often including both NetBEUI and TCP/IP. This can slow browsing considerably or even stopping it from working altogether.



These problems happen because Windows sends browsing requests via its primary protocol first. If it gets no answer with that protocol, it tries the other protocols in turn, but only after it has timed out on the primary protocol. If NetBEUI is your primary protocol, Samba will not see the browse requests the first time around.



The browsing problem I found during the class I was teaching was caused by another problem, however. The Windows 98 PCs actually elected a master browser from among themselves via NetBEUI. This master browser didn't bother listening to the Samba servers on TCP/IP, so none of the Samba servers appeared in browse lists.



Shares unavailable



Another curly problem you may encounter relates to creating new shares. Sometimes after you have created a new share, you get the error message shown in Figure 3 when trying to access the share from Windows.



Figure 3. Windows complains that the share you just created does not exist




There are two possible reasons for this problem:



  1. You forgot to create the directory that the share is pointing to, or you made a spelling mistake while entering the share's path in your smb.conf file.



  2. You do not have permission to access the directory that the share points to.



In each case, Samba returns an error message that causes Windows to pop up the message shown. This can be very confusing until you spot the spelling mistake or the permission problem.



Conclusion



We have discussed a number of problems that new Samba users are likely to encounter, and have provided solutions to them as well. You will find Samba much easier to manage once you are aware of these problems. For more detail on configuring Samba, have a look at one of the many Samba books available. You can also find a list on the Samba Website under the books link.



Resources





LinuxWorld.com links

LinuxWorld.com home

Best of LinuxWorld.com

The Legacy Files

The Penguin Brief

Version Control

Linux links




 


LinuxWorld.com