Troubleshooting Samba problems

Here is a relevant quote from Sean A. Walberg tutorial published at IBM Developer Works ( Configure Samba, Apr 27,  2011 ). Generally you should check firewall first and for the period of troubleshooting disable it.

 Apr 27, 2011 | developerWorks

Troubleshooting Samba problems

Samba is not immune to problems. Sometimes, these problems are caused by the system administrator; sometimes they're caused by the user. Your job as the system administrator is to figure out where the problem lies, then how to solve it.

Testing the configuration file

If Samba won't start or you want to check your configuration file for correctness, then the testparm utility will help. This utility checks smb.conf for correctness. Listing 4 shows the result of testparm if there is an error.

Listing 4. Using testparm on an incorrect smb.conf file
 

# testparm Load smb config files from /etc/samba/smb.conf Unknown parameter encountered: "hide dto files" Ignoring unknown parameter "hide dto files" Processing section "[homes]" Processing section "[printers]" Processing section "[public]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions [global] workgroup = MYGROUP server string = Samba Server Version %v passdb backend = tdbsam log file = /var/log/samba/log.%m max log size = 50 cups options = raw << rest of the output omitted >>

 

The output of testparm starts with the location of the files. If you want to specify a different file, pass the name of the file on the command line, as in this example:

testparm /home/me/smb.conf

Statements

       workgroup = MYGROUP
        server string = Samba Server Version %v

Mean that the server will be visible something like  homes on Version 3.6.1-75.fc16 (Plex755)

Next, testparm is complaining about an invalid parameter called hide dto files. This parameter should really be hide dot files.

After processing the configuration file, you are given some information about the server's role and a condensed version of the configuration file. This version has the comments stripped out and is consistently formatted, so you will sometimes catch errors here that you missed while browsing smb.conf in a text editor.

You should run testparm on your configuration file after making changes. Samba ignores most typographical errors in the configuration files and doesn't always write messages to the console when starting up. It's likely that you won't catch these types of mistakes until something isn't working properly. Testparm alerts you to any typos in smb.conf.

By default, testparm only shows you the configuration as entered in smb.conf. If you suspect that you are using a default value somewhere, you can use the -v option to force testparm also to show default values.

Another use of testparm is to limit the output to a single section or parameter. Listing 5 shows how to use testparm to see the value of the security mask option.

Listing 5. Limiting testparm to a single parameter
 

# testparm -s --parameter-name "security mask" Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[public]" Loaded services file OK. 0777

 

In Listing 5, the -s parameter stops testparm from waiting for user input in between parsing smb.conf and displaying it to the screen. Using --parameter name "security mask" asks for the value of security mask. The result is 0777, which is the default value. In this mode, it is not necessary to specify -v to show default values.

Connecting as a client

In lieu of going to a user's desktop and trying things out yourself, you can do a great deal of testing from the command line at your own desk. The first and easiest test is to make sure that you can connect to the Samba port. The easiest way to do this is with the telnet command, which is shown in Listing 6.

Listing 6. Testing connectivity with telnet
 

# telnet bob 139 Trying 192.168.1.134... telnet: connect to address 192.168.1.134: Connection refused

 

In Listing 6, the root user is connecting to the server bob on port 139. You could also use port 445 to test for the direct-hosted SMB port. The result is Connection refused, which indicates either that the daemon isn't listening on that address or that a firewall is blocking the connection. Other results, such as No route to host or Connection timed out, can mean the same thing.

Clients generally connect to a server with a name, not an IP address. If you use telnet to connect to the server by name rather than IP address, pay special attention to the IP address returned. In the example above, the server (bob) was resolved to 192.168.1.134. Sometimes, you can have errors in your DNS records that result in the clients connecting to the wrong address.

If you are not using DNS for Windows name resolution, you can use the nmblookup command to perform a NetBIOS name lookup. Listing 7 shows a query for the bob server.

Listing 7. Performing a NetBIOS name query for bob
 

# nmblookup bob querying bob on 192.168.1.255 192.168.1.138 bob<00>

 

According to Listing 7, the server bob is at 192.168.1.138, not 192.168.1.134, as you saw in Listing 6. This result points to a problem with DNS, especially if ports 139 and 445 are responsive on 192.168.1.138.

Another test is to see whether the configuration file denies access to a particular host. Testparm is used again in Listing 8.

