Debugging Samba: Deciphering Access Denied

When a user presents an Access Denied error message and says Samba is the culprit, is the blame warranted? Here's how to determine whether the error is the fault of Samba.

The next time a user comes knocking with an Access Denied error message and blames it on Samba, tell him to slow...

down. Most of the time, it's not Samba's fault, said Samba release manager Jerry Carter. "Our motto is 'Bug for bug, feature for feature, we are completely compatible with Microsoft Windows,''" he said.

Our motto is 'Bug for bug, feature for feature, we are completely compatible with Microsoft Windows.'
Jerry Carter,
release managerSamba

Carter usually says the motto with a smile, as he did during a presentation at the LinuxWorld conference in San Francisco this month, but his claim is mostly serious. It sounds arrogant, but more often than not, Carter and the rest of the Samba team eventually discover that the "bugs" logged by users are hardware issues specific to their systems or bugs that actually exist in Windows, not Samba.

Access denied

How to have a Samba bug report ignored:
Don't describe how to reproduce the bug in thorough detail.
Don't specify what version of Samba you are using.
Don't attach your smb.conf. Don't attach level debug logs when requested.
Don't respond at all when requested for more information. Do include text dumps of CIFS packets in the bug comments.

"In this scenario, the error message will say something like, 'Permission is needed to perform this action,'" Carter said. "You will never get an exact problem, because the user will just give you the error message they received and expect you to find out what the problem is. [As a system administrator], what you have to do is decipher what is popping up in front of the user and what is actually happening with Samba."

For any system administrator, the debugging process should always begin with a simple set of steps and a process of elimination, Carter said. First, ensure that you understand what the expected result should be. Then, if possible, test the same operation against a Windows server and check the physical networking hardware for issues.

The basics: Check permissions with smbstatus

$ smbstatus

PID  Username Group       Machine
15215  AD\gcarter  AD\unixusers    vanz (

Service  pid  machine     Connected at
public  15215  vanz  Tue Jul 3 19:58:22 2007

If things check out, Carter prescribes a recipe for basic debugging needs. The basic debugging settings recommended by the Samba Team are log level 10, log file = /var/log/samba/log.%m, where Max Log Size is set to zero, debug time stamp is set to Yes, and the debug: pid set to Yes. Limiting log file size and log levels increase performance while debugging, Carter said.

Get grepping with Samba

Here's how Carter said users should deploy grep tools when Access Denied pops up on users' displays:

  • Find the error and backtrack by using grep panic log.*
  • Look for crashes with egrep '(WERR_|NT_STATUS)' log.* | grep -v OK
  • Look for ACCESS_DENIED and so on by way of grep .api_rpcTNP.*unknown$. log.*
  • Look for unknown MS-RPC calls with

Carter explained that many times in an access denied scenario, grep will return a message like this one in the log file:

unix_error_packet: error string = Permission denied
error packet at smbd/trans2.c(2682) cmd=162

"So grep wants to open the log file," he said, "and finds that access is denied. But why?" The answer is the SID, or security identifier. In Microsoft Windows, the SID is a unique alphanumeric character string that identifies each operating system and each user in a network of NT/2000/XP systems.

$ getent passwd "AD\gcarter"
$ getent passwd "gcarter"

Additional Samba debugging tools
  • Formerly known as Ethereal, Wireshark is a network sniffer and protocol analysis tool that provides excellent support for Server Message Block/Common Internet File System; Network Basic I/O System; distributed computing environment/remote procedure calls, Kerberos, Lightweight Directory Access Protocol and other associated protocols.
  • There are also system trace tools, such as strace, ltrace and the contents of /proc.

Email Jack Loftus with your comments and suggestions.

If users can come to accept that everything in Samba runs smoothly most of the time, they can start debugging the software to find where the true source lies. And to retrace their steps, Carter said, they should investigate the Access Denied error message. Once that step is complete, system administrators need to know who is connected to what and what their permissions are, Carter said. "If user jbgood is actually connected as catzilla or [some other] ID … that is an immediate thing to look at," Carter said. A simple smbstatus check will volunteer that information immediately. Consider this example: With the basics covered above, system administrators should execute some common grep commands, Carter said. The grep utilities are a family of Unix tools that are used to perform repetitive searching tasks. Administrators can use grep to search file contents for information that matches particular criteria. "When a user is authenticated against the server, either standalone or remote, Samba will authenticate the password and then make a token for every user. So not only will every user in every group in any Windows domain have an SID, they will also have an associated Unix token," Carter said. This can create a disparity between SIDs and UIDs. In Carter's example, he discovered 11 SIDs for his group ID, but a UID list of only seven. It also creates naming confusion, as the two IDs are actually considered different users by the system. With a Get Password command, Carter showed how the two IDs can look very similar to the user, and lead to the initial access denied/permissions problem: "These are actually two different users. Look at UID (the numbers in the second and fourth lines) and they are different," he said. Need more help? Carter recommended some additional tools for administrators looking for a debugging edge.

Dig Deeper on Linux servers