[geeks] Weird ZFS mount point issue to put in the archive

[velociraptor]

I've been hassling with Netatalk for the last few days.  Since I
rebuilt my root pool to due to that patching problem, I upgraded to
Netatalk 2.0.5 as well.  It was a lot easier to build this time, but I
couldn't get the shares mounted on the Macs.

After a bunch of experimenting, someone suggested something that had
me poking around in the actual top directory of the share point, and I
noticed this:

$ ls -altr ..
..: Permission denied

Yet, as myself, 'ls -altr /' showed all files.

Turns out my underlying mount point for the directory I was trying to
share was set to this:

drwx------   2 root     root           2 Jan  2 01:39 lagoon

Unmount, change perms to 777, remounted, and Netatalk worked fine.
Mail archives of zfs-discuss show discussions about a similar problem
with NFS shares.  In retrospect, this also explains a weird error I
was getting when trying to use 'rm -r ./directory' under that mount
point:
rm -r ./foo
rm: cannot determine if this is an ancestor of the current working
directory ./foo

I just used pfexec and ignored it, not thinking it was of any
significance.  Whoops.

The only real clue from Netatalk was an error I got out of trussing
the afpd and following forks--Err#13 EACCES:

20482:  write(5, " J a n   2 1   1 7 : 2 2".., 84)      = 84
20482:  stat64("../lagoon", 0x0809FE38)                 Err#13 EACCES
[file_dac_search]
20482:  send(10, "0102\0\bFFFFEC f\0\0\0\0".., 16, 0)   = 16

Should have looked at ".." from the start, given that error.

Hopefully this will help someone else using google to try to resolve
client side mounting problems between Solaris 10 ZFS Netatalk shares
and Mac OS X clients.

=Nadine=