Listing 8. Checking access with testparm
 

# testparm /etc/samba/smb.conf seanspc 192.168.1.147 Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[public]" Loaded services file OK. Server role: ROLE_STANDALONE Deny connection from seanspc (192.168.1.147) to homes Deny connection from seanspc (192.168.1.147) to printers Deny connection from seanspc (192.168.1.147) to public

Firewalls problems or application problems?

There are many ways to block a connection to a host, but all the options can be grouped into two categories: network and application. By blocking at the network layer, either on a firewall or using a host-based firewall like iptables, you will see that the telnet connection shown in Listing 6 is refused or times out. This is because the packet never makes it to the Samba application.

If Samba is configured not to allow connections from a particular host, you will see that the telnet connection succeeds, but any client access is greeted with an error. This is because the packet is read by the application but doesn't like the IP address or hostname and sends an application-level error. Without accepting the packet at the application layer, Samba can't know whether the IP address is acceptable.

In Listing 8, three items are passed to testparm:

• The path to the Samba configuration file
• The NetBIOS name of the machine to test
• The IP address of the machine to test

The output from Listing 8 shows that the machine in question is denied access to all shares. When using testparm in this mode, the utility does not actually connect as that machine. Instead, testparm processes the configuration file to see whether the access would be allowed.

If all the tests up to now succeed, you can attempt to make a client connection using the smbclient utility. The first test is to attempt to browse the share list, which is shown in Listing 9.

Listing 9. Showing a machine's shares
 

[sean@bob source3]$ smbclient -L '\\bob' Enter sean's password: Anonymous login successful Domain=[MYGROUP] OS=[Unix] Server=[Samba 3.5.6-69.fc13] Sharename Type Comment --------- ---- ------- extdrive Disk Sean Walberg's iMac Disk timemachine Disk IPC$ IPC IPC Service (Samba Server Version 3.5.6-69.fc13) test Printer test Downstairs_Laser Printer HP 6L Cups-PDF Printer Cups-PDF Anonymous login successful Domain=[MYGROUP] OS=[Unix] Server=[Samba 3.5.6-69.fc13] Server Comment --------- ------- BOB Samba Server Version 3.5.6-69.fc13 Workgroup Master --------- ------- MYGROUP BOB WORK SWALBERG-XPLT WORKGROUP IMAC-1FC525

 

In Listing 9, the user is requesting a list of shares with the -L parameter on the server called bob. The server name is prefixed with two backslashes (\\), because it is a Universal Naming Convention (UNC) path. Be careful about your choice of single versus double quotation marks, as well. Single quotation marks interpolate and see the backslashes as escape characters.

If your server has more security set up, you may need to pass the name of the user or the domain with the -W and -U parameters, respectively.

Finally, you can try to connect to a share by omitting the -L parameter and specifying a full UNC path to the share. Listing 10 shows the client connecting to a server using a different workgroup and user name.

Listing 10. Connecting to a share with a different user name and domain
 

[sean@bob source3]$ smbclient '\\swalberg-xplt\photos' -U swalberg -W WORK Enter swalberg's password: Domain=[WORK] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager] smb: \> dir . D 0 Thu Jan 6 11:39:50 2011 .. D 0 Thu Jan 6 11:39:50 2011 << files omitted >> 38156 blocks of size 4194304. 2938 blocks available smb: \>>

 

If these tests pass, you can be reasonably certain that the problem is not with the Samba configuration but somewhere between the client and the server or something on the client itself. You look at the logs in the next section, which offer some clues as to where the problem lies.

O'Reilly book Using Samba(1991) is available online.  Here is a quote about how to test Samba daemon after the installation:

Testing the Samba Daemons

We're nearly done with the Samba server setup. All that's left to do is to make sure that everything is working as we think it should. A convenient way to do this is to use the smbclient program to examine what the server is offering to the network. If everything is set up properly, you should be able to do the following:

$ smbclient -L localhost -N

Anonymous login successful
Domain=[GARDEN] OS=[Unix] Server=[Samba 3.0.22]

        Sharename      Type      Comment
        ---------      ----      -------
        test           Disk      For testing 
 
 only, please
        IPC$           IPC       IPC Service (Samba 3.0.22)
        ADMIN$         Disk      IPC Service (Samba 3.0.22)

        Server               Comment
        ---------            -------
        RAIN                 Samba 3.0.22

        Workgroup            Master
        ---------            -------
        GARDEN               RAIN

