If you need to specify the domain (say, if you are using Active Directory credentials), you need to escape the semicolon that divides the domain and the username. So if your map file is /etc/auto_smb, then you could use something like this example.

You also need to escape the dollar sign if have such a character on your remote server's sharepoint (plus any funky characters in your password). Thanks Adam! If you do not, you'll get errors like

and the icon in the Mac's Finder will be a broken alias. Note that you may need to enable verbose logging (which isn't terribly verbose) in /etc/autofs.conf file to get these messages in your system.log file.

If you're using mount_smbfs (or mount -t smbfs) via command line, on the other hand, it's unnecessary to escape the trailing $, but acceptable.

It would seem that your autofs map file could have the username, domain and password configured on a different file, as measure of security. This is normally done like this:

But that will result in an error message, like

...so it's important to safeguard the map file if you're going to expose the credentials in plain text (chown root:wheel and chmod to 600).

In the man page for mount_smbfs, the wording suggests we could use the -N flag to bypass a password prompt and instead have mount_smbfs consult /etc/nsmb.conf. It says, "

However, the man page for nsmb.conf gives no indication that the password could be a valid key.

/usr/sbin/serveradmin settings info:enableARD = yes 

...does the trick too!

What drove me nuts, however, was how my Microsoft Remote Desktop Connection connections still were programmed with the flipped buttons. Even though my trackpad on my Mac was now set back to the default arrangement, whenever I connected to a Windows machine, my buttons continued to be flipped. And since I connected to these particular Windows servers from different Macs, I had to keep flipping the right/left preference in Windows each time changed Macs.

Unfortunately, there's no evident way to reset your mouse button settings on a Mac laptop via the normal PreferencePane in System Preferences if you don't actually have a mouse attached. No mouse, no GUI.

I searched high and low for where that setting is kept so that I could reverse it, so my RDC connections would also be returned to normal too.  For your information, the right/left mouse button configuration is configured in ~/Library/Preferences/ByHost/.GlobalPreferences.[yourMACaddress].plist. That's a hidden, binary-encoded plist that's unique to your Mac hardware, in your home folder.

To edit this file, you will need to convert it to XML using the plutil terminal command, then modify the structure using your favorite text editor. You could also just delete it and a new, default one will be created, but this is a big plist with lots of discrete preference settings. Or, you could use the Property List Editor.app included with Xcode. TextMate will also allow you to convert and edit the file accordingly.

If you try to use this cert with your own version of Apache, however, you will encounter the default situation where httpd will ask for the password of that .crt file during the startup procedure.

Many admins choose to delete the password from this certificate to eliminate administrator intervention when restarting the service. The usual way this is done is to run the command openssl rsa -in /path/to/mycert.crt -out /output/path/ofmyclean.crt. To run this command, you need to know the original password.

Intuitively, you might think that the password MOSXS uses to create this private key (and thus  used to create the signed cert) would be the initial root password, or maybe the first eight characters of the serial number. Instead, it's a randomly generated password created by the system.

You can retrieve this password using the Keychain Access application. Search for the "Mac OS X Server certificate management" object of the type "application password". Double-click to examine this object and to reveal the password used by the system.

With this information, you can proceed with the openssl command to delete the password from your signed certificate. Note that you needn't have to worry about this if you're using the built-in Mac OS X services, since those programs will automatically consult the Keychain to get the password for the .crt file when starting up.

Next, launch Directory Utility. It's located in /System/Library/CoreServices folder. Edit the LDAPv3 service to add a new directory system. For the server name, enter ldap.stanford.edu in the field. The program will query the campus OpenLDAP directory, then ask you to choose a template for LDAP mapping. Since you just installed the Stanford LDAP template, choose that from the pull-down menu. Enter cn=accounts,dc=stanford,dc=edu for the searchbase.

You can configure other options as you see fit. You should also install the Kerberos Configuration Utility from the Essential Stanford Software site.

Level II oplocks can only be set if oplocks are also set.

You can read about "level2" or "level 2" opportunistic locking here in the official Samba HOWTO document (though it's written for v3.2 and Apple ships 3.0, I find it's almost entirely compatible and, in the least, quite informative). Here is what the document says,

Level2 Oplocks provides opportunistic locking for a file that will be treated as read only. Typically this is used on files that are read-only or on files that the client has no initial intention to write to at time of opening the file.

Level 2 oplocks appear to be something set to "true" or "on" by default. While Server Admin allows for enabling (plain old) oplocks and strict oplocks, there's no interface for setting level 2 oplocks off. But as the message indicates, it's effectively disabled without enabling locking in the first place.

If you do enable oplocks via Server Admin, and find the need to not have level 2 oplocks enabled too (for some odd reason — perhaps you're neurotically conscientious of your testparm output) you will need to specify this option explicitly on the share realm, not the global realm. 

Hand-edit your /etc/smb.conf file, following the convention indicated by Apple (that is, make your changes at the bottom of the conf file, using [My Sharepoint] instead of [global], setting

level2 oplocks = no [or false, if you prefer]

For example,

Remember that Apple recommends using oplocks only on shares accessed via SMB only.

There's an important behavioral difference between the version of Samba in Mac OS X Server 10.5 (Version 3.0.25b-apple) Snow Leopard's (Version 3.0.28a-apple) in the way it handles processing the /etc/smb.conf file and manages shares.

With 10.5 you could edit your /etc/smb.conf file include at least two directives in your custom [global] parameter set "acl check permissions = no" and "nt acl support = no" to address issues with locking and access. In some environments, these are very important to have, especially some Office documents and Windows XP clients.

With 10.6 however it appears you can't entirely rely on including these in your custom [global] section any longer, as recommended by Apple. You may need to append a share-specific parameter set with these two directives instead.

For example, at the end of /etc/smb.conf file:

I have a few ideas about what the problem might be.

Some forums suggested adding two parameters at the very end of your /etc/smb.conf file:

[global]
    ea support = yes
    stream support = no

I've edited this entry to reflect some changes in late 10.6 Samba releases. Further, with the right smb.conf configuration, the changes below to various EAs  don't need to be made.

We I noticed that I could download the .doc files to my Mac via AFP, make a neglible modification and save the file, then upload it back to the SAN, my Windows colleagues could then view the file. When I did an ls -l@ on the file, I could see that this process added the com.apple.ResourceFork extended attribute. At this point, the modified Office files could be opened by my PC friends.

So, ironically, rather than deleting the EAs, I needed to apply this EA to the right files. It's probably OK to write this EA on each file and directory, but that's a little heavy handed. So instead, I executed this command:

This will find the files with the .doc extension in my /Shares/Docs, add the extended attribute, and make everyone happy.

If you want to make it more thorough, you could try:

One possible issue, though, is that if you apply this command too high up the hierarchy, it seems to make a problem. You might get this error: unable to execute /usr/bin/xattr: Argument list too long

You may wish to recursively apply this further down the directory tree.