Intro Install Configure Troubleshoot Optimize PDC Security

The Unofficial Samba HOWTO

Troubleshooting Samba

David Lechnyr <david@lechnyr.com>
Tue, 13 May 2003 11:32:46 -0700

Is It Not Nifty?

"You're reasoning is excellent -- it's only your basic assumptions that are wrong." -- Anonymous

Samba Checklist

The following items should be consulted, in sequential order, to help diagnose/troubleshoot your Samba server.

Test #1: Ensure basic connectivity

Try pinging your Samba server from itself (i.e., not across the network) using the loopback address, the actual IP address, and DNS name of your Samba server. If you're having problems pinging, verify that the value of /proc/sys/net/ipv4/icmp_echo_ignore_all is set to 0 (at least while debugging) and that you aren't filtering out ICMP traffic (echo request/8, echo reply/0).
Try pinging your Samba server from one of your Windows clients by IP Address and DNS name.
Verify that a firewall is not blocking any traffic from your Windows clients for ports 135/udp, 135/tcp, 137/udp, 138/udp, 139/tcp, 445/tcp
Verify that a firewall is not blocking any icmp traffic from your Windows clients for echo-reply (type 0), destination-unreachable (type 3), source quench (type 4), echo request (type 8), time exceeded (type 11), and parameter problem (type 12).
If you still can't get any basic connectivity from these steps, Samba is the least of your worries. Time to break out a packet sniffer (ethereal, tcpdump, etc) and determine the cause.

Test #2: Proper Samba configuration

Make sure you are running the latest stable version of Samba. As of this writing, that would be Samba 2.2.8a.
Verify that your /usr/local/samba/lib/smb.conf file exists and run `testparm` against it to validate its syntax.
Verify that your smb.conf file includes the parameter "encrypt passwords = yes" unless you are using Win95/Win95a or have disabled encrypted passwords in your other Windows clients (not a good idea).
Verify that your smb.conf file includes the parameter "wins support = yes" and that your client is set to use the Samba server as its wins server.

Test #3: Daemons

Bump up your Samba log to level 3, stop and then restart both smbd and nmbd.

Verify that smbd is running by examining your Samba logfile for something like:

lib/interface.c:add_interface(81)
  added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
smbd/server.c:open_sockets(215)
  waiting for a connection

Verify that nmbd is running by examining your Samba logfile for something like:

nmbd/nmbd.c:main(794)
Netbios nameserver version x started.
Copyright Andrew Tridgell and the Samba Team 1994-2002
nmbd/nmbd.c:main(832)
  Becoming a daemon.
lib/interface.c:add_interface(81)
  added interface ip=192.168.1.1 bcast=192.168.1.255 nmask=255.255.255.0
  nmbd/nmbd_subnetdb.c:make_subnet(192)
  making subnet name:192.168.1.1 Broadcast address:192.168.1.255 Subnet mask:255.255.255.0
nmbd/nmbd_subnetdb.c:make_subnet(192)
  UNICAST_SUBNET Broadcast address:0.0.0.0 Subnet mask:0.0.0.0
nmbd/nmbd_subnetdb.c:make_subnet(192)
  making subnet name:REMOTE_BROADCAST_SUBNET Broadcast address:0.0.0.0 Subnet mask:0.0.0.0

Test #4: NetBIOS Name Resolution

From the Samba box itself, verify that you can query the nmbd server for its own NetBIOS name:
```
nmblookup -B example-server __SAMBA__
```
From the Samba box itself, verify that you can query the nmbd server for any NetBIOS client name:
```
nmblookup -B example-client '*'
```
From the Samba box itself, verify that you can query your subnet for any NetBIOS client name:
```
nmblookup -d 2 '*'
```

Test #5: Listing Network Shares

From the Samba box itself, try generating a list of valid shares:
```
smbclient -L example-server
```
From a Windows client, try generating a list of valid shares:
```
NET VIEW \\example-server
```
From the Samba box, verify that you can query the Domain Master Browser (probably itself) for the Samba server's IP address:
```
nmblookup -M example-wkgrp
```
From a Windows client, verify that you can view a list of available shares via the Network Neighborhood.

Test #6: Establishing a Session

From the Samba box, try connecting to one of its own shares:
```
smbclient //example-server/tmp -Uusername
```
From a Windows Client, try connecting to one of the shares:
```
NET USE X: \\example-server\tmp
```

If All Else Fails...

Again, don't panic. The solution is there; you just have to do the work to determine the cause of the problem. If you're certain you've exhausted your options and have read, followed and addressed the above tests, you can always post your question to one of the Samba mailing lists located at http://lists.samba.org. If you haven't addressed and resolved the above tests, don't be suprised if nobody answers your questions ;-)

Samba Logfile Settings

To stand a chance of determining the answer to the classic question of "what went wrong" you'll need to understand how to enable Samba logging and how to decipher its cryptic log messages as well. First, here are a few of the smb.conf(5) parameters that directly affect logging:

