Files Corrupted By Windows Sharing

Windows doesn't have a long history of interoperability and standards compliance, but the history it does have is somewhat checkered. As a result, most Macintosh administrators develop a knee-jerk aversion to Microsoft products and protocols. So when the first few Photoshop files wind up corrupted on your SMB file shares, complaining of inconsistent permissions issues or just displaying jumbled nonsense, it's easy to blame the problem on the Windows workstations. More often than not, though, it's a configuration error on Mac OS X Server that renders these files unavailable or unreadable.

The SMB (or Server Message Block) protocol is used for file sharing by Windows operating systems. It's also the basis of Windows-compatible file sharing on OS X Server, using the open source "Samba" implementation. When you configure individual share points for the SMB service, you can configure "Protocol Options" including custom naming, guest access, and permission inheritance. Those options also include enabling oplocks (also known as opportunistic locking) by default, which can be a serious and unexpected cause of file damage.

Opportunistic locking can improve performance by allowing multiple users to edit portions of a file concurrently. Unfortunately, they only work when clients edit files via over SMB, meaning that they can cause conflicts and become destructive when enabled on share points that offer AFP or NFS sharing as well. They can also cause performance issues when used with large binary files, the very kinds of files most often associated with the Macintosh platform.

While this issue can become quite serious over time, the solution is trivial. Uncheck the "Enable oplocks" box from the File Sharing configuration in Server Admin, then restart the service from the "Server" menu. You can turn off opportunistic locking this way on each share offered through multiple protocols, and eliminate the threat of file corruption through misconfiguration.

Recommended Reading: For more information on file locking with SMB, check out the Locks And Oplocks chapter of Oreilly's "Using Samba", available free online.

Open Archives Without Stuffit

In the late eighties, the original Stuffit was an invaluable utility, bringing compression and archiving capabilities to the Macintosh filesystem. In Mac OS X, however, you could soon right-click on any file or folder to create a cross-platform .zip file with the "Make Archive" feature (now called "Compress" in Leopard). While the need to compress files with Stuffit passed long ago, the need to "unstuff" old archives has never disappeared. The Unarchiver can open .sit files, as well as more than thirty other legacy formats (such as Disk Doubler and BinHex), and does it all for free.

While stand-alone expansion utilities for Stuffit archives aren't new, The Unarchiver actually ties this ability into the operating system interface, allowing you to uncompress supported formats by simply opening them in the Finder. Just double-click on the application when you first install it to determine which file formats you'd like The Unarchiver to handle.

The author of The Unarchiver isn't selling anything, so users never get nagged to "upgrade" to a deluxe version, a common complaint with the Stuffit-branded utilities. Plus, once you get your users into the habit of compressing files through the Finder, you'll be able to share archives with Windows users without shelling out for Stuffit licenses year after year.

There are, unfortunately, tasks The Unarchiver can't handle. Most notably, it lacks support for the proprietary .sitx format, which offers better compression ratios for graphics files than the original. It's also essentially a front-end for the open source libxad project, so new file formats aren't added to The Unarchiver unless they're added to libxad first. Despite these weaknesses, The Unarchiver is an invaluable tool for breaking the expensive Stuffit habit.

The Unarchiver is available for free download from its creator, Dag Ågren.

Disable Hardware Components

Security policy means different things to different companies. In some environments, using managed preferences to control external drive access would be considered draconian. In others, leaving the Airport card plugged in (or firewire ports connected) is thought of as irresponsible. What can a systems administrator do to limit hardware use on company machines?

One option is to disable use of certain hardware components at a system level. Kernel extensions, the software which allows the system to access hardware, are kept in the /System/Library/Extensions folder. Removing specific extensions from that folder will disable the associated hardware, preventing it from being used. Remove the wrong ones, unfortunately, and the your operating system won't boot.

If you want to prohibit wireless access, those files are AppleAirPort.kext, AppleAirPort2.kext, and AppleAirPortFW.kext. To disable Bluetooth capabilities (and therefore Bluetooth file transfer), you'll want IOBluetoothFamily.kext and IOBluetoothHIDDriver.kext. Apple's iSight cameras can be disabled to prevent video and photographs of your facility by replacing AppleUSBVideoSupport.kext and Apple_iSight.kext. The use of external hard drives is regulated by IOUSBMassStorageClass.kext and IOFireWireSerialBusProtocolTransport.kext.
For every hardware interface, there's a kernel extension file to match.

If your goal is to disable your chosen hardware permanently (so that software updates won't re-enable it), just replace the missing files with empty text files of the same name, then "Get Info" on each file in the Finder and check the "Locked" option so they won't be reinstalled.

Using this technique, you can insure that even users with administrative privileges can't get around the hardware restrictions on your standard installation.

Recommended Reading: Apple's very technical explanation of kernel extensions can be found at their developer site. You might also consider controlling hardware access through Open Directory's managed preferences, explained previously in this very blog.