This example used an anonymous connection. But because we've already added a Samba account for lizard, we can also connect to and browse a specific share. Being greeted by the smb: \> is an indication of success.

$ smbclient //localhost/test -U lizard
Password: <enter password>
Domain=[GARDEN] OS=[Unix] Server=[Samba 3.0.22]
smb: \>

If there is a problem, don't panic! Try to start the daemons manually, and check the system output or the debug files at /usr/local/samba/var/log.smbd to see if you can determine what happened. If you think it might be a more serious problem, skip to Chapter 12 for help on troubleshooting the Samba daemons.

If it worked, congratulations! You now have successfully set up the Samba server with a disk share. It's a simple one, but we can use it to set up and test the Windows clients in the next chapter. Then we will start making it more interesting by adding services such as home directories, printers, and security, and by seeing how to integrate the server into a larger Windows domain.

Chapter 9 covers troubleshooting.[Chapter 9] Troubleshooting Samba

The Tool Bag

Sometimes Unix seems to be made up of a handful of applications and tools. There are tools to troubleshoot tools. And of course, there are several ways to accomplish the same task. When you are trying to solve a problem related to Samba, a good plan of attack is to check the following:

1. Samba logs

2. Fault tree

3. Unix utilities

4. Samba test utilities

5. Documentation and FAQs

6. Searchable archives

7. Samba newsgroups

Let's go over each of these one by one in the following sections.

9.1.1 Samba Logs

Your first line of attack should always be to check the log files. The Samba log files can help diagnose the vast majority of the problems that beginning to intermediate Samba administrators are likely to face. Samba is quite flexible when it comes to logging. You can set up the server to log as little or as much as you want. Substitution variables that allow you to isolate individual logs for each machine, share, or combination thereof.

By default, logs are placed in samba_directory /var/smbd.log and samba_directory /var/nmbd.log, where samba_directory is the location where Samba was installed (typically, /usr/local/samba). As we mentioned in Chapter 4, Disk Shares , you can override the location and name using the log file configuration option in smb.conf. This option accepts all of the substitution variables mentioned in Chapter 2, Installing Samba on a Unix System, so you could easily have the server keep a separate log for each connecting client by specifying the following in the [global] section of smb.conf :

log file = %m.log

Alternatively, you can specify a log directory to use with the -l flag on the command line. For example:

smbd -l /usr/local/var/samba

Another useful trick is to have the server keep a log for each service (share) that is offered, especially if you suspect a particular share is causing trouble. Use the %S variable to set this up in the [global] section of the configuration file:

log file = %S.log

9.1.1.1 Log levels

The level of logging that Samba uses can be set in the smb.conf file using the global log level or debug level option; they are equivalent. The logging level is an integer which ranges from 0 (no logging), and increases the logging to voluminous by log level = 3. For example, let's assume that we are going to use a Windows client to browse a directory on a Samba server. For a small amount of log information, you can use log level = 1, which instructs Samba to show only cursory information, in this case only the connection itself:

105/25/98 22:02:11 server (192.168.236.86) connect to service public as user pcguest (uid=503,gid=100) (pid 3377) 

Higher debug levels produce more detailed information. Usually you won't need any more than level 3; this is more than adequate for most Samba administrators. Levels above 3 are for use by the developers and dump enormous amounts of cryptic information.

Here is example output at levels 2 and 3 for the same operation. Don't worry if you don't understand the intricacies of an SMB connection; the point is simply to show you what types of information are shown at the different logging levels:

 /* Level 2 */
Got SIGHUP
Processing section "[homes]"
Processing section "[public]"
Processing section "[temp]"
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC/


