Mac OS X SIG

Apple replaced Samba with SMBX, their home-cooked application for Windows File Sharing. By default, it doesn't do much logging. If you want to review logs, you'll have to edit the launchd item. Add the two extra ProgramArgument keys in bold below.

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 are trying to establish static CIFS (aka SMB) mounts on your Mac, here are a couple hints that might save some time and effort.

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.

I've always used the kickstart command to manage ARD. But little did I know that it can be managed using serveradmin too.

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

...does the trick too!

For a while, I used a mouse with my laptop. Because I was dealing with some wrists issues, I had the buttons flipped so that the main clicking button was on the right side, and the "right click" button was actually on the left side.  Over time, I lost the mouse and resumed using the trackpad.

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.

With Mac OS X Server, you can use Server Admin and the Certificate Assistant tools to create your private key for your server. In fact, when you start the server up, out of the box, one has already been created for you. You can use this key to create a certificate signing request (CSR) to send to your certificate authority (CA) to sign. If you do this, you will get a spiffy signed cert back, appropriate for securing your web server, chat server or a variety of other uses.

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.

These instructions are Snow Leopard-specific. First, download the Stanford Directory Utility Template installer. It will install a property list file into your home directory, which will make configuring your Mac to use the campus OpenLDAP directory system even easier than before. This template holds the record and attribute matching information, so you don't need to edit much.

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.

I'm sure there are parameters here that I'm not acknowledging, but this is something that justifies jotting down for posterity. One of the Xserves I manage (Early 2009) has a quad fibre card with connections to two fibre different switches (an Emulex and Qlogic SanBox). If the server's chassis is locked (as if to prevent accidental ejection of the internal hard drives), bootup is prevented; all I get is a blinking folder on the screen. Unlock the chassis and the machine boots normally. In my experience, it doesn't seem to matter how the server was shutdown or started up, via LOM or at the console.

Though this behavior seems reasonable, it's still undesirable. After all, what's the point of remote lights-out reboots if you can't reboot, even when your machine is configured properly. Oftentimes, chassis are locked to prevent accidents, which increase in likelihood when a server is in a high traffic area. I suggest the desired behavior should be is for the system to note its state prior to the shutdown, and permit booting only when that state is maintained.

If you do a testparm on your /etc/smb.conf file on Mac OS X Server 10.6, there's a good chance you'll see this message:

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.

Update: Be sure to add the path of the share in your 10.6 edits suggested below.

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.