February 18, 2009, 3:22 PM — 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.
