12.5. Troubleshooting Browsing Finally, we come to browsing. We've left this for last, not because it is the most difficult, but because it's both optional and partially dependent on network topology. Browsing is simply a way to find the servers on your network and the resources that they provide. But problems with browsing are hard to diagnose if you don't already know that all the other NetBIOS and SMB/CIFS services are running properly. 12.5.1. Testing the Server with nmblookup This section tests the "advertising" system used for Windows name services and browsing. Advertising works by broadcasting one's presence or willingness to provide services; it uses broadcasts and UDP packets. The nmblookup program can broadcast name queries for the hostname you provide and returns its IP address and the name of the system, much as nslookup does with DNS. Here, the -B option is used to define the broadcast address to use when sending the name query. If you do not list a specific broadcast address, nmblookup defaults to sending a request using the broadcast address of each available network interface (or the subset defined by the interfaces option). First, check the server locally. Run nmblookup with a -B option specifying your server's name (to tell it to send the query to the Samba server) and a parameter of _ _SAMBA_ _ (two underscores on each side) as the symbolic name to look up: $ nmblookup -B server _ _SAMBA_ _ querying _ _SAMBA_ _ on 192.168.236.86 192.168.236.86 _ _SAMBA_ _<00>
You should get the IP address of the server, followed by the name _ _SAMBA_ _, which means that the server has successfully advertised that it has a service called _ _SAMBA_ _, and therefore that at least part of NetBIOS name service works. If you get name_query failed to find name _ _SAMBA_ _, chances are that you either have a problem with name resolution, or nmbd is not running. Check to make sure you spelled the server's hostname correctly, then try again with nmblookup -B ip_address. If that fails too, nmbd isn't running. Go back briefly to the earlier section, "Troubleshooting Server Daemons." 12.5.2. Testing the Client with nmblookup Next, check the IP address of the client from the server with nmblookup using the -B option for the client's name and a parameter of '*' meaning "anything," as shown here: $ nmblookup -B client '*' querying * on 192.168.236.10 192.168.236.10 *<00>
You might get the following errors: If you receive name_query failed to find name *, the client software on the PC isn't installed, started, or bound to TCP/IP. Refer to Chapter 3 and ensure that you have a client installed that is listening to the network. Windows XP clients (at least those with Service Pack 2) do not seem to respond to the '*' name. These hosts will respond to queries for their own names, so retest using the client machine name in place of *. If nmblookup -B client_name fails but nmblookup -B client_IP_address succeeds, there is a name service problem with the client's name; go to "Troubleshooting Name Services," later in this chapter.
12.5.3. Testing the Network with nmblookup Run the command nmblookup again with a parameter of '*', this time without a specific broadcast address. Here we are testing the ability of programs (such as nmbd) to use broadcasts. It's essentially a connectivity test, done via a broadcast to the default broadcast address. The results lists the hosts on the network that respond. Samba might not catch all the responses in the short time it listens, so you won't always see all the SMB/CIFS hosts on the network. However, you should see most of them: $ nmblookup '*' 192.168.236.191 *<00> 192.168.236.228 *<00> 192.168.236.86 *<00> 192.168.236.79 *<00> 192.168.236.206 *<00> 192.168.236.10 *<00> 192.168.236.217 *<00> 192.168.236.72 *<00>
In case of failure: If this doesn't give at least the client address you previously tested, the default broadcast address is wrong (or it is running Windows XP). Try nmblookup -B 255.255.255.255 '*', which is a last-ditch variant. If this draws responses, the broadcast address you've been using before is wrong. Troubleshooting these is discussed in the "Broadcast Addresses" section, later in this chapter. If the address 255.255.255.255 fails too, check your notes to see whether your PC and server are on different subnets, as mentioned in the earlier section, "Testing connections with ping." You should try to diagnose this step with a server and client on the same subnet, but if you can't, you can try specifying the remote subnet's broadcast address with -B. Finding that address is discussed in the section "Broadcast Addresses" later in this chapter. The -B option will work if your router supports directed broadcasts; if it doesn't, you might be forced to test with a client on the same network.
As usual, you can check the Samba logfiles for additional clues. 12.5.4. Testing Browsing with smbclient From the server, try listing its own shares using smbclient with a -L option and your server's name. We'll stick to port 139 (-p option) since NetBIOS sessions are a required component of network browsing.[*] A server that is not configured to receive SMB/CIFS connections on port 139 will frequently have problems with participating in browsing and elections. You should get something resembling the following: [*] Windows clients do not support separating NetBIOS name services (137/udp) from NetBIOS session services (139/tcp). The client either supports NetBIOS in its entirety or does not support any of its services. We'll take the same approach when configuring Samba.
$ smbclient -L server -N -p 139 Anonymous login successful Domain=[EXAMPLE] OS=[Unix] Server=[Samba 3.0.22] Sharename Type Comment --------- ----- ---------- temp Disk homes Disk IPC$ IPC IPC Service (Samba 3.0.22) Server Comment --------- ------- SERVER Samba 3.0.22 CLIENT Workgroup Master --------- ------- EXAMPLE SERVER
Problems can be diagnosed as follows: If you didn't get a Sharename list, the server is not allowing you to browse any shares. This should not be the case if you've tested any of the shares with Windows Explorer or the net use command. If you haven't done the smbclient -L localhost -N test yet (see the earlier section, "Testing locally with smbclient"), do it now. Also check the smb.conf file to make sure that you do not have the option browsable = no anywhere in it: we suggest using a minimal smb.conf file (see the earlier section, "A minimal smb.conf file"). You need to have browsable enabled (which is the default) to see the share. Windows 2000 and later hosts do not allow you to browse for shares anonymously and return NT_STATUS_ACCESS_DENIED. You will, however, still be able to enumerate any servers or workgroups of which the host is aware. If you didn't get a browse list of servers or workgroups, the host might not be providing information about the systems on the network. At least one system on the net must support browse lists. Make sure that your Samba host has local master = yes and browse list = yes (both are enabled by default unless configured otherwise) in the smb.conf file if you want Samba to be the local master browser. If you didn't get a workgroup list with your workgroup name in it, it is possible that your workgroup is set incorrectly in the smb.conf file. If you get nothing, try once more with the additional options -I ip_address -d3. Remember that the -d3 option sets the log/debugging level to 3. Then check the Samba logs for clues.
If you're still getting nothing, you shouldn't have gotten this far; double back to at least "Troubleshooting Low-Level IP" and "Troubleshooting Server Daemons." On the other hand: If you get NT_STATUS_ACCESS_DENIED, you aren't permitted access to the server. If this is a Samba host, verify that the hosts allow option includes the server itself and the loopback address. If this is a Windows 2000 or later host, you must use a valid user account to connect (the -U option) instead of requesting an anonymous session (the -N option). If you attempt to connect with user credentials (the -U option) and instead get NT_STATUS_LOGON_FAILURE, verify that the account exists and you have the correct login name and password. Sometimes it might also be necessary to specify the domain name (the -W option) if you are connecting to a domain member server. If you get Connection refused, the smbd server is not currently running. Check that it's up, running, and listening to the network with netstat. See the earlier section, "Troubleshooting Server Daemons." If you get Connection to hostname failed, you've made a spelling error, there is a mismatch between the Unix and NetBIOS hostname, or there is a name service problem. Start name service debugging as discussed in the earlier section, "Testing connections with net use." If this works, suspect a name mismatch, and go to the later section, "Troubleshooting NetBIOS Names." If you get Session request failed, the server refused the connection. This message usually indicates an internal error, such as insufficient memory to fork a process or perhaps some problem with inordinate name resolution delays.
12.5.5. Testing Client Browsing with net view On the client, run the command net view \\server in an MS-DOS (command prompt) window to see whether you can connect to the client and ask what shares it provides. You should get back a list of available shares on the server.  | As was discussed in Chapter 8, anonymous browsing of servers has been one of the casualties in the effort to tighten network security. In some environments, anonymous browsing may still work. If you receive any messages indicating "Access denied," try retesting using a valid user account. The net.exe command allows you to specify the account credentials with the /user:username command-line option. |
|
If this test works, you have no further problems. Otherwise: If you get Network name not found for the name you just tested in the earlier section, "Testing the Client with nmblookup," there is a problem with the client software itself. Double-check this diagnosis by running nmblookup against the client; if it works and net view doesn't, the client is at fault. If nmblookup fails, there is a NetBIOS name service problem, as discussed in the later section, "Troubleshooting NetBIOS Names." If you get You do not have the necessary access rights, or This server is not configured to list shared resources, you probably have a hosts allow or hosts deny line that prohibits connections from your system. These problems should have been detected by the smbclient tests starting in the earlier section, "Testing browsing with smbclient." If you get The specified computer is not receiving requests, you have misspelled the name, the system is unreachable by broadcast (tested in the earlier section, "Testing the network with nmblookup"), or the system is not running nmbd.
12.5.6. Browsing the Server from the Client From My Network Places window, try to browse the server. You will probably first have to expand the Entire Network link. Your Samba server should appear in the browse list of your local workgroup. You should be able to double-click the name of the server to get a list of shares. If you receive an Unable to browse the network error, one of the following has occurred: You have looked too soon, before the broadcasts and updates have completed. Wait 30 seconds and try again. There is a network problem you haven't yet diagnosed. There is no browse master. Add the configuration option local master = yes to your smb.conf file.
If you receive the message \\server is not accessible:
If you've made it this far and the problem is not yet resolved, either the problem is one not yet covered here, or it is a problem related to a topic already covered, and further analysis is required. Name resolution is often related to difficulties with Samba, so we cover it in more detail in the next sections. If you know that your problem is not related to name resolution, skip to the "Extra Resources" section at the end of the chapter. |
