Chapter 33. The Samba Checklist

Chapter 33. The Samba Checklist
Prev	Part V. Troubleshooting	Next

Andrew Tridgell

Samba Team

<tridge@samba.org>

Jelmer R. Vernooij

The Samba Team

<jelmer@samba.org>

Dan Shearer

Samba Team

<dan@samba.org>

Wed Jan 15

Table of Contents

Introduction
Assumptions
The Tests

Introduction

-This file contains a list of tests you can perform to validate your -Samba server. It also tells you what the likely cause of the problem -is if it fails any one of these steps. If it passes all these tests, -then it is probably working fine. -

-You should do all the tests, in the order shown. We have tried to -carefully choose them so later tests only use capabilities verified in -the earlier tests. However, do not stop at the first error as there -have been some instances when continuing with the tests has helped -to solve a problem. -

-If you send one of the Samba mailing lists an email saying, “it does not work” -and you have not followed this test procedure, you should not be surprised -if your email is ignored. -

Assumptions

-In all of the tests, it is assumed you have a Samba server called -BIGSERVER and a PC called ACLIENT both in workgroup TESTGROUP. -

-The procedure is similar for other types of clients. -

-It is also assumed you know the name of an available share in your -smb.conf. I will assume this share is called tmp. -You can add a tmp share like this by adding the -lines shown in . -

Example 33.1. smb.conf with [tmp] share

[tmp]

comment = temporary files

path = /tmp

read only = yes

Note

-These tests assume version 3.0.0 or later of the Samba suite. -Some commands shown did not exist in earlier versions. -

-Please pay attention to the error messages you receive. If any error message -reports that your server is being unfriendly, you should first check that your -IP name resolution is correctly set up. Make sure your /etc/resolv.conf -file points to name servers that really do exist. -

-Also, if you do not have DNS server access for name resolution, please check -that the settings for your smb.conf file results in dns proxy = no. The -best way to check this is with testparm smb.conf. -

- -It is helpful to monitor the log files during testing by using the -tail -F log_file_name in a separate -terminal console (use ctrl-alt-F1 through F6 or multiple terminals in X). -Relevant log files can be found (for default installations) in -/usr/local/samba/var. Also, connection logs from -machines can be found here or possibly in /var/log/samba, -depending on how or if you specified logging in your smb.conf file. -

-If you make changes to your smb.conf file while going through these test, -remember to restart smbd and nmbd. -

The Tests

Procedure 33.1. Diagnosing your Samba server

