Volume Number: 23 (2007)
Issue Number: 08
Column Tag: Networks
By Philip Rinehart, Yale University
This month, the MacEnterprise community has been talking about Samba, and how OS X uses it, both on Server and Client. It's a bit of an interesting topic, as both use a version of Samba, 3.0.10, that is slightly out of date, as the current version of Samba shipping is 3.0.25a. It is interesting to note that the Finder does not primarily use the underlying samba framework, but instead uses mount_smbfs, a command from the FreeBSD project instead. First let's look at this particular command.
Mount_smbfs is a bit of an oddity. It appears to have been included in OS X to take advantage of OS X frameworks. It is linked heavily to the CoreFoundation framework in particular. It also allows for Kerberos authentication, which has only recently appeared in Samba 3.0 or higher. Its usage is pretty simple, and follows the same syntax, both in the Finder and from the command line. In fact, when connecting via the Finder to a share, the command appears in the process list when initiating the connection. Here is the command as it appears in the process list.
/sbin/mount_smbfs -o noautomounted -o browse //user:**************@sambashare /Volumes/sambashare
Let's look at this command a bit further; note the two options used with the -o switch. Neither of these options appear in the manual page for the command. Omit the two options, and the command appears as invoked from the command line. Why is that important to know? It is important, because often many users use smbclient to connect to the Samba share and assume that smbclient behaves in the same way. Now that you know that the Finder uses mount_smbfs, it may or may not be an effective way to test Samba connectivity. If testing the connection via the Finder, use mount_smbfs. Unfortunately, it does not provide as much debugging information as smbclient does.
Another source of frustration for some users is OS X, by default, uses encrypted passwords when connecting to a Samba share. In fact, an Apple knowledge base article, 301580, exists that describes the creation of a configuration file, nsmb.conf, which allows clear text authentication. It should be noted that a file can be created per user as well, .nsmbrc. Let's look at a short example:
[default] workgroup=WORKGROUP # this is the server name and ip [WINDOWS] address=192.168.1.130 [WINDOWS:USERNAME] password=my_password
By putting this file in a user's home directory the Samba share will be mounted automatically using the stored password. Note that the password should be stored in encrypted format. To generate the encrypted password, use smbutil. Here's how:
smbutil crypt my_password
Include this in the nsmbrc file, and the Finder will no longer ask for authentication. That pretty much sums up the way that OS X client connects to Samba shares. The Server side is the source of most other common problems.
Now that we understand how a client connects to file shares, are there any particular hints for dealing with Windows file shares? Sure, here are some that should be considered:
OS X client cannot connect to a Windows 2003 server if the server has the "digitally sign communication" option enabled. Disable this option to allow a successful connection. The Finder usually will show an Error -5000. It is commonly known as "SMB Signing". For more information on this option, refer to the Microsoft Knowledge Base article, http://support.microsoft.com/kb/887429.
Shares created on a Windows file share generally work most successfully when the user connects with "Full permissions" on the file share. Without full permissions, the Finder may not display any file or folder in the share point.
Let's move to a frequently discussed topic, the use of Samba as implemented on OS X. One of the commonly discussed issues is the use of an older version of Samba, version 3.0.10, in OS X. Samba is also compiled in a particular way, and may not include modules that are required. Recently, a method for recompiling certain modules appeared on the MacEnterprise list. If this is of interest, search the list archives, as the procedure is fairly complex.
Another oddity with Samba is that it does not respect the use of ctime. Why is this relevant? Consider the possibility of controlling backups of files, if the ctime is being used to control whether the file is backed up or not, the inability of Samba to set the ctime could become a problem.
Next, when using Samba in conjunction with Active Directory, check the smb.conf file for the following entries:
Use spnego=yes Realm=Ad.realm.name Security=ads
Though generally not an issue any more in Tiger server, when joining a machine to Active Directory and hosting Samba file services via OS X in earlier versions, these options were not consistently set.
Lastly, when using Samba, on server or client, the log level can be tuned. The following entry can be added to the /etc/smb.conf file:
log level = [1-10]
Turning up the log level can be very useful when debugging a troublesome connection. At a level of 10, the logging can be quite a handful to parse through, but it may better point to the source of the connection problem.
The last issue that is somewhat common is connecting to a shared Windows printer from OS X. Usually the printer is shared as a "Guest" printer by the Windows machine. However, when printing, an "NT_STATUS_ACCESS_DENIED" error message is returned. OS X does not work without credentials when printing to a Windows shared printer. The most successful method of connecting works by adding the printer using the URI formatted this way:
smb://user:password@DOMAIN/1.2.3.4/Printername
Sometimes adding this via the Printer Setup Utility will work, sometimes not. If it does not work, using the CUPS web interface at http://localhost:631 will allow the printer to be added. It has the additional benefit of being able to print a test page!
In a heterogeneous world, understanding Samba and Windows file and print sharing is a complex and sometimes difficult operation. Often, the configuration or the tools that we have talked about may provide a solution. Until next month, see you on the lists!
Philip Rinehart is co-chair of the steering committee leading the Mac OS X Enterprise Project (macenterprise.org) and is the Lead Mac Analyst at Yale University. He has been using Macintosh Computers since the days of the Macintosh SE, and Mac OS X since its Developer Preview Release. Before coming to Yale, he worked as a Unix system administrator for a dot-com company. He can be reached at: philip.rinehart@yale.edu. The MacEnterprise project is a community of IT professionals sharing information and solutions to support Macs in an enterprise. We collaborate on the deployment, management, and integration of Mac OS X client and server computers into multi-platform computing environments.
