diff options
Diffstat (limited to 'docs-xml/Samba3-HOWTO/TOSHARG-Diagnosis.xml')
| -rw-r--r-- | docs-xml/Samba3-HOWTO/TOSHARG-Diagnosis.xml | 603 |
1 files changed, 603 insertions, 0 deletions
diff --git a/docs-xml/Samba3-HOWTO/TOSHARG-Diagnosis.xml b/docs-xml/Samba3-HOWTO/TOSHARG-Diagnosis.xml new file mode 100644 index 0000000000..951c879b49 --- /dev/null +++ b/docs-xml/Samba3-HOWTO/TOSHARG-Diagnosis.xml @@ -0,0 +1,603 @@ +<?xml version="1.0" encoding="iso-8859-1"?> +<!DOCTYPE chapter PUBLIC "-//Samba-Team//DTD DocBook V4.2-Based Variant V1.0//EN" "http://www.samba.org/samba/DTD/samba-doc"> +<chapter id="diagnosis"> +<chapterinfo> + &author.tridge; + &author.jelmer; + &author.danshearer; + <pubdate>Wed Jan 15</pubdate> +</chapterinfo> + +<title>The Samba Checklist</title> + +<sect1> +<title>Introduction</title> + +<para> +<indexterm><primary>validate</primary></indexterm> +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. +</para> + +<para> +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: there +have been some instances when continuing with the tests has helped +to solve a problem. +</para> + +<para> +If you send one of the Samba mailing lists an email saying, <quote>It does not work,</quote> +and you have not followed this test procedure, you should not be surprised +if your email is ignored. +</para> + +</sect1> + +<sect1> +<title>Assumptions</title> + +<para> +In all of the tests, it is assumed you have a Samba server called +BIGSERVER and a PC called ACLIENT, both in workgroup TESTGROUP. +</para> + +<para> +The procedure is similar for other types of clients. +</para> + +<para> +It is also assumed you know the name of an available share in your +&smb.conf;. I for our examples this share is called <smbconfsection name="tmp"/>. +You can add a <smbconfsection name="tmp"/> share like this by adding the +lines shown in <link linkend="tmpshare">the next example</link>. +</para> + +<example id="tmpshare"> +<title>smb.conf with [tmp] Share</title> +<smbconfblock> +<smbconfsection name="[tmp]"/> +<smbconfoption name="comment">temporary files </smbconfoption> +<smbconfoption name="path">/tmp</smbconfoption> +<smbconfoption name="read only">yes</smbconfoption> +</smbconfblock> +</example> + +<note><para> +These tests assume version 3.0.0 or later of the Samba suite. +Some commands shown did not exist in earlier versions. +</para></note> + +<para> +<indexterm><primary>error messages</primary></indexterm> +<indexterm><primary>name resolution</primary></indexterm> +<indexterm><primary>/etc/resolv.conf</primary></indexterm> +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 <filename>/etc/resolv.conf</filename> +file points to name servers that really do exist. +</para> + +<para> +<indexterm><primary>DNS server access</primary></indexterm> +<indexterm><primary>name resolution</primary></indexterm> +<indexterm><primary>dns proxy</primary></indexterm> +<indexterm><primary>testparm</primary></indexterm> +Also, if you do not have DNS server access for name resolution, please check +that the settings for your &smb.conf; file results in <parameter>dns proxy = no</parameter>. The +best way to check this is with <command>testparm smb.conf</command>. +</para> + + +<para> +<indexterm><primary>log files</primary></indexterm> +<indexterm><primary>tail</primary></indexterm> +<indexterm><primary>/usr/local/samba/var</primary></indexterm> +<indexterm><primary>/var/log/samba</primary></indexterm> +<indexterm><primary>log files</primary><secondary>monitoring</secondary></indexterm> +It is helpful to monitor the log files during testing by using the +<command>tail -F log_file_name</command> 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 +<filename>/usr/local/samba/var</filename>. Also, connection logs from +machines can be found here or possibly in <filename>/var/log/samba</filename>, +depending on how or if you specified logging in your &smb.conf; file. +</para> + +<para> +If you make changes to your &smb.conf; file while going through these test, +remember to restart &smbd; and &nmbd;. +</para> + +</sect1> + +<sect1> +<title>The Tests</title> +<procedure> +<title>Diagnosing Your Samba Server</title> + + +<step performance="required"> +<para> +<indexterm><primary>testparm</primary></indexterm> +In the directory in which you store your &smb.conf; file, run the command +<command>testparm smb.conf</command>. If it reports any errors, then your &smb.conf; +configuration file is faulty. +</para> + +<note><para> +<indexterm><primary>/etc/samba</primary></indexterm> +<indexterm><primary>/usr/local/samba/lib</primary></indexterm> +Your &smb.conf; file may be located in <filename>/etc/samba</filename> +or in <filename>/usr/local/samba/lib</filename>. +</para></note> +</step> + +<step performance="required"> +<para> +<indexterm><primary>ping</primary></indexterm> +Run the command <command>ping BIGSERVER</command> from the PC and +<command>ping ACLIENT</command> from the UNIX box. If you do not get a valid response, +then your TCP/IP software is not correctly installed. +</para> + +<para> +You will need to start a <quote>DOS prompt</quote> window on the PC to run ping. +</para> + +<para> +<indexterm><primary>/etc/hosts</primary></indexterm> +<indexterm><primary>DNS</primary></indexterm> +<indexterm><primary>/etc/resolv.conf</primary></indexterm> +If you get a message saying <quote><errorname>host not found</errorname></quote> or a similar message, then +your DNS software or <filename>/etc/hosts</filename> file is not correctly set up. If using DNS, check that +the <filename>/etc/resolv.conf</filename> has correct, current, entries in it. 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. +</para> + +<para> +<indexterm><primary>firewall</primary></indexterm> +<indexterm><primary>iptables</primary></indexterm> +<indexterm><primary>ipchains</primary></indexterm> +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 <command>ipchains</command> +or <command>iptables</command>). +</para> + +<note> +<para> +Modern Linux distributions install ipchains/iptables by default. +This is a common problem that is often overlooked. +</para> +</note> + +<para> +<indexterm><primary>iptables</primary></indexterm> +<indexterm><primary>ipchains</primary></indexterm> +If you wish to check what firewall rules may be present in a system under test, simply run +<command>iptables -L -v</command>, or if <parameter>ipchains</parameter>-based firewall rules are in use, +<command>ipchains -L -v</command>. +</para> + +<para> +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: +<screen> +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 destination +</screen> +</para> + +</step> + +<step performance="required"> +<para> +Run the command <command>smbclient -L BIGSERVER</command> +on the UNIX box. You should get back a list of available shares. +</para> + +<para> +<indexterm><primary>bad password</primary></indexterm> +<indexterm><primary>hosts allow</primary></indexterm> +<indexterm><primary>hosts deny</primary></indexterm> +<indexterm><primary>valid users</primary></indexterm> +<indexterm><primary>guest account</primary></indexterm> +<indexterm><primary>invalid users</primary></indexterm> +If you get an error message containing the string <quote>bad password</quote>, then +you probably have either an incorrect <parameter>hosts allow</parameter>, +<parameter>hosts deny</parameter>, or <parameter>valid users</parameter> line in your +&smb.conf;, or your guest account is not valid. Check what your guest account is using &testparm; and +temporarily remove any <parameter>hosts allow</parameter>, <parameter>hosts deny</parameter>, +<parameter>valid users</parameter>, or <parameter>invalid users</parameter> lines. +</para> + +<para> +<indexterm><primary>inetd.conf</primary></indexterm> +If you get a message <literal>connection refused</literal> response, then the <command>smbd</command> server may +not be running. If you installed it in <filename>inetd.conf</filename>, 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 <command>netstat -a</command>. +</para> + +<note><para> +<indexterm><primary>inetd</primary></indexterm> +<indexterm><primary>xinetd</primary><see>inetd</see></indexterm> +Some UNIX/Linux systems use <command>xinetd</command> in place of +<command>inetd</command>. Check your system documentation for the location +of the control files for your particular system implementation of +the network super daemon. +</para></note> + +<para> +If you get a message saying <literal>session request failed,</literal> the server refused the +connection. If it says <quote>Your server software is being unfriendly,</quote> 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. +</para> + +<para> +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 <link linkend="modif1">the next example</link>. +</para> + + +<example id="modif1"> +<title>Configuration for Allowing Connections Only from a Certain Subnet</title> +<smbconfblock> +<smbconfsection name="[globals]"/> +<smbconfoption name="hosts deny">ALL</smbconfoption> +<smbconfoption name="hosts allow">xxx.xxx.xxx.xxx/yy</smbconfoption> +<smbconfoption name="interfaces">eth0</smbconfoption> +<smbconfoption name="bind interfaces only">Yes</smbconfoption> +</smbconfblock> +</example> + +<para> +<indexterm><primary>loopback adapter</primary></indexterm> +In <link linkend="modif1">Configuration for Allowing Connections Only from a Certain Subnet</link>, 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 <link linkend="modif2">the following +example</link>. +</para> + +<example id="modif2"> +<title>Configuration for Allowing Connections from a Certain Subnet and localhost</title> +<smbconfblock> +<smbconfsection name="[globals]"/> +<smbconfoption name="hosts deny">ALL</smbconfoption> +<smbconfoption name="hosts allow">xxx.xxx.xxx.xxx/yy 127.</smbconfoption> +<smbconfoption name="interfaces">eth0 lo</smbconfoption> +</smbconfblock> +</example> + +<para> +<indexterm><primary>inetd</primary></indexterm> +<indexterm><primary>smbclient</primary></indexterm> +Another common cause of these two errors is having something already running on port <constant>139</constant>, +such as Samba (&smbd; is running from <application>inetd</application> already) or Digital's Pathworks. Check +your <filename>inetd.conf</filename> file before trying to start &smbd; as a daemon &smbmdash; it can avoid a +lot of frustration! +</para> + +<para> +<indexterm><primary>subnet mask</primary></indexterm> +<indexterm><primary>broadcast address</primary></indexterm> +<indexterm><primary>log.nmbd</primary></indexterm> +<indexterm><primary>network interface</primary></indexterm> +<indexterm><primary>IP address</primary></indexterm> +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 <filename>log.nmbd</filename> file. +</para> + +</step> + +<step performance="required"> + +<para> +<indexterm><primary>nmblookup</primary></indexterm> +Run the command <command>nmblookup -B BIGSERVER __SAMBA__</command>. +You should get back the IP address of your Samba server. +</para> + +<para> +<indexterm><primary>inetd.conf</primary></indexterm> +<indexterm><primary>nmbd</primary></indexterm> +<indexterm><primary>port 137</primary></indexterm> +If you do not, then &nmbd; is incorrectly installed. Check your <filename>inetd.conf</filename> +if you run it from there, or that the daemon is running and listening to UDP port 137. +</para> + +<para> +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. +</para> + +</step> + +<step performance="required"> + +<para> +<indexterm><primary>nmblookup</primary></indexterm> +Run the command <command>nmblookup -B ACLIENT `*'</command>. +</para> + +<para> +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. +</para> + +<para> +If ACLIENT does not resolve via DNS, then use the IP address of the +client in the above test. +</para> + +</step> + +<step performance="required"> + +<para> +Run the command <command>nmblookup -d 2 `*'</command>. +</para> + +<para> +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 <literal>got a positive name query response</literal> +messages from several hosts. +</para> + +<para> +<indexterm><primary>nmblookup</primary></indexterm> +If this does not give a result similar 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 <smbconfoption +name="interfaces"/> option in &smb.conf; to manually configure your IP address, broadcast, and netmask. +</para> + +<para> +If your PC and server aren't on the same subnet, then you will need to use the +<option>-B</option> option to set the broadcast address to that of the PC's subnet. +</para> + +<para> +This test will probably fail if your subnet mask and broadcast address are +not correct. (Refer to test 3 notes above). +</para> + +</step> + +<step performance="required"> + + +<para> +<indexterm><primary>smbclient</primary></indexterm> +Run the command <command>smbclient //BIGSERVER/TMP</command>. 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 <option>-U accountname</option> option to the end of +the command line &smbmdash; for example, <command>smbclient //bigserver/tmp -Ujohndoe</command>. +</para> + +<note><para> +It is possible to specify the password along with the username as follows: +<command>smbclient //bigserver/tmp -Ujohndoe%secret</command>. +</para></note> + +<para> +Once you enter the password, you should get the <prompt>smb></prompt> prompt. If you +do not, then look at the error message. If it says <quote><errorname>invalid network +name,</errorname></quote> then the service <smbconfsection name="tmp"/> is not correctly set up in your &smb.conf;. +</para> + +<para> +If it says <quote><errorname>bad password,</errorname></quote> then the likely causes are: +</para> + +<orderedlist> +<listitem> + <para> + You have shadow passwords (or some other password system) but didn't + compile in support for them in &smbd;. + </para> +</listitem> + +<listitem> + <para> + Your <smbconfoption name="valid users"/> configuration is incorrect. + </para> +</listitem> + +<listitem> + <para> + You have a mixed-case password and you haven't enabled the <smbconfoption name="password level"/> option at a high enough level. + </para> +</listitem> + +<listitem> + <para> + The <smbconfoption name="path"/> line in &smb.conf; is incorrect. Check it with &testparm;. + </para> +</listitem> + +<listitem> + <para> + You enabled password encryption but didn't map UNIX to Samba users. Run + <command>smbpasswd -a username</command> + </para> +</listitem> +</orderedlist> + +<para> +<indexterm><primary>dir</primary></indexterm> +<indexterm><primary>get</primary></indexterm> +<indexterm><primary>put</primary></indexterm> +<indexterm><primary>help command</primary></indexterm> +Once connected, you should be able to use the commands <command>dir</command>, <command>get</command>, +<command>put</command>, and so on. Type <command>help command</command> for instructions. You should +especially check that the amount of free disk space shown is correct when you type <command>dir</command>. +</para> + +</step> + +<step performance="required"> + +<para> +<indexterm><primary>net view</primary></indexterm> +On the PC, type the command <command>net view \\BIGSERVER</command>. You will +need to do this from within a DOS prompt window. You should get back a +list of shares available on the server. +</para> + +<para> +<indexterm><primary>nmbd</primary></indexterm> +If you get a message <literal>network name not found</literal> or similar error, then NetBIOS +name resolution is not working. This is usually caused by a problem in <command>nmbd</command>. +To overcome it, you could do one of the following (you only need to choose one of them): +</para> + +<orderedlist> +<listitem><para> + Fix the &nmbd; installation. +</para></listitem> + +<listitem><para> + Add the IP address of BIGSERVER to the <command>wins server</command> box in the + advanced TCP/IP setup on the PC. +</para></listitem> + +<listitem><para> + Enable Windows name resolution via DNS in the advanced section of the TCP/IP setup. +</para></listitem> + +<listitem><para> + Add BIGSERVER to your lmhosts file on the PC. +</para></listitem> +</orderedlist> + +<para> +If you get a message <quote><errorname>invalid network name</errorname></quote> or +<quote><errorname>bad password error,</errorname></quote> then apply the +same fixes as for the <command>smbclient -L</command> test. In +particular, make sure your <command>hosts allow</command> line is correct (see the man pages). +</para> + +<para> +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. +</para> + +<para> +If you get a message <quote><errorname>specified computer is not receiving requests</errorname></quote> or similar error, +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 <filename>hosts.allow</filename> file for your client (or subnet, and so on.) +</para> + +</step> + +<step performance="required"> + +<para> +Run the command <command>net use x: \\BIGSERVER\TMP</command>. You should +be prompted for a password, then you should get a <computeroutput>command completed +successfully</computeroutput> message. If not, then your PC software is incorrectly +installed or your &smb.conf; is incorrect. Make sure your <parameter>hosts allow</parameter> +and other config lines in &smb.conf; are correct. +</para> + +<para> +It's also possible that the server can't work out what username to connect you as. +To see if this is the problem, add the line +<smbconfoption name="user">username</smbconfoption> to the +<smbconfsection name="[tmp]"/> section of +&smb.conf; where <parameter>username</parameter> is the +username corresponding to the password you typed. If you find this +fixes things, you may need the username mapping option. +</para> + +<para> +It might also be the case that your client only sends encrypted passwords +and you have <smbconfoption name="encrypt passwords">no</smbconfoption> in &smb.conf;. +Change this setting to `yes' to fix this. +</para> + +</step> + +<step performance="required"> + +<para> +Run the command <command>nmblookup -M <parameter>testgroup</parameter></command> where +<parameter>testgroup</parameter> 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. +</para> + +<para> +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 <smbconfoption name="preferred master">yes</smbconfoption> to ensure that +an election is held at startup. +</para> + +</step> + +<step performance="required"> + +<para> +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 <quote>invalid password,</quote> + 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 +<smbconfoption name="security">server</smbconfoption> and +<smbconfoption name="password server">Windows_NT_Machine</smbconfoption> in your +&smb.conf; file or make sure <smbconfoption name="encrypt passwords"/> is +set to <quote>yes</quote>. +</para> + +</step> +</procedure> +</sect1> + +</chapter> |