- -In the directory in which you store your smb.conf file, run the command -testparm smb.conf. If it reports any errors, then your smb.conf -configuration file is faulty. -
Note
-Your smb.conf file may be located in: /etc/samba -or in /usr/local/samba/lib. -
-Run the command ping BIGSERVER from the PC and -ping ACLIENT from the UNIX box. If you do not get a valid response, -then your TCP/IP software is not correctly installed. -
-You will need to start a “dos prompt” window on the PC to run ping. -
-If you get a message saying “host not found” or similar, then your DNS -software or /etc/hosts file is not correctly setup. -It is possible to run Samba without DNS entries for the server and client, but it is assumed -you do have correct entries for the remainder of these tests. -
-Another reason why ping might fail is if your host is running firewall -software. You will need to relax the rules to let in the workstation -in question, perhaps by allowing access from another subnet (on Linux -this is done via the appropriate firewall maintenance commands ipchains -or iptables). -
Note
-Modern Linux distributions install ipchains/iptables by default. -This is a common problem that is often overlooked. -
-If you wish to check what firewall rules may be present in a system under test, simply run -iptables -L -v or if ipchains-based firewall rules are in use, -ipchains -L -v. -
-Here is a sample listing from a system that has an external ethernet interface (eth1) on which Samba -is not active, and an internal (private network) interface (eth0) on which Samba is active: -
```
-frodo:~ # iptables -L -v
-Chain INPUT (policy DROP 98496 packets, 12M bytes)
- pkts bytes target     prot opt in     out     source     destination
- 187K  109M ACCEPT     all  --  lo     any     anywhere   anywhere
- 892K  125M ACCEPT     all  --  eth0   any     anywhere   anywhere
-1399K 1380M ACCEPT     all  --  eth1   any     anywhere   anywhere  \
-					state RELATED,ESTABLISHED
-
-Chain FORWARD (policy DROP 0 packets, 0 bytes)
- pkts bytes target     prot opt in     out     source     destination
- 978K 1177M ACCEPT     all  --  eth1   eth0    anywhere   anywhere \
-					state RELATED,ESTABLISHED
- 658K   40M ACCEPT     all  --  eth0   eth1    anywhere   anywhere
-    0     0 LOG        all  --  any    any     anywhere   anywhere \
-					LOG level warning
-
-Chain OUTPUT (policy ACCEPT 2875K packets, 1508M bytes)
- pkts bytes target     prot opt in     out     source     destination
-
-Chain reject_func (0 references)
- pkts bytes target     prot opt in     out     source     destinat
-
```
-
-Run the command: smbclient -L BIGSERVER -on the UNIX box. You should get back a list of available shares. -
-If you get an error message containing the string “Bad password”, then -you probably have either an incorrect hosts allow, -hosts deny or valid users line in your -smb.conf, or your guest account is not valid. Check what your guest account is using testparm and -temporarily remove any hosts allow, hosts deny, -valid users or invalid users lines. -
-If you get a message “connection refused” response, then the smbd server may -not be running. If you installed it in inetd.conf, then you probably edited -that file incorrectly. If you installed it as a daemon, then check that -it is running, and check that the netbios-ssn port is in a LISTEN -state using netstat -a. -
Note
- - -Some UNIX/Linux systems use xinetd in place of -inetd. Check your system documentation for the location -of the control files for your particular system implementation of -the network super daemon. -
-If you get a message saying “session request failed”, the server refused the -connection. If it says “Your server software is being unfriendly”, then -it's probably because you have invalid command line parameters to smbd, -or a similar fatal problem with the initial startup of smbd. Also -check your config file (smb.conf) for syntax errors with testparm -and that the various directories where Samba keeps its log and lock -files exist. -
-There are a number of reasons for which smbd may refuse or decline -a session request. The most common of these involve one or more of -the smb.conf file entries as shown in . -
-
Example 33.2. Configuration for only allowing connections from a certain subnet

[globals]
...
hosts deny = ALL
hosts allow = xxx.xxx.xxx.xxx/yy
interfaces = eth0
bind interfaces only = Yes
...
-
-In the above, no allowance has been made for any session requests that -will automatically translate to the loopback adapter address 127.0.0.1. -To solve this problem, change these lines as shown in . -
-
Example 33.3. Configuration for allowing connections from a certain subnet and localhost

