Another zfs sharenfs issue

Jeremy Chadwick freebsd at
Fri Jun 17 03:45:51 UTC 2011

On Thu, Jun 16, 2011 at 09:48:43PM -0400, James L. Lauser wrote:
> 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 8.2-STABLE FreeBSD 8.2-STABLE #13:
> Wed Jun  8 00:08:53 EDT 2011
> root at  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.

On our FreeBSD (RELENG_8-based) NFS filer for our local network, we
never bothered with the "sharenfs" attribute of the filesystems because,
simply put, it didn't seem to work reliably.  We use /etc/exports
natively and everything Just Works(tm).  We've had literally zero
problems over the years with this method, and have rebooted the filer
numerous times without any repercussions on the client side.

Given that this is the 2nd "sharenfs is wonky" thread in the past few
hours, I'm left wondering why people bother with it and don't just use

| Jeremy Chadwick                                jdc at |
| Parodius Networking              |
| UNIX Systems Administrator                   Mountain View, CA, US |
| Making life hard for others since 1977.               PGP 4BD6C0CB |

More information about the freebsd-fs mailing list