Section 12.2. Samba Logs

12.2. Samba Logs

Your first line of attack should always be to check the Samba logfiles. These can help diagnose the vast majority of the problems faced by beginning- to intermediate-level Samba administrators.

Samba is quite flexible when it comes to logging. You can set up the server to log as little or as much information as you desire. Variables in the Samba configuration file allow you to isolate individual logs for each system, share, or combination thereof.

The quickest way to determine the default location of the logfiles on your Samba server is to look for the LOGFILEBASE setting in the output from smbd -b. The following output is from a server that was compiled using only default settings:

 $ smbd -b | grep LOGFILEBASE    LOGFILEBASE: /usr/local/samba/var 

You can specify a log directory to use with vhe -l flag on the command line when starting the Samba daemons. For example:

 $ smbd -l /var/log/samba $ nmbd -l /var/log/samba 

Alternatively, you can override the location and name using the log file configuration option in smb.conf. This option accepts variables, so you could easily have the server keep a separate log for each connecting client system by specifying the following absolute path:

 [global]     log file = /var/log/samba/log.%m 

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. To do this, use the %S variable, like this:

 [global]     log file = /var/log/samba/log.%S 

12.2.1. Log Level

The level of logging that Samba uses can be set in the smb.conf file using the global log level option or its synonym debug level. The logging level is an integer that can range from 0 to 10.^[*] At level 0, only critical errors such as client disconnections or system-call-related failures are logged. Higher values result in more voluminous logging.

^[*] In reality, Samba's log level exceeds 100 in some code. However, levels 0 to 10 are the ones primarily used by both administrators and developers.

For example, let's assume that we will 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:

 [2006/02/20 19:13:19, 1] smbd/service.c:make_connection_snum(924)   client (192.168.236.10) connect to service public   initially as user lizard (uid=1004, gid=100) (pid 18450) 

Higher debug levels produce more detailed information. Usually, you won't need more than level 3, which is fully adequate for most Samba administrators. Levels above 3 are primarily used by developers. These higher levels quickly consume disk space with megabytes of excruciating detail concerning Samba's internal operations.

Here is an example of 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 what types of information are shown at the different logging levels. Note that timestamps have been removed (debug timestamp = no) to reduce the noise in the log excerpts.

 /* Level 2 */ check_ntlm_password:  authentication for user [lizard] ->   [lizard] -> [lizard] succeeded client (192.168.236.10) connect to service public   initially as user lizard (uid=1004, gid=100) (pid 18491) Serving public as a Dfs root /* Level 3 */ Transaction 6 of length 82 switch message SMBtconX (pid 18535) conn 0x0 setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 Connect path is '/export/u1/public' for service [public] se_access_check: user sid is S-1-5-21-3489264249-1556752242-1837584028-2560 se_access_check: also S-1-5-21-3489264249-1556752242-1837584028-1201 se_access_check: also S-1-1-0 se_access_check: also S-1-5-2 se_access_check: also S-1-5-11 se_access_check: also S-1-22-2-16 se_access_check: also S-1-22-2-33 se_access_check: also S-1-5-21-3489264249-1556752242-1837584028-512 se_access_check: also S-1-22-2-1003 se_access_check: also S-1-22-2-1004 se_access_check: also S-1-22-2-1006 se_access_check: also S-1-5-32-544 Initialising default vfs hooks setting sec ctx (1004, 100) - sec_ctx_stack_ndx = 0 client (192.168.236.10) connect to service public   initially as user lizard (uid=1004, gid=100) (pid 18535) setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0 Serving public as a Dfs root tconX service=PUBLIC [... deleted ...] 

We cut off the log level 3 listing after the one packet. Log level 3 is extremely useful for following exactly what the server is doing, and most of the time it is clear where an error occurs after glancing through the logfile.

Using a high log level (5 or higher) seriously slows 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 large amounts of data. Essentially, you should turn on logging level 3 or higher only when you're actively tracking a problem in the Samba server.

You might find it necessary to generate a level 10 debug log for submitting a bug report or when working with other administrators in the Samba community to track down a problem. We recommend these smb.conf settings:

 [global]     log level = 10     max log size = 0     log file = /var/log/samba/log.%m 

Then archive and compress the entire contents of /var/log/samba before sending it to the relevant parties.

12.2.2. Activating and Deactivating Logging

To turn logging on and off, set the appropriate level in the [global] section of smb.conf. Then either restart Samba or force the current daemon to reprocess the configuration file by sending it a hangup (HUP) signal. You also can monitor and control the current log level for a particular smbd process using the smbcontrol utility. The following example, run as the root user, determines that the current log level for the smbd with process id of 18637 is 0 and then sets the overall log level to 5. The final command verifies that the log level was in fact set to 5.

 $ smbcontrol 18637 debuglevel PID 18637: all:0 tdb:0 printdrivers:0 lanman:0 smb:0    rpc_parse:0 rpc_srv:0 rpc_cli:0 passdb:0 sam:0 auth:0    winbind:0 vfs:0 idmap:0 quota:0 acls:0 locking:0 msdfs:0 $ smbcontrol 18637 debug 5 $ smbcontrol 18637 debuglevel PID 18637: all:5 tdb:5 printdrivers:5 lanman:5 smb:5    rpc_parse:5 rpc_srv:5 rpc_cli:5 passdb:5 sam:5 auth:5    winbind:5 vfs:5 idmap:5 quota:5 acls:5 locking:5 msdfs:5 

12.2.3. Logging by Individual Client Systems or Users

An effective way to diagnose problems without hampering other users is to assign different log levels for different systems in the [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 = /var/log/samba/log.%m     include = /usr/local/samba/lib/smb.conf.%m 

These options instruct Samba to use unique configuration and logfiles for each client that connects. Now all you have to do is create an smb.conf file for a specific client system (e.g., /usr/local/samba/lib/smb.conf.lettuce) with a log level = 3 entry in it (the others will pick up the default log level of 0), and then use that logfile to track down the problem.

Similarly, if only particular users are experiencing a problemand it travels from system to system with themyou can isolate logging to a specific user by adding the following to the smb.conf file:

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

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