[globals]
...
hosts deny = ALL
hosts allow = xxx.xxx.xxx.xxx/yy 127.
interfaces = eth0 lo
...
-
- -Another common cause of these two errors is having something already running - -on port 139, such as Samba (smbd is running from inetd already) or -something like Digital's Pathworks. Check your inetd.conf file before trying -to start smbd as a daemon it can avoid a lot of frustration! -
-And yet another possible cause for failure of this test is when the subnet mask -and/or broadcast address settings are incorrect. Please check that the -network interface IP Address/Broadcast Address/Subnet Mask settings are -correct and that Samba has correctly noted these in the log.nmbd file. -
-Run the command: nmblookup -B BIGSERVER __SAMBA__. -You should get back the IP address of your Samba server. -
-If you do not, then nmbd is incorrectly installed. Check your inetd.conf -if you run it from there, or that the daemon is running and listening to udp port 137. -
-One common problem is that many inetd implementations can't take many -parameters on the command line. If this is the case, then create a -one-line script that contains the right parameters and run that from -inetd. -
-Run the command: nmblookup -B ACLIENT `*' -
-You should get the PC's IP address back. If you do not then the client -software on the PC isn't installed correctly, or isn't started, or you -got the name of the PC wrong. -
-If ACLIENT does not resolve via DNS then use the IP address of the -client in the above test. -
-Run the command: nmblookup -d 2 '*' -
-This time we are trying the same as the previous test but are trying -it via a broadcast to the default broadcast address. A number of -NetBIOS/TCP/IP hosts on the network should respond, although Samba may -not catch all of the responses in the short time it listens. You -should see the “got a positive name query response” -messages from several hosts. -
-If this does not give a similar result to the previous test, then -nmblookup isn't correctly getting your broadcast address through its -automatic mechanism. In this case you should experiment with the -interfaces option in smb.conf to manually configure your IP -address, broadcast and netmask. -
-If your PC and server aren't on the same subnet, then you will need to use the --B option to set the broadcast address to that of the PCs subnet. -
-This test will probably fail if your subnet mask and broadcast address are -not correct. (Refer to TEST 3 notes above). -
- -Run the command: smbclient //BIGSERVER/TMP. You should -then be prompted for a password. You should use the password of the account -with which you are logged into the UNIX box. If you want to test with -another account, then add the -U accountname option to the end of -the command line. For example, smbclient //bigserver/tmp -Ujohndoe. -
Note
-It is possible to specify the password along with the username as follows: -smbclient //bigserver/tmp -Ujohndoe%secret. -
-Once you enter the password, you should get the smb> prompt. If you -do not, then look at the error message. If it says “invalid network -name”, then the service tmp is not correctly setup in your smb.conf. -
-If it says “bad password”, then the likely causes are: -
1. - You have shadow passwords (or some other password system) but didn't - compile in support for them in smbd. -
2. - Your valid users configuration is incorrect. -
3. - You have a mixed case password and you haven't enabled the password level option at a high enough level. -
4. - The path line in smb.conf is incorrect. Check it with testparm. -
5. - You enabled password encryption but didn't map UNIX to Samba users. Run: - smbpasswd -a username -
-Once connected, you should be able to use the commands dir, get, -put and so on. Type help command for instructions. You should -especially check that the amount of free disk space shown is correct when you type dir. -
-On the PC, type the command net view \\BIGSERVER. You will -need to do this from within a dos prompt window. You should get back a -list of shares available on the server. -
-If you get a message “network name not found” or similar error, then netbios -name resolution is not working. This is usually caused by a problem in nmbd. -To overcome it, you could do one of the following (you only need to choose one of them): -
1. - Fixup the nmbd installation. -
2. - Add the IP address of BIGSERVER to the wins server box in the - advanced TCP/IP setup on the PC. -
3. - Enable Windows name resolution via DNS in the advanced section of the TCP/IP setup. -
4. - Add BIGSERVER to your lmhosts file on the PC. -
-If you get a message “invalid network name” or -“bad password error”, then apply the -same fixes as for the smbclient -L test above. In -particular, make sure your hosts allow line is correct (see the man pages). -
-Also, do not overlook that fact that when the workstation requests the -connection to the Samba server, it will attempt to connect using the -name with which you logged onto your Windows machine. You need to make -sure that an account exists on your Samba server with that exact same -name and password. -
-If you get a message “specified computer is not receiving requests” or similar, -it probably means that the host is not contactable via TCP services. -Check to see if the host is running TCP wrappers, and if so add an entry in -the hosts.allow file for your client (or subnet, and so on.) -
-Run the command net use x: \\BIGSERVER\TMP. You should -be prompted for a password, then you should get a command completed -successfully message. If not, then your PC software is incorrectly -installed or your smb.conf is incorrect. Make sure your hosts allow -and other config lines in smb.conf are correct. -
-It's also possible that the server can't work out what user name to connect you as. -To see if this is the problem, add the line -user = username to the -[tmp] section of -smb.conf where username is the -username corresponding to the password you typed. If you find this -fixes things, you may need the username mapping option. -
-It might also be the case that your client only sends encrypted passwords -and you have encrypt passwords = no in smb.conf. -Change this to "yes" to fix this. -
-Run the command nmblookup -M testgroup where -testgroup is the name of the workgroup that your Samba server and -Windows PCs belong to. You should get back the IP address of the -master browser for that workgroup. -
-If you do not, then the election process has failed. Wait a minute to -see if it is just being slow, then try again. If it still fails after -that, then look at the browsing options you have set in smb.conf. Make -sure you have preferred master = yes to ensure that -an election is held at startup. -
->From file manager, try to browse the server. Your Samba server should -appear in the browse list of your local workgroup (or the one you -specified in smb.conf). You should be able to double click on the name -of the server and get a list of shares. If you get the error message “invalid password”, - you are probably running Windows NT and it -is refusing to browse a server that has no encrypted password -capability and is in User Level Security mode. In this case, either set -security = server and -password server = Windows_NT_Machine in your -smb.conf file, or make sure encrypt passwords is -set to “yes”. -