In a perfect world, you'd install software and it would work with no problems. Unfortunately, nothing's perfect—not even Linux. Here's what to do when things go wrong.
In my recent article on configuring Red Hat's Enterprise Linux, I discussed how you could configure SAMBA so that files on a Linux server would be accessible to Windows users. Any time that you are trying to establish communications between two completely different operating systems though, there is a potential for things to go wrong. In this article, I want to discuss some troubleshooting techniques for accessing a SAMBA share from Windows.
Verify basic network connectivity
Although it might seem a little bit basic, I recommend that you initially start the troubleshooting process by verifying that TCP/IP connectivity exists between the Linux server and the Windows clients.
Begin the process by selecting the System Settings | Network commands from the Linux server's Applications menu. When you do, you will see the Network Configuration properties sheet. Begin by looking at the reference to the server's NIC on the properties sheet's Device tab. Verify that the check box in the NIC's Profile column is selected. This means that the NIC is enabled.
With the NIC selected, click the Edit button. You will now see the Ethernet Device properties sheet. Verify that the Activate Device When Computer Starts check box is selected on the properties sheet's General tab.
Being that most servers use a static IP address, verify that the Statically Set IP Address option is selected. You should also verify that the correct IP address, subnet mask, and default gateway address has been entered. If your server does use a dynamic IP address, then make sure that the Automatically Obtain IP Address Settings With option is set to DHCP mode.
Click OK to return to the Network Configuration Properties sheet. Now, go to the Hardware tab and just take a quick look to make sure that Linux has identified the NIC correctly. Linux usually doesn't have a problem identifying common brands of NICs, but it's still worth checking.
Now, move on to the properties sheet's DNS tab. The hostname should be entered as a fully qualified domain name (server.domain.com). The domain portion of the server name should match the name used by your Windows domain. This tab should also have at least one DNS server entered. This should be the IP address for the DNS server used by your domain controllers, not the address of your ISP's DNS servers. Finally, check the DNS search path to make sure that it is set to reflect the domain.com portion of the server's fully qualified domain name. For example, if the server's fully qualified domain name is set to myserver.mynetwork.com, then the DNS search path should be set to mynetwork.com.
Once you have confirmed the DNS settings, take a look at the properties sheet's Hosts tab. Normally, the Hosts tab should only be configured with the server's loopback address (127.0.0.1). If there are other entries in the host tab, they should be deleted (unless you have them there for a specific purpose) because they will take precedence over information derived from a DNS server.
Now that you have checked over your adapter's IP address settings, it's time to verify that Linux is actually using those settings. To do so, select the System Tools | Terminal commands from the Linux Applications menu. When the Terminal screen opens, enter the IFCONFIG command (not to be mistaken for the IPCONFIG command used by Windows). This will display a summary of your NIC's IP address configuration (this is a great way to find out if your DHCP server is working). The IFCONFIG command won't display DNS configuration information, but it will show you the number of TX and RX packets that have passed through the NIC.
After confirming that packets are indeed passing through your NIC, try pinging one of your Windows workstations that is having trouble accessing the SAMBA share. To do so, simply type the PING command into the Terminal screen, followed by the Windows workstation's IP address. The PING will go on indefinitely until you press [CTRL][C].
If the Linux server is able to PING your Windows workstation, try pinging the Linux server from the Windows workstation. Assuming that both machines are able to PING each other, you can rest assured that there is at least a TCP/IP path between the two machines and that they can talk to each other.
The next thing that I recommend doing is pinging the fully qualified domain name of the Windows machine from the Linux machine. This insures that the Linux machine is able to use the DNS server to resolve the Windows machine's host name. Again, the ping will continue indefinitely until you press [CTRL][C].
Is SAMBA running?
Now that we have confirmed that connectivity exists between the two machines, it's time to turn our attention to SAMBA. The first thing that we need to do is to verify that SAMBA is actually running. To do so, log into your Linux server as root and open a Terminal screen. Now, enter the following command:
smbclient -L localhost
When you enter this command, you will be prompted to enter a password. By default there is no password, so unless you have set one up, just press [Enter]. After doing so, you will see a summary of the shares that SAMBA is hosting. This proves that SAMBA is running.
If you get a Connection Refused message, it means that SAMBA is not running. If this happens to you then enter the following command to start SAMBA:
service smb start
After issuing this command, use the
localhost command once more to verify that SAMBA is now running.
Issuing the service smb start command should have fixed the problem, but it is
a temporary fix. You still need to make sure that SAMBA starts automatically
next time you reboot the server. To configure SAMBA to launch automatically
upon system startup, enter the following command:
chkconfig smb on
Locate the Linux server from Windows
Now that you can confirm that SAMBA is running, you should try to connect to your Linux server from a Windows machine. The exact method for doing so varies depending on the version of Windows that you are running. To attach from Windows XP though, you would select the My Network Places command from the Start menu. When you do, you will see a list of network resources that you have recently connected to.
The Linux server probably won't be listed here, but if you look in the window's left margin, you will see that there is a section labeled Other Places. Click the Entire Network link found in the Other Places section and you will see a window giving you a choice between the Microsoft Terminal Services, Microsoft Windows Network, and Web Client Network. Double click on the Microsoft Windows Network icon and you will see a list of the domains on your network.
As you will recall in one of the previous sections, I mentioned that you need to make sure that the Linux server's fully qualified domain name conforms to the name of one of your Windows domains. The reason for this is that the Linux server isn't actually a member of a domain, but by giving it a name that incorporates the name of a Windows domain, Windows will display the Linux server as though it were a part of that domain. Therefore, if you double click on the domain that matches the domain portion of the Linux server's fully qualified domain name, you should see all of the computers in that domain, including your Linux server.
If you have a large network, you may have hundreds, if not thousands of computers listed as being a part of the domain. You can make it easier to locate your Linux server by selecting the Arrange Icons By | Name commands from the window's View menu. As you scroll through the window looking for your Linux server, it's worth noting that the server might not use the name that you would expect.
For example, in preparation for writing this article, I set up a Linux server on my Windows network. The fully qualified domain name of my Linux server is Linux.brienposey.com. However, the listing of computers in the brienposey.com does not show a computer named Linux.brienposey.com, or even a computer named Linux. Instead, the server is listed as Samba Server (Linux). Therefore, if you have alphabetized your list of computers in an effort to make finding the Linux Server easier, try looking under the letter S for Samba rather than looking for the server's real name.
Once you locate your Linux server in the list of computers in your domain, double click on the server to connect to it. When you do, you will be prompted to enter your user name and password (this is the Windows user name and password that you assigned to the shared SAMBA resource). You should now have access to the SAMBA share.
What went wrong?
If you were able to locate your Linux server in the list of computers, but were unable to connect to it, there are a couple of different things that could potentially be going on. If you are receiving an error message stating that the connection was refused, then the issue is most likely firewall related. Red Hat Enterprise Linux has a built in firewall just like Windows does. If the necessary ports aren't open in the firewall, then SAMBA connectivity will fail.
The easiest way to test to see if the firewall is causing the problem or not is to temporarily disable it and then try attaching to the server again. To disable the firewall, select the System Settings | Security level commands from the Linux Server's Applications menu to open the Security Level Configuration properties sheet. Now, select the Disable Firewall option from the Security level drop down list found on the Firewall Options tab. Click OK ant the firewall will be disabled.
Now that the firewall is disabled, try connecting to the Linux server from a Windows workstation again. This time the connection should be successful. If the connection is still refused, then you may have a hardware firewall somewhere between the two machines.
If you find that disabling the firewall solves your problem then you simply need to open a few ports and then re-enable the firewall. The Firewall Options tab of the Security Level Configuration properties sheet contains an Other Ports field that you can use to enter the ports that you wish to open. In order to make SAMBA work correctly, you must open ports 137, 138, and 139.
The last potential problem that I want to discuss is that of password not being accepted. As you may recall, when you initially set up SAMBA, you were required to map a Windows user name and password to a Linux user account. Normally, when you click on a SAMBA share from a Windows machine, you would enter the Windows username and password and would then be given access to the share. Occasionally though, things don't exactly work the way that they are supposed to.
If you are having problems getting SAMBA to accept your password, then the easiest way to diagnose the problem is to take the windows machine out of the equation. Rather than logging on from a windows machine, open a Terminal window on your Linux server and try logging into the share from a command prompt. To do so, you will use the smbclient command. The syntax for this command is as follows:
Smbclient //servername/sharename -U username
Since we are attaching to the SAMBA share from the same machine that is hosting the share, you would enter localhost as the server name. The share name would be the name assigned to the SAMBA share, and the username would be the name of your Windows account that you have mapped to a Linux account.
When you execute this command, you will be prompted to enter a password. If the password is correct then you should see information displayed regarding the server and be taken to an SMB prompt.
If the password is rejected, then there are a couple of things that could be going on. One possibility is that SAMBA is configured not to use encrypted passwords. Windows XP uses encrypted passwords (some older versions of Windows don't), so SAMBA should be configured to expect passwords to be encrypted. To check the password encryption setting, go to the Samba Server Configuration properties sheet and select the Server Settings command from the Preferences menu. When you do, you will see the Server Settings properties sheet. Select this properties sheet's Security tab and verify that the Encrypt Passwords option is set to Yes.
The other possibility is that you have an account mismatch. If you pay close attention to the screen that allows you to set up SAMBA accounts, you will notice that it asks you for the name of a UNIX account, a Windows account, and a SAMBA password.
Obviously, you don't want to have a UNIX account on the server that doesn't have a password. Therefore, when you set up the UNIX account, you probably assigned it a password. If you look at the Create New Samba User dialog box though, you will notice that you only have the option of entering this account's name, not its password. In order to make everything work, the SAMBA password should be set to the same thing as the account's UNIX password. I also recommend setting the Windows username to the same thing as the UNIX username, but that isn't an absolute requirement. What is important to remember is that the Windows username that you specify here is completely separate from anything that you might have set up on a Windows server, unless you have configured Linux to authenticate users through the Active Directory.
Not as hard as it seems
As you can see, troubleshooting a SAMBA connectivity issue is fairly simple. The most difficult past of the process is simply getting used to the differences in the two operating systems.