Understanding how Mac OS X handles resource forks when saving to mounted SMB server volumes has gotten much more complex due to a change Apple has made with Snow Leopard.

With Leopard/Tiger/Panther, when you saved a file that had a resource fork to a mounted SMB server volume, the resource fork would be saved to an AppleDouble file (dot underscore file, ._filename).  This legacy method has been tried and true, however resulted in extra clutter on the server.  Windows users mounting the same SMB server volume would also see these AppleDouble files, thus leading to possible confusion.

With Snow Leopard, when saving to a SMB server volume hosted by a Mac OS X server, resource forks are still saved in an AppleDouble file just like the always have.

However… with Snow Leopard, when saving to a SMB server volume hosted by a Windows server, resource forks are now saved in NTFS streams.  This method is cleaner, utilizing the extended attributes (xattr) feature when mounting the SMB volume, and no longer requires the separate AppleDouble files.

The problem this change introduces is if you have a mix of older and newer Macs saving files to a SMB server volume hosted by a Windows server.  Because Snow Leopard saves resource forks differently that Leopard/Tiger/Panther, all sorts of issues can occur.  The two formats are not backward/forward compatible, so working with files containing resource forks can result in possible file corruption and Finder errors -36 when opening/saving/copying files.

The workaround for mixed Mac environments like this is to set Snow Leopard NOT to use NTFS streams when saving to a SMB server volume hosted by a Window server.  This can be accomplished on a Snow Leopard Mac-by-Mac basis by editing the /etc/nsmb.conf file (which may need to be created if it doesn’t exist).  Adding these lines to the file, followed by reboot, will make Snow Leopard behave like Leopard/Tiger/Panther in this regard:


NOTE: ExtremeZ-IP has always saved resource forks in NTFS streams no matter the version of Mac OS X, so if you’re using ExtremeZ-IP on a Windows server to share a SMB volume, you are immune from this possible problem.

NOTE: The reason Snow Leopard still saves AppleDouble resource fork files to SMB server volumes hosted by Mac OS X servers is because all versions of Mac OS X server use Samba, and Samba doesn’t support NTFS streams.