12.6. Troubleshooting Name Services This section looks at simple troubleshooting techniques for all the name services that you'll encounter, but only for the common problems that affect Samba. There are several good additional references for troubleshooting particular name services: Paul Albitz and Cricket Liu's DNS and Bind (O'Reilly) covers DNS, and the Windows Internet Name Service (WINS) and LMHOSTS files are discussed in a wide variety of documentation available from http://www.microsoft.com. The problems addressed in this section are as follows: You don't know which name services are in use. A hostname can't be looked up. The long (FQDN) form of a hostname works, but the short form doesn't. The short form of the name works, but the long form doesn't. A long delay occurs before the expected result.
12.6.1. Identifying What's in Use First, determine whether both the server and the client are using DNS, WINS, or local files to resolve names. Each operating system has a different preference: Windows NT tries WINS, then broadcast, then the LMHOSTS file, and finally HOSTS and DNS. Windows 2000 and later follow the same rules as Windows NT unless NetBIOS support has been disabled in the network settings. In that case, the client relies solely on DNS and a local hosts file. Samba daemons use lmhosts, WINS, the Unix system's name resolver (i.e., the gethostbyname( ) function), and then NetBIOS broadcasts (depending on the name resolve order parameter in smb.conf). Unix systems can be configured to use any combination of DNS, a local hosts files, or WINS and generally in any order.
A good rule of thumb is to always configure clients and servers to prefer a centralized directory service such as DNS or WINS over local files for resolving names to addresses. Local settings such as /etc/hosts and lmhosts have a tendency to get out of sync over time when deployed on multiple systems. By consolidating on a central name service, you have a single database to troubleshoot when clients are unable to resolve names: you know that either the name service is broken or the client or server is misconfigured. We recommend that both the client systems use WINS and DNS, and that Samba be configured to use WINS and the host operating system's name resolver. The Unix server itself should be configured to use DNS and fall back to the /etc/hosts file only in case of failure. You'll have to look at your notes and the actual systems to see which is in use. On the clients, the name services are all set in the TCP/IP Properties panel of the Networking Control Panel, as discussed in Chapter 3. You might need to check there to see what you've actually turned on. On the server, see whether a /etc/resolv.conf file exists. If it does, you're using DNS. You might be using the other name resolution options as well, though. Check for a /etc/nsswitch.conf file on Unix operating systems. If you have one, look for a line that begins with host: followed by files dns, or both. These are the name services to use, in order, with optional extra material in square brackets. The files keyword is for using a local hosts files, while dns (sometimes using the keyword bind for the Berkeley Internet Name Daemon) refers to using the Domain Name System. 12.6.2. Cannot Look Up Hostnames If you have isolated a problem to a name lookup and know from the previous section which service your local system is using, try the following:
DNS Use the nslookup or host command to resolve the machine name. If this fails, look for a /etc/resolv.conf error, an inaccessible DNS server, or a short name/FQDN problem (see the next section). Try the following solutions: Confirm that your /etc/resolv.conf file contains one or more nameserver lines, each with an IP address. These are the addresses of your DNS servers. Ping each server address you find. If this fails for one system, check that connectivity and DNS service on the system. If it fails for all, check your network. Retry the lookup using the full domain name including the finalizing period (e.g., server.example.com.) if you tried the short name first, or the short name if you tried the FQDN first. If results differ, skip to the next section.
Broadcast The broadcast mechanism supports only short names such as server, and not the FQDN variants, such as server.example.com. Run nmblookup -S server. This reports everything broadcast has registered for the name. In our example, it looks like this: $ nmblookup -S server querying server on 192.168.236.255 192.168.236.86 SERVER<00> Looking up status of 192.168.236.86 SERVER <00> - M <ACTIVE> SERVER <20> - M <ACTIVE> EXAMPLE <00> - <GROUP> M <ACTIVE> EXAMPLE <1e> - <GROUP> M <ACTIVE>
The required entry is SERVER <00>, which identifies server as being this system's NetBIOS name. You should also see your workgroup mentioned one or more times. If these lines are missing, NetBIOS broadcasts cannot look up names and will need attention.
WINS WINS is similar to the NetBIOS broadcast methods, and debugging WINS issues is very similar to debugging broadcast name resolution problems. The only real difference is that nmblookup must send the name query directly to the WINS server itself. This is accomplished by sending a unicast packet to the WINS server IP address (the -U option) and setting the recursive flag (the -R option) in the request. If nmblookup can resolve the name successfully, it will proceed to issue a node status request to the target server as it did with the broadcast mechanism. Assuming that we are using a WINS server at 192.168.1.74, the command and its output would appear as: $ nmblookup -U 192.168.1.74 -R -S server querying server on 192.168.1.74 192.168.236.86 SERVER<00> Looking up status of 192.168.236.86 SERVER <00> - M <ACTIVE> SERVER <20> - M <ACTIVE> EXAMPLE <00> - <GROUP> M <ACTIVE> EXAMPLE <1e> - <GROUP> M <ACTIVE>
The server and workgroup entries should display the same information as described in the broadcast tests. If there is an error, verify that the network and SMB/CIFS software are on the target machine.
hosts Inspect the HOSTS file on the client (%SYSTEMROOT%\system32\drivers\etc\hosts). Each line should have an IP number and one or more names, with the primary name first and then any optional aliases. An example follows: 127.0.0.1 localhost 192.168.236.1 dns.svc.example.com 192.168.236.10 client.example.com client 192.168.236.11 backup.example.com loghost 192.168.236.86 server.example.com server 192.168.236.254 router.svc.example.com
On Unix, localhost should always be 127.0.0.1. On the client, check that there are no #XXX directives at the ends of the lines; these are LAN Manager/NetBIOS directives and should appear only in LMHOSTS files.
LMHOSTS This file is a local source for LAN Manager (NetBIOS) names. It has a format similar to HOSTS files, but it does not support long-form domain names (e.g., server.example.com) and can have a number of optional #XXX directives following the NetBIOS names. There is usually an lmhosts.sam (for sample) file located in %SYSTEMROOT%\system32\drivers\etc on Windows clients, but it's not used unless it is renamed to lmhosts in the same directory. 12.6.3. Long and Short Hostnames Where the FQDN form of a hostname works but the short name doesn't (for example, client.example.com works but client doesn't), consider the following:
DNS This usually indicates that there is no default domain in which to look up the short names. Look for a default or domain line in /etc/resolv.conf on the Samba server containing your domain, or look for a search line containing one or more domains. One or the other might need to be present to make short names usable; which one is needed depends on the vendor and version of the DNS resolver. Try adding domain your_domain to resolv.conf, and ask your network or DNS administrator what should be in the file.
Broadcast/WINS The broadcast and WINS NetBIOS name services do not support fully qualified domain names; it won't suffer from this problem.
hosts If the short name is not in /etc/hosts, consider adding it as an alias. If you can, avoid short names as primary names (the first one on a line). Have them as aliases if your system permits.
LMHOSTS LAN Manager doesn't support names other than the short versions, so it won't suffer from this problem. On the other hand, if the short form of the name works and the long form doesn't, consider the following:
DNS This is not a normal or expected error. Troubleshoot the DNS server configuration or contact your DNS administrator if you do not manage that service.
Broadcast/WINS This is normal; NetBIOS name services can't use an FQDN. Optionally, consider DNS for locating specific servers wherever possible.
hosts Add the long name as at least an alias, and preferably as the primary form. Also consider using DNS if it's practical.
LMHOSTS This is normal. LAN Manager can't use an FQDN; consider switching to DNS or hosts. 12.6.4. Unusual Delays When there is a long delay before the expected result:
DNS Test the same name with the nslookup or host command on the system that is slow (client or server). If nslookup is also slow, you have a DNS problem. If the lookup is slower on a client, you might have too many protocols bound to the Ethernet card. Eliminate NetBEUI, which is infamously slow, assuming you don't need it. You can also use Wireshark to analyze the cause of any DNS delays.
Broadcast/WINS Test the client using nmblookup; if it's faster, you probably have the protocols problem mentioned in the previous item.
hosts The HOSTS file, if of reasonable size, is always fast. You probably have the protocols problem mentioned previously under DNS.
LMHOSTS This is not a name lookup problem; LMHOSTS files are as fast as hosts files. 12.6.5. Localhost issues When a localhost isn't 127.0.0.1, try the following:
DNS There is probably no record for localhost. A 127.0.0.1. Arrange to add one, as well as a reverse entry, 1.0.0.127.IN-ADDR.ARPA PTR 127.0.0.1.
Broadcast/WINS Not applicable.
hosts Add a line that says 127.0.0.1 localhost.
LMHOSTS Not applicable. |