/* Level 3 */
05/25/98 22:15:09 Transaction 63 of length 67
switch message SMBtconX (pid 3377)
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
ACCEPTED: guest account and guest ok
found free connection number 105
Connect path is /tmp
chdir to /tmp
chdir to /
05/25/98 22:15:09 server (192.168.236.86) connect to service IPC$ as user pcguest (uid=503,gid=100) (pid 3377)
05/25/98 22:15:09 tconX service=ipc$ user=pcguest cnum=105
05/25/98 22:15:09 Transaction 64 of length 99
switch message SMBtrans (pid 3377)
chdir to /tmp
trans <\PIPE\LANMAN> data=0 params=19 setup=0
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
Doing RNetShareEnum
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
05/25/98 22:15:11 Transaction 65 of length 99
switch message SMBtrans (pid 3377)
chdir to /
chdir to /tmp
trans <\PIPE\LANMAN> data=0 params=19 setup=0
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
Doing RNetShareEnum
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
05/25/98 22:15:11 Transaction 66 of length 95
switch message SMBtrans2 (pid 3377)
chdir to /
chdir to /pcdisk/public
call_trans2findfirst: dirtype = 0, maxentries = 6, close_after_first=0, close_if_end = 0 requires_resume_key = 0 level = 260, max_data_bytes = 2432
unix_clean_name [./DESKTOP.INI]
unix_clean_name [desktop.ini]
unix_clean_name [./]
creating new dirptr 1 for path ./, expect_close = 1
05/25/98 22:15:11 Transaction 67 of length 53
switch message SMBgetatr (pid 3377)
chdir to /

[...]

We cut off this listing after the first packet because it runs on for many pages. However, you should be aware that log levels above 3 will quickly fill your disk with megabytes of excruciating detail concerning Samba internal operations. Log level 3 is extremely useful for following exactly what the server is doing, and most of the time it will be obvious where an error is occurring by glancing through the log file.

A word of warning: using a high log level (3 or above) will seriously slow down the Samba server. Remember that every log message generated causes a write to disk (an inherently slow operation) and log levels greater than 2 produce massive amounts of data. Essentially, you should turn on logging level 3 only when you're actively tracking a problem in the Samba server.

9.1.1.2 Activating and deactivating logging

To turn logging on and off, set the appropriate level in the [global] section of smb.conf. Then, you can either restart Samba, or force the current daemon to reprocess the configuration file. You also can send the smbd process a SIGUSR1 signal to increase its log level by one while it's running, and a SIGUSR2 signal to decrease it by one:

# Increase the logging level by 1
kill -SIGUSR1 1234

# Decrease the logging level by 1
kill -SIGUSR2 1234

9.1.1.3 Logging by individual client machines or users

An effective way to diagnose problems without hampering other users is to assign different log levels for different machines in [global] section of the smb.conf file. We can do this by building on the strategy we presented earlier:

[global]
	log level = 0
	log file = /usr/local/samba/lib/log.%m
	include = /usr/local/samba/lib/smb.conf.%m

These options instruct Samba to use unique configuration and log files for each client that connects. Now all you have to do is create an smb.conf file for a specific client machine with a log level = 3 entry in it (the others will pick up the default log level of 0) and use that log file to track down the problem.

Similarly, if only particular users are experiencing a problem, and it travels from machine to machine with them, you can isolate logging to a specific user by adding the following to the smb.conf file:

[global]
	log level = 0
	log file = /usr/local/samba/lib/log.%u
	include = /usr/local/samba/lib/smb.conf.%u

Then you can create a unique smb.conf file for each user (e.g., /usr/local/samba/lib/smb.conf.tim) files containing the configuration option log level = 3 and only those users will get more detailed logging.

9.1.2 Samba Test Utilities

A rigorous set of tests that exercise the major parts of Samba are described in various files in the /docs/textdocs directory of the Samba distribution kit, starting with DIAGNOSIS.TXT. The fault tree in this chapter is a more detailed version of the basic tests suggested by the Samba team, but covers only installation and reconfiguration diagnosis, like DIAGNOSIS.TXT. The other files in the /docs subdirectoryies address specific problems (such as Windows NT clients) and instruct you how to troubleshoot items not included in this book. If the fault tree doesn't suffice, be sure to look at DIAGNOSIS.TXT and its friends.

9.1.3 Unix Utilities

Sometimes it's useful to use a tool outside of the Samba suite to examine what's happening inside the server. Unix has always been a "kitchen-sink" operating system. Two diagnostic tools can be of particular help in debugging Samba troubles: trace and tcpdump.

9.1.3.1 Using trace

The trace command masquerades under several different names, depending on the operating system that you are using. On Linux it will be strace, on Solaris you'll use truss, and SGI will have padc and par. All have essentially the same function, which is to display each operating system function call as it is executed. This allows you to follow the execution of a program, such as the Samba server, and will often pinpoint the exact call that is causing the difficulty.

