While Mac OS is unlike any Unix-like operating system I’ve managed so far, there are certainly some of similarities. I can honestly say that I’m enjoying the Mac Book Pro so far, and hope to discover most of the differences compared to my previous Unix-like desktop which is Ubuntu 9.10.

Mounting NFS on MAC OS X

One thing which I noticed immediately was that out of the box it was impossible to mount any NFS shares from my Ubuntu NAS server. Any attempt to mount a remote filesystem would give me an error like this:
mbp:~ root# mount nasbox:/try /mnt

mount_nfs: /mnt: Operation not permitted

This error was happening for a relatively simple NFS share on the Ubuntu box:
nasbox# cat /etc/exports

/try            (rw)

… so I started looking around and realized that the reason for this strange problem is quite simple.

Mac OS X uses non-standard port for outgoing NFS connections

That’s right – apparently, Mac OS X uses a non-privileged port (2049) for TCP and UDP connections serving the NFS transport. What this means is that most likely attempts to mount remote filesystems will fail, because most NFS servers don’t really like connections from insecure ports.

There are two ways to approach this problem:

1. Fix it on the client side (probably makes more sense)
2. Fix it on the NFS server side (if you manage both systems)

Using reserved NFS port number on Mac OS X

There’s a mount option supported by the mount_nfs command, which allows you to force the NFS client connections to originate from a privileged port. This will magically make your attempts to mount remote filesystems successful. The option is called resvport.

First we double-check that default mounts still don’t work:
mbp:~ root# mount nasbox:/try /mnt

mount_nfs: /mnt: Operation not permitted

… and now let’s use the resvport option:

mbp:~ root# mount -o resvport nasbox:/try /mnt

… and make sure we’re actually looking at a mounted filesystem:
mbp:~ root# df -h /mnt
Filesystem   Size   Used  Avail Capacity  Mounted on

nasbox:/try    61Gi   56Gi  2.6Gi    96%    /mnt

Allowing connections from non-privileged ports on NFS server

Like I said, if you manage both the Mac OS based client and the NFS server, perhaps it makes more sense to relax the default NFS server security and allow the connections from non-privileged ports.

Just to remind you about the validity of such a decision, the option to allow non-privileged connections is called insecure.

Here’s how you use it:
nasbox# cat /etc/exports

/try            (rw,insecure)

After making this change to the /etc/exports file, you’ll have to restart your NFS server. On my Ubuntu NAS box, it’s done like this:

nasbox# /etc/init.d/nfs-kernel-server restart
* Stopping NFS kernel daemon
…done.
* Unexporting directories for NFS kernel daemon…
…done.
* Exporting directories for NFS kernel daemon…
…done.
* Starting NFS kernel daemon
…done.

We know are ready to attempt the default mount of the same filesystem on the Mac OS X client:

mbp:~ root# mount nasbox:/try /mnt

That’s it! I won’t promise any Mac OS posts just yet, but if there is enough interest

• /Users/[username]/Library/Preferences/Microsoft/Office 2008/Microsoft Office 2008 settings.plist
• /Applications/Microsoft Office 2008/Office/OfficePID.plist

[username] would be the username of your laptop. Run any Mac Office 2008 application and the office assistant will now have a textfield of the product key for you to input.

So I’ve put one together with some info from the web (and looking inside the available Nokia plugins) and now have it working successfully over Bluetooth. It has full iCal & Address Book (with photos) support, and a nice pic of the phone for the iSync panel.

To Install
1. Download (Nokia 6120 Classic iSync Plugin (6455) – 23.69 KB) & unzip the file.
2. Open Finder, and browse to Macintosh HD/Library/PhonePlugins.
3. Copy the “Nokia-6120.phoneplugin” into this folder.

If the PhonePlugins folder doesn’t exist, create it and then do step 3.

Once done, use the Bluetooth “Bluetooth Setup Assistant” and add your phone, it should be detected and work as expected from then on.

Have fun!

The application runs rather smoothly even if it’s a beta. At least until it messed up a bunch of different cache files in /private/var/db/dyld. The line “dyld: shared cached file was build against a different libSystem.dylib, ignoring cache” was showing up whenever I worked in terminal. Amazingly irritating!

The fix

The fix for this error was rather simple, just open a terminal window and enter

$sudo update_dyld_shared_cache -force

Enter your password when required. This operation might take a few minutes.

For the record

My os x version is (currently) 10.6.2

It is a Universal Binary, and allows you to connect to multiple servers concurrently. It was originally ported from the UNIX program rdesktop

Download link

=> Download CoRD