Who’s Using Samba?

Samba provides a set of tools that allow Unix systems to share resources with their Windows counterparts and is both easy to set up and remarkably reliable. Still, there are times when you might want to take a look at who is using your Samba services. When these occasions arise, the smbstatus command can tell you a lot, but not all of its output is necessarily easy to understand.

Some of the Samba output looks like the table below.

PID     Username      Group         Machine
-------------------------------------------------------------------
897       gregp         devguys       dragonfly   (10.9.9.123)
934       karens        devguys       butterfly   (10.9.9.101)
915       mannyg        devguys       tadpole     (10.9.9.134)

This output shows the process IDs of the smbd process for each active user’s process. We then see the username and user group for each user, plus the system name and IP address of the client they are using to access the Samba shares.

The next section provides some of the same and some additional information. Here we see the time each user mapped the shared resource on the client system.

Service      pid     machine       Connected at
-------------------------------------------------------
gregp        897   dragonfly     Wed Feb 18 08:01:14 2009
karens       934   butterfly     Wed Feb 18 09:23:57 2009
mannyg       915   tadpole       Wed Feb 18 08:42:46 2009

If you request a brief report using the -b option, you will only see the first table shown above. With a full report (no options), you will also see a list detailing the file locks that are in place. As with any type of file system, Samba needs some way to keep multiple users from attempting to update a file at the same time. One way it does this is by providing something called opportunistic locks or “oplocks” for short. As you can see in the listing below, one column in the locked files report describes oplocks that are placed on files that are being used by the various Samba users.

Locked files:
Pid     Uid      DenyMode     Access      R/W       Oplock   SharePath   Name   Time
----------------------------------------------------------------------------------------
897   4056    DENY_NONE  0x2019f    RDWR    EXCLUSIVE+BATCH  /homes/gregp   

.metadata/.lock   Wed Feb 18 08:32:05 2009
897   4056    DENY_NONE  0x2019f    RDWR    EXCLUSIVE+BATCH  /homes/gregp   

.metadata/.plugins/org.eclipse.cdt.core/sms-latest.1234971877375.pdom   
Wed Feb 18 10:41:28 2009
1252  1111    DENY_NONE  0x100001 RDONLY  NONE             /spare .   Wed Feb 18 

11:53:00 2009
1252  1111    DENY_NONE  0x20089   RDONLY  EXCLUSIVE+BATCH  /homes/racheller   smb.conf  

 Wed Feb 18 14:45:42 2009

Exclusive oplocks are fairly straightforward. A Samba user opens a file and nobody else can touch it. These locks are fairly efficient, especially if the user is making a lot of changes to the file. Sometimes even exclusive locks can be broken by the server, however, which then instructs the client to send any updates it has cached.

Batch oplocks implies that updates to locked files are grouped together so that multiple connections don’t have to be set up, used and then shut down.

The locked files report will give you some idea about the files that Samba users are updating. Since the locks themselves are handled by Samba and the SMB (Server Message Block) or CIFS (Common Internet File System) protocols, you don’t need to be too concerned about them beyond noting their use.