hdiutil Requires sudo for Read/Write

Another unwelcome surprise from Apple: in some recent OS X update (I don’t know exactly which one as I ran into the problem this morning) they changed how hdiutil behaves when mounting sparsebundles in read/write mode (it is used in my build scripts as a step toward generating the final setup DMG): it now requires sudo-ing when you use the -readwrite flag.

The problem is that sudo by default prompts for a password and silently fails when used from a script. The solution is to remove that password requirement. This is carried out by adding a line to the /etc/sudoers file:

%admin ALL=(ALL) NOPASSWD: /usr/bin/hdiutil

This innocent one-line edit requires lots of command-line gymnastics, however. Permissions on the sudoers file is 440 by default, and the sudo command fails to work with anything other that that.

So you have to boot your Mac in single user mode to do the edit (by holding down Command+S at startup). Then you have to mount the root file system in read-write mode and change the permissions on the file:

mount -o update /
cd /etc
chmod 640 sudoers
vim sudoers

Add the line to the end of the file, save it and restore the file’s permissions:

chmod 440 sudoers

You can now reboot, and sudo hdiutil will not ask for a password any more! So it can be safely used from within build scripts.

Hibernate File Issue with MacBook 2012 Update

Seems that the list of annoyances I have to deal with after each and every OS X update just grown a bit. Besides the usual

chflags nohidden ~/Library

command that unhides the Library folder, now I have to do some extra work to reclaim the space normally occupied by the hibernate file (/var/vm/sleepimage). I do not use hibernation on my notebooks. I shut them down when I finished. I prefer to start with clean state on every boot, but equally I’m not fond of wasting 17 gigabytes of expensive SSD space on a file that I never use.

In the past you could turn off hibernation with

sudo pmset -a hibernatemode 0
sudo rm /var/vm/sleepimage

But after today’s release of “Update 2.0 for all Mac notebooks introduced in June 2012”, I had to do some extra work. The issue is: regardless of the state of the hibernatemode switch, the hibernate file (stored in /var/vm/sleepimage) is recreated on every boot. Bummer.

Fortunately you can also set the location of the file, so all I had to do is to send it into a black hole:

sudo pmset -a hibernatefile /dev/null

Everything works fine with this setup, but I fear that the next update could bring some more surprises…

Backing up Lightroom with ChronoSync

ChornoSync is what I use on my Mac for backing up user data – including my images. Although I don’t use Lightroom nowadays as much as I used to, backing up the database is important. There’s one gotcha, however. Preview images are stored in something called a bundle. A bundle is a directory that OS X handles as a single entity. For the catalog named Something.lrcat the preview bundle is named Something Previews.lrdata. So if one single preview image is changed, OS X thinks that the bundle is changed and ChronoSync happily copies the entire multi-hundred-megabyte conglomerate, not just the changed (or new) previews.

There’s a simple solution to this issue, shown on the image below.

Check the Dissect packages checkbox on the Options tab, and the Previews bundle will be treated as a regular directory, and ChronoSync will just synchronize newly added or changed previews.

Solved: C1 Crashes with Images on an AFP Share

I originally posted the following on the Phase One forums.

I almost pulled all my hair because of this issue, so I thought the solution could be helpful for others (especially FreeNAS users).

The problem:

I recently moved to storing all my RAW files on a central server in the studio to be able to access them from my Macs as well as a Windows notebook (which I use on the field during trips). The server is a beefy machine, with dual gigabit Ethernet connections and an 8 disk super fast ZFS array. It runs FreeBSD 9.0 with Netatalk 2.2.1 for file sharing towards Mac clients and Samba 3.6.3 for Windows file sharing. It could serve files faster than the local SSD disk in my Mac… Basically this is the same software stack you get when you use FreeNAS.

From Windows 7 running the 64-bit version of C1 everything was fine, but when I worked on my files from a Mac then C1 crashed every 5-15 minutes bringing down even the Mac (I had to pull the plug several times because even shutdown didn’t work). Frankly I was unable to work at all with C1 from Macs (running OS X 10.7.3).

The server’s log was full with the following error message:

afpd[6065]: sys_getextattr_size: error: Result too large

The solution:

After hours of debugging the solution is really simple: you have to add the “ea:ad” parameter to the shared volume’s config line in AppleVolumes.default.
The line for my Photos share is the following:

/tank/Photos ea:ad options:upriv dperm:0700 fperm:0600

No more error messages, and C1 6.3.5 shines! I’m a happy user now :D