One problem that trace can highlight is the location of an incorrect version of a dynamically linked library. This can happen if you've downloaded prebuilt binaries of Samba. You'll typically see the offending call at the end of the trace, just before the program terminates.

A sample strace output for the Linux operating system follows. This is a small section of a larger file created during the opening of a directory on the Samba server. Each line is a system-call name, and includes its parameters and the return value. If there was an error, the error value (e.g., ENOENT) and its explanation are also shown. You can look up the parameter types and the errors that can occur in the appropriate trace manual page for the operating system that you are using.

chdir("/pcdisk/public")                 = 0
stat("mini/desktop.ini", 0xbffff7ec)    = -1 ENOENT (No such file or directory)
stat("mini", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
stat("mini/desktop.ini", 0xbffff7ec)    = -1 ENOENT (No such file or directory)
open("mini", O_RDONLY)                  = 5
fcntl(5, F_SETFD, FD_CLOEXEC)           = 0
fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lseek(5, 0, SEEK_CUR)                   = 0
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 196
lseek(5, 0, SEEK_CUR)                   = 1024
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 0
close(5)                                = 0
stat("mini/desktop.ini", 0xbffff86c)    = -1 ENOENT (No such file or directory)
write(3, "\0\0\0#\377SMB\10\1\0\2\0\200\1\0"..., 39) = 39
SYS_142(0xff, 0xbffffc3c, 0, 0, 0xbffffc08) = 1
read(3, "\0\0\0?", 4)                   = 4
read(3, "\377SMBu\0\0\0\0\0\0\0\0\0\0\0\0"..., 63) = 63
time(NULL)                              = 896143871

This example shows several stat calls failing to find the files they were expecting. You don't have to be a expert to see that the file desktop.ini is missing from that directory. In fact, many difficult problems can be identified by looking for obvious, repeatable errors with trace. Often, you need not look farther than the last message before a crash.

9.1.3.2 Using tcpdump

The tcpdump program, written by Van Jacobson, Craig Leres, and Steven McCanne, and extended by Andrew Tridgell, allows you to monitor network traffic in real time. A variety of output formats are available and you can filter the output to look at only a particular type of traffic. The tcpdump program lets you examine all conversations between client and server, including SMB and NMB broadcast messages. While its troubleshooting capabilities lie mainly at the OSI network layer, you can still use its output to get a general idea of what the server and client are attempting to accomplish.

A sample tcpdump log follows. In this instance, the client has requested a directory listing and the server has responded appropriately, giving the directory names homes, public, IPC$, and temp (we've added a few explanations on the right):

$

tcpdump -v -s 255 -i eth0 port not telnet
SMB PACKET: SMBtrans (REQUEST)	                        

Request packet
SMB Command   =  0x25                                 

Request was ls or dir.

[000] 01 00 00 10                                     ....


>>> NBT Packet                                                                 

Outer frame of SMB packet
NBT Session Packet
Flags=0x0
Length=226
[lines skipped]
                         
SMB PACKET: SMBtrans (REPLY)	                           

Beginning of a reply to  request 
SMB Command   =  0x25			                                  

Command was an ls or dir
Error class   =  0x0			 
Error code    =  0                                                                    

No errors
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  105
Proc ID       =  6075
UID           =  100
MID           =  30337
Word Count    =  10
TotParamCnt=8 
TotDataCnt=163 
Res1=0
ParamCnt=8 
ParamOff=55 
Res2=0 
DataCnt=163 
DataOff=63 
Res3=0
Lsetup=0
Param Data: (8 bytes)
[000] 00 00 00 00 05 00 05 00                           ........ 

Data Data: (135 bytes)                                                        

			Actual directory contents:
[000] 68 6F 6D 65 73 00 00 00  00 00 00 00 00 00 00 00  homes... ........
[010] 64 00 00 00 70 75 62 6C  69 63 00 00 00 00 00 00  d...publ ic......
[020] 00 00 00 00 75 00 00 00  74 65 6D 70 00 00 00 00  ....u... temp....
[030] 00 00 00 00 00 00 00 00  76 00 00 00 49 50 43 24  ........ v...IPC$
[040] 00 00 00 00 00 00 00 00  00 00 03 00 77 00 00 00  ........ ....w...
[050] 64 6F 6E 68 61 6D 00 00  00 00 00 00 00 00 00 00  donham.. ........
[060] 92 00 00 00 48 6F 6D 65  20 44 69 72 65 63 74 6F  ....Home  Directo
[070] 72 69 65 73 00 00 00 49  50 43 20 53 65 72 76 69  ries...I PC Servi
[080] 63 65 20 28 53 61 6D                              ce (Sam

This is more of the same debugging session as with the trace command; the listing of a directory. The options we used were -v (verbose), -i eth0 to tell tcpdump the interface to listen on (an Ethernet port), and -s 255 to tell it to save the first 255 bytes of each packet instead of the default: the first 68. The option port not telnet is used to avoid screens of telnet traffic, since we were logged in to the server remotely. The tcpdump program actually has quite a number of options to filter just the traffic you want to look at. If you've used snoop or etherdump, they'll look vaguely familiar.

You can download the modified tcpdump from the Samba FTP server at ftp://samba.anu.edu.au/pub/samba/tcpdump-smb. Other versions don't include support for the SMB protocol; if you don't see output such as that shown in the example, you'll need to use the SMB-enabled version.

Old News ;-)

[Jul 04, 2011] Learn Linux, 302 (Mixed environments) Configure Samba by Sean A. Walberg

 Apr 27, 2011 | developerWorks

Troubleshooting Samba problems

Samba is not immune to problems. Sometimes, these problems are caused by the system administrator; sometimes they're caused by the user. Your job as the system administrator is to figure out where the problem lies, then how to solve it.

Testing the configuration file

If Samba won't start or you want to check your configuration file for correctness, then the testparm utility will help. This utility checks smb.conf for correctness. Listing 4 shows the result of testparm if there is an error.

Listing 4. Using testparm on an incorrect smb.conf file
 

# testparm Load smb config files from /etc/samba/smb.conf Unknown parameter encountered: "hide dto files" Ignoring unknown parameter "hide dto files" Processing section "[homes]" Processing section "[printers]" Processing section "[public]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions [global] workgroup = MYGROUP server string = Samba Server Version %v passdb backend = tdbsam log file = /var/log/samba/log.%m max log size = 50 cups options = raw << rest of the output omitted >>

 

The output of testparm starts with the location of the files. If you want to specify a different file, pass the name of the file on the command line, as in this example:

testparm /home/me/smb.conf

 

Next, testparm is complaining about an invalid parameter called hide dto files. This parameter should really be hide dot files.

After processing the configuration file, you are given some information about the server's role and a condensed version of the configuration file. This version has the comments stripped out and is consistently formatted, so you will sometimes catch errors here that you missed while browsing smb.conf in a text editor.

You should run testparm on your configuration file after making changes. Samba ignores most typographical errors in the configuration files and doesn't always write messages to the console when starting up. It's likely that you won't catch these types of mistakes until something isn't working properly. Testparm alerts you to any typos in smb.conf.

By default, testparm only shows you the configuration as entered in smb.conf. If you suspect that you are using a default value somewhere, you can use the -v option to force testparm also to show default values.

Another use of testparm is to limit the output to a single section or parameter. Listing 5 shows how to use testparm to see the value of the security mask option.

Listing 5. Limiting testparm to a single parameter
 

# testparm -s --parameter-name "security mask" Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[public]" Loaded services file OK. 0777

 

In Listing 5, the -s parameter stops testparm from waiting for user input in between parsing smb.conf and displaying it to the screen. Using --parameter name "security mask" asks for the value of security mask. The result is 0777, which is the default value. In this mode, it is not necessary to specify -v to show default values.

Connecting as a client

In lieu of going to a user's desktop and trying things out yourself, you can do a great deal of testing from the command line at your own desk. The first and easiest test is to make sure that you can connect to the Samba port. The easiest way to do this is with the telnet command, which is shown in Listing 6.

Listing 6. Testing connectivity with telnet
 

# telnet bob 139 Trying 192.168.1.134... telnet: connect to address 192.168.1.134: Connection refused

 

In Listing 6, the root user is connecting to the server bob on port 139. You could also use port 445 to test for the direct-hosted SMB port. The result is Connection refused, which indicates either that the daemon isn't listening on that address or that a firewall is blocking the connection. Other results, such as No route to host or Connection timed out, can mean the same thing.

Clients generally connect to a server with a name, not an IP address. If you use telnet to connect to the server by name rather than IP address, pay special attention to the IP address returned. In the example above, the server (bob) was resolved to 192.168.1.134. Sometimes, you can have errors in your DNS records that result in the clients connecting to the wrong address.

If you are not using DNS for Windows name resolution, you can use the nmblookup command to perform a NetBIOS name lookup. Listing 7 shows a query for the bob server.

 

Listing 7. Performing a NetBIOS name query for bob
 

# nmblookup bob querying bob on 192.168.1.255 192.168.1.138 bob<00>

 

According to Listing 7, the server bob is at 192.168.1.138, not 192.168.1.134, as you saw in Listing 6. This result points to a problem with DNS, especially if ports 139 and 445 are responsive on 192.168.1.138.

Another test is to see whether the configuration file denies access to a particular host. Testparm is used again in Listing 8.

Listing 8. Checking access with testparm
 

# testparm /etc/samba/smb.conf seanspc 192.168.1.147 Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[public]" Loaded services file OK. Server role: ROLE_STANDALONE Deny connection from seanspc (192.168.1.147) to homes Deny connection from seanspc (192.168.1.147) to printers Deny connection from seanspc (192.168.1.147) to public

Firewalls or application?

There are many ways to block a connection to a host, but all the options can be grouped into two categories: network and application. By blocking at the network layer, either on a firewall or using a host-based firewall like iptables, you will see that the telnet connection shown in Listing 6 is refused or times out. This is because the packet never makes it to the Samba application.

If Samba is configured not to allow connections from a particular host, you will see that the telnet connection succeeds, but any client access is greeted with an error. This is because the packet is read by the application but doesn't like the IP address or hostname and sends an application-level error. Without accepting the packet at the application layer, Samba can't know whether the IP address is acceptable.

In Listing 8, three items are passed to testparm:

• The path to the Samba configuration file
• The NetBIOS name of the machine to test
• The IP address of the machine to test

The output from Listing 8 shows that the machine in question is denied access to all shares. When using testparm in this mode, the utility does not actually connect as that machine. Instead, testparm processes the configuration file to see whether the access would be allowed.

If all the tests up to now succeed, you can attempt to make a client connection using the smbclient utility. The first test is to attempt to browse the share list, which is shown in Listing 9.

Listing 9. Showing a machine's shares
 

[sean@bob source3]$ smbclient -L '\\bob' Enter sean's password: Anonymous login successful Domain=[MYGROUP] OS=[Unix] Server=[Samba 3.5.6-69.fc13] Sharename Type Comment --------- ---- ------- extdrive Disk Sean Walberg's iMac Disk timemachine Disk IPC$ IPC IPC Service (Samba Server Version 3.5.6-69.fc13) test Printer test Downstairs_Laser Printer HP 6L Cups-PDF Printer Cups-PDF Anonymous login successful Domain=[MYGROUP] OS=[Unix] Server=[Samba 3.5.6-69.fc13] Server Comment --------- ------- BOB Samba Server Version 3.5.6-69.fc13 Workgroup Master --------- ------- MYGROUP BOB WORK SWALBERG-XPLT WORKGROUP IMAC-1FC525

 

In Listing 9, the user is requesting a list of shares with the -L parameter on the server called bob. The server name is prefixed with two backslashes (\\), because it is a Universal Naming Convention (UNC) path. Be careful about your choice of single versus double quotation marks, as well. Single quotation marks interpolate and see the backslashes as escape characters.

If your server has more security set up, you may need to pass the name of the user or the domain with the -W and -U parameters, respectively.

Finally, you can try to connect to a share by omitting the -L parameter and specifying a full UNC path to the share. Listing 10 shows the client connecting to a server using a different workgroup and user name.

Listing 10. Connecting to a share with a different user name and domain
 

[sean@bob source3]$ smbclient '\\swalberg-xplt\photos' -U swalberg -W WORK Enter swalberg's password: Domain=[WORK] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager] smb: \> dir . D 0 Thu Jan 6 11:39:50 2011 .. D 0 Thu Jan 6 11:39:50 2011 << files omitted >> 38156 blocks of size 4194304. 2938 blocks available smb: \>>

 

If these tests pass, you can be reasonably certain that the problem is not with the Samba configuration but somewhere between the client and the server or something on the client itself. You look at the logs in the next section, which offer some clues as to where the problem lies.

 

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: July, 28, 2019