Another zfs sharenfs issue

[James L. Lauser]

Adrian's email reminded me that I'm having a persistent issues with 'zfs 
sharenfs' as well, which I don't think is related.

On my server, I have two datasets exported, pool/mythtv and pool/home/james:

[Sledge:~] james$ zfs get sharenfs | grep local
pool/home/james                sharenfs  -alldirs -mapall james 
quadraplex  local
pool/mythtv                    sharenfs  -alldirs -mapall mythtv 
herman     local

Whenever I have to reboot sledge, I lose the ability to mount my home 
directory export from quadraplex.  When I attempt the mount, I get a 
'permission denied' error from the server.  Running "sudo zfs set 
sharenfs='-alldirs -mapall james quadraplex' pool/home/james" (setting 
it to what it's already set to) fixes the problem, and it remains fixed 
until I reboot the machine again.  This ONLY affects the share to 
quadraplex.  The mythtv share to herman works without issue.

The server is 8-STABLE (built a few days ago, right after ZFSv28 was 
MFC'd) on amd64.  The machine is currently running ZFSv28, but this 
problem has existed since well before that upgrade.  I am running the 
"experimental" NFS server, but not using NFSv4.  Switching to the old 
server does not seem to affect anything.

Both clients are Ubuntu 11.04 on x86_64.

The only thought I had was the fact that I'm trying to export 
/home/james, but /home itself is not exported.  Exporting it as well, 
however, did not fix the problem.

Other useful info:

[Sledge:~] james$ uname -a
FreeBSD Sledge.home.jlauser.net 8.2-STABLE FreeBSD 8.2-STABLE #13: Wed 
Jun  8 00:08:53 EDT 2011     
root at Sledge.home.jlauser.net:/usr/obj/usr/src/sys/GENERIC  amd64
[Sledge:~] james$ grep nfs /etc/rc.conf
nfs_server_enable="YES"
nfsv4_server_enable="YES"

[Quadraplex:~] james$ grep sledge /etc/fstab
sledge:/home/james      /mnt/sledge     nfs     rw,tcp,nfsvers=3,async  
0       0

Any insight would be appreciated, though seeing as how I only normally 
reboot the server about 4 times per year, this isn't exactly a very high 
priority issue.

-- 
-- James L. Lauser
    james at jlauser.net
    http://jlauser.net/