Enable Logging with 10.7 SMBX (Windows File Sharing)

| No Comments | No TrackBacks

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



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

syntax differences between autofs and mount_smbfs

| 1 Comment | No TrackBacks

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.

localmountpoint   -fstype=smbfs  ://DOMAIN\;username:password@nas.stanford.edu/sharepoint\$    

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

/sbin/mount_smbfs[2017] <Error>: smb_mount: mount failed to nas.stanford.edu/sharepoint : syserr = No such file or directory    

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:

localmountpoint   -fstype=smbfs,credentials=/path/to/file  ://nas.stanford.edu/sharepoint\$    

But that will result in an error message, like

com.apple.automountd[341]: mount_smbfs: -o credentials: option not supported    

...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, "

Do not ask for a password. At run time, mount_smbfs reads the ~/Library/Preferences/nsmb.conf file for additional configuration parameters and a password. If no password is found, mount_smbfs prompts for it."    

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

kickstart vs serveradmin for ARD ON/OFF

| No Comments | No TrackBacks

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.

diskutil command line secureErase options

| No Comments | No TrackBacks
When I need to decommission a hard drive, it's necessary for me to to securely wipe the data prior to disposal. Stanford's data wiping policy is publicly accessible from the internet (though woefully out of date with the product recommendations—Mac OS 8 anyone?). It's usually not enough just to delete the files using the Finder or the rm command, since that action merely hides your files and makes their blocks eligible for possible future write-overs. Inexpensive file recovery software can usually return data when you simply delete files this way, to say nothing of real forensics software.

Retrieving the password for Server Admin-generated Keys

| No Comments | No TrackBacks

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.

Binding your 10.6 Mac to the Campus OpenLDAP directory

| No Comments | No TrackBacks

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.

Enhanced by Zemanta

Chassis lock on Xserve prevents bootup

| No Comments | No TrackBacks

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.

Level II Oplocks and Snow Leopard Server Samba

| No Comments | No TrackBacks

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,

; Site-specific parameters can be added below this comment.
; END required configuration.

    realm = stanford.edu
    acl check permissions = no
    nt acl support = no 
    veto files = /Thumbs.db/.DS_Store/.TemporaryItems/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary Items/Network Trash Folder/        

    path = /Shares/Projects     
    acl check permissions = no 
    nt acl support = no
    level2 oplocks = no

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

Snow Leopard's Samba adds unwanted directives to shares

| 11 Comments | No TrackBacks
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:

; Site-specific parameters can be added below this comment.
; END required configuration.
    veto files = /Thumbs.db/.DS_Store/.TemporaryItems/TheVolumeSettingsFolder/TheFindByContentFolder/Temporary Items/Network Trash Folder/    

[Test Share]
    path = /Shares/Test Share
    acl check permissions = no
    nt acl support = no

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

Recent Comments

  • Ahmad Merdang: I can't thank you enough for this post. I was read more
  • Jolanda Forsting: Hi Andrew... Snow Leopard works on any Mac with an read more
  • Deltron: The rest of the necessary information is supplied by you read more
  • Adam Bates: Thank you for this post. I was having a similar read more
  • Steve Beck: Ok. I think I got it ... I deleted any read more
  • Steve Beck: I am stuck here: Open System Preferences --> Network --> read more
  • Niels: Hi Noah, we’re upgrading to Office 2011 next month. I read more
  • Niels: Thank you very much for this useful information! read more
  • Screenshotzz: Thanks for the info you've provided. It has helped us read more
  • Pablogeo: It works with iPad, i tried it myself Pablo's Fotolog read more

Recent Assets

  • Screen shot 2009-09-12 at 10.55.52 AM.png
  • Screen shot 2009-09-12 at 10.42.57 AM.png
  • Screen shot 2009-09-12 at 10.43.33 AM.png
  • Screen shot 2009-09-12 at 10.40.42 AM.png
  • Snow Leopard VPN Connect
  • Picture7.png
  • Picture6.png
  • Picture2.png
  • Picture1.png