log level = 3
Enables logging at the level of detail specified by an integer. The default is 0; to gather anything meaningful you'll want to use at least 1. A level of 3 is useful for brief, problem-specific troubleshooting. A level of 10 is typically used for diagnosing the SMB protocol.
debug hires timestamp = yes
Use microseconds, instead of seconds, in printing out the timestamps in the log messages. Chances are you won't need this unless you're doing massive debugging.
debug pid = yes
Add the process-id of the specific samba process to the logfiles. This can help you if you're trying to determing which process outputs which log message. Requires the debug timestamp parameter to be enabled as well.
debug timestamp = no
Actually, this is the default setting and is generally quite useful. You might want to set this to 'no' if you're running at a high debug level and don't want the timestamps to be printed out as well, which can be distracting. It's also helpful when comparing logfiles with diff(1), although one caveat is that you don't get the name and function of the code that is generating the message (catch-22).
debug uid = yes
Print out the effective uid (euid), effective gid (egid), uid and gid along with the the timestamp message headers in the log files. Since Samba runs as root and at other times runs as the connected user, this can be helpful for certain cases. Requires the debug timestamp parameter to be enabled as well.
debug level
This is a synonym for log level
log file = %m.log
The name and location of the Samba log file. The '%m' allows you to log machine-specific connection information in different log files.
max log size = 5000
This option allows you to specify the maximum size the log files can grow to. Files exceeding this value (in kilobytes) are renamed with a '.old' extension. Setting this value to '0' disables the log limit.

Marshalling/Unmarshalling

If you've ever seen something similar to the following in a logfile before, you've probably been a bit perplexed:

rpc_server/srv_samr.c:api_samr_set_userinfo(670)
api_samr_set_userinfo: Unable to unmarshall SAMR_Q_SET_USERINFO.

By itself, marshalling means to take variable data, serialize (i.e., place in order) it, and send it in transmittable form across a network or to a file. Unmarshalling is the reverse process. In DCE/RPC terminology, marshalling and unmarshalling refers to the flattening and unpacking of a data stream between a client and server. A rough approximation of this process could be described as:

Both computers negotiate a 'set of functions' and a 'data format' that is common to both of them, so that they can communicate using the same language
The receiving computer authenticates the caller (if required)
Both computers negotiate the security (if required)
The calling computer marshalls (flattens) the data into a 'continuous data stream' and sends it to the receiving computer
The receiving computer unmarshalls (unpacks) the data stream it has just received and processes the data
The receiving computer then marshalls the results of processing the data and passes them back to the caller
The calling computer unmarshalls the results and submits the received data to the original function call that started this process in the first place

Using tcpdump

When troubleshooting your Samba server with tcpdump, the best use is something like:

tcpdump -ln -vv host 192.168.1.1 | tee tcpdump.samba

While analyzing your data, you may come across an error message similar to:

WARNING: Short packet. Try increasing the snap length

This actually has nothing to do with Samba, however it comes up a lot. It's tcpdump itself complaining about snaplen (-s <number>) being shorter than at least one packet during its capture. Again, it has nothing to do with Samba; it's harmless and can be ignored.

Troubleshooting Example

This is, perhaps, the best example of a real-life approach towards troubleshooting, which was posted on samba-technical:

From: jht@samba.org (John H Terpstra)
Subject: Re: Eureka! Slow Samba transfers resolved!
Date: Sun, 19 Jan 2003 21:17:39 +0000 (UTC)

On Sun, 19 Jan 2003, Jean-Marie White wrote:

> I just spent so much time troubleshooting why
> *some types* of samba transfers were slow that I thought
> I would share how I resolved the problem.
>
> This problem had been going on for ever. As far as I could
> tell, it was only happening with winamp (MP3 player). All
> my MP3s reside on my Linux box and I was trying to access
> them from my PC running Windows 2000. What was throwing me
> for a loop was that Windows Media player seemed to be more
> successful at playing them ! What would happen is that Winamp
> would freeze and nothing would happen. I had then decided to
> just copy my MP3s back to my PC.
>
> Then, last night I started using FrontPage for some reason or
> another; and when I tried to publish my web site to my Linux
> box, then behavior I had observed with my MP3s started
> plaguing FrontPage as well.
>
> I went through all the troubleshooting guides, learned about
> every samba configuration options: I was able to successfully
> transfer a 100M file in either direction (linux->pc or
> pc->linux) using the File Explorer without any problem.
> But I just couldn't for the life of me understand why
> winamp and FrontPage were having problems.
>
> Then I decided to use ethereal and try and understand what
> was actually happening on the wire. I realized that when
> winamp or FrontPage were trying to transfer files, Linux
> was ending up retransmitting the same frame over and over
> without ever receiving a TCP acknowledgment for it. Then the
> PC would eventually tear down the session and re-establish the
> session and restart the transfer. An article that I read
> http://www.dd.iij4u.or.jp/~okuyamak/Documents/tuning.english.html
> talking about how Windows could mysteriously drop packets,
> and I started thinking that maybe packets were being lost
> due to some hardware problem.
>
> So I looked at my PC network card configuration (Linksys LNE
> 100TX Fast Ethernet) and saw that the "Connection Type" was
> set to auto-detect. (My PC is connected to my Linux box through
> a Linksys 8-port Workgroup Switch - Ehterfast 10/100) So I
> thought, maybe having to ends that "auto-detect" each
> others speed is not good. So I changed my "Connection Type"
> to 100 TX Full Duplex and VOILA! All my problems solved, winamp
> is happily playing away and FrontPage can publish my whole web
> site in seconds.

The problem and solution you describe here is very common. It also happens to be the least expected,
thus we have had many queries on this list regarding samba problems that were in fact hardware issues like yours.

Thank you for sharing your experience. This is valuable feedback.

John H Terpstra
Email: jht@samba.org

This document was lovingly handcrafted on a Dell Latitude C400 laptop running Slackware Linux 9.0, in case anyone asks.

Copyright © 2003 David Lechnyr <david@lechnyr.com>
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation. A copy of the license is available at http://www.gnu.org/licenses/fdl.txt.

Intro Install Configure Troubleshoot Optimize PDC Security