Another zfs sharenfs issue
freebsd at jdc.parodius.com
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
> 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
> [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.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |
More information about the freebsd-fs