Avoid Prompts for the Admin Password when Writing to ZFS volumes

When you're creating zpools and ZFS volumes you have to be doing it with root privileges, so naturally any volume you create is going to be owned by root. So if you are trying to write to these volumes as your normal Mac login, it's going to prompt for the admin password every time.

The easy fix is just to make yourself the owner of that volume:

# chown -R UserName:GroupName /Volumes/myzpool

If you have multiple users, then use chmod to allow access to other users.

Empty Trash won't work

Badness level, on a scale of 1 (not bad) - 100 (WTF?): 5

If you delete files on a ZFS volume via the Finder, you won't be able to use Empty Trash properly. The files don't show up in the Finder anymore, but they're actually just moved to a hidden directory called ".Trashes". You have to use "rm" in the Terminal to really remove the file (or just "rm -rf .Trashes").

As far as most things go, this is not a huge deal, but you could easily forget that this issue exists and accidentally let your zpool fill up over time and then waste a bunch of time troubleshooting it. Maybe some sort of Applescript/Automator/cronjob approach would provide a semi-seamless workaround.

Mac ZFS Kernel Panic Crashing

Badness level, on a scale of 1 (not bad) - 100 (WTF?): 100

First up is the more egregious behavior that I've seen so far with Mac ZFS. As I've been experimenting, I've noticed that it fails in the most ungraceful way possible (kernel panic and immediate Grey Screen of Death) when any of these conditions occur:

You're using an external USB/FW drive for ZFS and you unplug the drive before you unmount any ZFS volumes and "zfs export -f poolname" the ZFS pool on that external drive.

If a vdev/drive in a zpool has a failure that will put you into a FAULTED state. So on a RAIDZ (single-parity) if you lose 2 drives, that causes the kernel panic. Or on a RAIDZ2 (double-parity), if you lose 3 drives, same deal. Or in a 2-way mirror if you lose both halves of the mirror.

Drive went to sleep or got spun down (like on a laptop or if you have the spin-down set in your Energy Saver settings).

Apparently ZFS panics (literally!) when there are an asynchronous writes that already returned "success" and would
make disk state inconsistent. The supposed reason for defaulting to panics is "maintaining data integrity" because "ZFS cannot guarantee that the information in the cache, ZIL, and media will be consistent." [original post].