beteblanche:~ noahabrahamson$ sudo vi /System/Library/LaunchDaemons/com.apple.smbd.plist

...

    <key>ProgramArguments</key>
    <array>
            <string>/usr/sbin/smbd</string>
            <string>-debug</string>
            <string>-stdout</string>
    </array>

Now you can use syslog -w to review your logs in Terminal in real time.

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. (or the variant, openssl rsa -in key.pem -out newkey.pem if you are working with .pem-format certificates, which are the default if you use Server Admin.app to generate certs).

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.

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.

veto files =
hide files =

This worked fine — until it didn't. Seems I wasn't doing it properly.

There's a lot of (typically legacy) HFS detritus sprinkled around on a Mac server. When both AFP and SMB are enable, Windows users see these bits and pieces, much to their confusion. (These files and directories are invisible to Macs.)

Originally, I had this at the end of my smb.conf file, but once I added the final veto files = option below at the bottom, I was disappointed things didn't work as expected.

That was the trick. I'm not sure why, because seemingly the individual entries should work just as well as the string of filenames. Now those Mac filenames are now hidden from my Windows users.