The magic of ZFS and NFS (2nd try)

[Christian Baer]

Hi everyone!

I've already asked this question (basically) in the questions list, but I
didn't get anything that really helped me along. I am hoping to get a little
further on this list.

Using my search engines, I have found out that exporting a ZFS is a by
picky. However I have found no general rules of what to do - yet.

My file server is called obelix, my workstation falbala. Feel free to make
fun of that fact. :-)

obelix boots from an SSD. There is a raidz2 configured with 7 HDDs, mounted
under /zfs/arc1. This is the main (basic, root) mount point of the ZFS pool
and it is pretty much empty. There are other tanks I have defined and they
are under /usr/archive/. The directory /usr/archive/ is of course still part
of the SSD.

When I set /usr/archive as an export in /etc/exports, I can mount that from
falabala. I see all the subdirectories too - each of these are ZFS tanks.
However, I cannot access the contents of the tanks. I've played around here
a bit and there are two things that can happen:

1. I can dive into the directories but they look empty from falbala.
2. Access to the directories is refused completely.

I don't remember what I did to get each of these results, so please don't
ask. :-)

Ok, so I read that I cannot export all ZFS mounts together like this and
have to create an export for each seperately. Fine with me. :-)

So I created and export to /usr/archive/shared which is the mount point of a
ZFS tank. But if I try to mount that via NFS from falbala, the connection is
denied completely. This is logged in /var/log/messages on obelix - without
any reason however.

Now it might be that I am just to dumb to understand the works of NFS and
ZFS or I am just missing a piece of the puzzle. Can someone please give me a
push, please?

Regards,
Chris

[Rainer Duffner]

Post by Christian Baer
Hi everyone!
I've already asked this question (basically) in the questions list, but I
didn't get anything that really helped me along. I am hoping to get a little
further on this list.
Using my search engines, I have found out that exporting a ZFS is a by
picky. However I have found no general rules of what to do - yet.
My file server is called obelix, my workstation falbala. Feel free to make
fun of that fact. :-)
obelix boots from an SSD. There is a raidz2 configured with 7 HDDs, mounted
under /zfs/arc1. This is the main (basic, root) mount point of the ZFS pool
and it is pretty much empty. There are other tanks I have defined and they
are under /usr/archive/. The directory /usr/archive/ is of course still part
of the SSD.
When I set /usr/archive as an export in /etc/exports, I can mount that from
falabala. I see all the subdirectories too - each of these are ZFS tanks.
However, I cannot access the contents of the tanks. I've played around here
1. I can dive into the directories but they look empty from falbala.
2. Access to the directories is refused completely.
I don't remember what I did to get each of these results, so please don't
ask. :-)
Ok, so I read that I cannot export all ZFS mounts together like this and
have to create an export for each seperately. Fine with me. :-)
So I created and export to /usr/archive/shared which is the mount point of a
ZFS tank. But if I try to mount that via NFS from falbala, the connection is
denied completely. This is logged in /var/log/messages on obelix - without
any reason however.
Now it might be that I am just to dumb to understand the works of NFS and
ZFS or I am just missing a piece of the puzzle. Can someone please give me a
push, please?

You must use the syntax of exports(5) also with zfs set sharenfs=
AFAIK, you shouldn’t use /etc/exports to do zfs exports but the above command

If your hosts you export to are in your nfs-server’s /etc/hosts, you will need to use the names they resolve to also in the exports-statement.
(Though that might be wrong - it was the case with Solaris, though).

uids/gids should match, too, of course.




Rainer

[Russell L. Carter]

Post by Christian Baer
Hi everyone!
I've already asked this question (basically) in the questions list, but I
didn't get anything that really helped me along. I am hoping to get a little
further on this list.
Using my search engines, I have found out that exporting a ZFS is a by
picky. However I have found no general rules of what to do - yet.
My file server is called obelix, my workstation falbala. Feel free to make
fun of that fact. :-)
obelix boots from an SSD. There is a raidz2 configured with 7 HDDs, mounted
under /zfs/arc1. This is the main (basic, root) mount point of the ZFS pool
and it is pretty much empty. There are other tanks I have defined and they
are under /usr/archive/. The directory /usr/archive/ is of course still part
of the SSD.
When I set /usr/archive as an export in /etc/exports, I can mount that from
falabala. I see all the subdirectories too - each of these are ZFS tanks.
However, I cannot access the contents of the tanks. I've played around here
1. I can dive into the directories but they look empty from falbala.
2. Access to the directories is refused completely.
I don't remember what I did to get each of these results, so please don't
ask. :-)
Ok, so I read that I cannot export all ZFS mounts together like this and
have to create an export for each seperately. Fine with me. :-)
So I created and export to /usr/archive/shared which is the mount point of a
ZFS tank. But if I try to mount that via NFS from falbala, the connection is
denied completely. This is logged in /var/log/messages on obelix - without
any reason however.
Now it might be that I am just to dumb to understand the works of NFS and
ZFS or I am just missing a piece of the puzzle. Can someone please give me a
push, please?

Post your /etc/exports, and the nfs*_enable bits of /etc/rc.conf. And
as Rainer noted you definitely need to check that uid/gid match on
both server and client.

You can quickly check that sharenfs=on via mount:

***@terpsichore> mount | grep NFS
system/export on /export (zfs, NFS exported, local, nfsv4acls)
system/export/library on /export/library (zfs, NFS exported, local,
nfsv4acls)
system/export/usr on /export/usr (zfs, NFS exported, local, nfsv4acls)
system/export/usr/obj on /export/usr/obj (zfs, NFS exported, local,
nfsv4acls)
system/export/usr/src on /export/usr/src (zfs, NFS exported, local,
nfsv4acls)
ssd1/poudriere/ports/default on /ssd1/poudriere/ports/default (zfs, NFS
exported, local, nfsv4acls)
system/usr/ports on /usr/ports (zfs, NFS exported, local, nosuid, nfsv4acls)
system/usr/ports/distfiles on /usr/ports/distfiles (zfs, NFS exported,
local, nosuid, nfsv4acls)
/raid/library on /export/library (nullfs, NFS exported, local, nfsv4acls)
/ssd1/poudriere/data/packages/stable-amd64-default on /export/packages
(nullfs, NFS exported, local, nfsv4acls)

Russell

Post by Christian Baer
Regards,
Chris
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-fs

[Russell L. Carter]

On Feb 21, 2015, at 9:36 AM, Christian Baer
But why shouldn't I use /etc/exports? I have read people writing
this (don't use /etc/exports) in forums when searching for answers,

FreeNAS has more experience with sharing things from ZFS than anyone
else in the BSD community (that’s not hyperbole, it’s simply
fact). We don’t use any of the zfs sharing flags. Those were
intended more for Solaris (sharesmb, for example - FreeBSD lets you
do that, but what does it *mean* when you don’t have a native CIFS
service?). FreeBSD has never integrated ZFS’s notion of sharing
or, for that matter, a number of other things like drive hot sparing
and automatic replacement, and you’re seeing the results of ZFS’s
solaris roots still not lining up 100% with their new FreeBSD home.
That’s all.
I would simplify things, just as FreeNAS has (for good reasons), and
simply have ZFS be “a filesystem” from FreeBSD’s perspective
and share it just as you would UFS.

When I was working out my own mounts, it seemed that sharenfs=on was
required to make them work, but I just checked and indeed I can
mount a zfs file system over NFS4.1 without it. So I would definitely
agree about not complicating things.

Having both sharenfs and sharesmb *seem* to work does complicate
figuring out how to make NFS work if you don't already know this,
though.

Back to Christian's problem, I don't see nfsv4_server_enable="YES"
in your rc.conf lines. I have it in mine, and NFSv4 works.
See man(4) nfsv4.

You might have a look at /var/log/messages after restarting nfsd.

Russell

- Jordan
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe,

[Rainer Duffner]

But why shouldn't I use /etc/exports? I have read people writing this (don't
use /etc/exports) in forums when searching for answers, however the current

FreeNAS has more experience with sharing things from ZFS than anyone else in the BSD community (that’s not hyperbole, it’s simply fact). We don’t use any of the zfs sharing flags. Those were intended more for Solaris (sharesmb, for example - FreeBSD lets you do that, but what does it *mean* when you don’t have a native CIFS service?). FreeBSD has never integrated ZFS’s notion of sharing or, for that matter, a number of other things like drive hot sparing and automatic replacement, and you’re seeing the results of ZFS’s solaris roots still not lining up 100% with their new FreeBSD home. That’s all.
I would simplify things, just as FreeNAS has (for good reasons), and simply have ZFS be “a filesystem” from FreeBSD’s perspective and share it just as you would UFS.

Interesting.

I admit I don’t use NFS v4.
Is it much faster than NFS v3 these days?

But I’ve always added the line from exports(5) into the sharenfs property like

zfs get sharenfs datapool/nfs/ds3-documents
NAME PROPERTY VALUE SOURCE
datapool/nfs/ds3-documents sharenfs -maproot=1003 -network 10.10.10.0 -mask 255.255.255.0 inherited from datapool/nfs

These lines get written into /etc/zfs/exports

I like it that way because if a filesystem is destroyed, I don’t have to remember removing it from /etc/exports.

I also admit I’m heavily influenced by Solaris on this particular setting…

[Jordan Hubbard]

But why shouldn't I use /etc/exports? I have read people writing this (don't
use /etc/exports) in forums when searching for answers, however the current

FreeNAS has more experience with sharing things from ZFS than anyone else in the BSD community (that’s not hyperbole, it’s simply fact). We don’t use any of the zfs sharing flags. Those were intended more for Solaris (sharesmb, for example - FreeBSD lets you do that, but what does it *mean* when you don’t have a native CIFS service?). FreeBSD has never integrated ZFS’s notion of sharing or, for that matter, a number of other things like drive hot sparing and automatic replacement, and you’re seeing the results of ZFS’s solaris roots still not lining up 100% with their new FreeBSD home. That’s all.

I would simplify things, just as FreeNAS has (for good reasons), and simply have ZFS be “a filesystem” from FreeBSD’s perspective and share it just as you would UFS.

- Jordan

[Christian Baer]

Post by Russell L. Carter
Post your /etc/exports, and the nfs*_enable bits of /etc/rc.conf. And
as Rainer noted you definitely need to check that uid/gid match on
both server and client.

Pretty boring stuff...

***@obelix:~ # cat /etc/exports
V4: /usr/archive/Shared -alldirs -network 192.168.100/24

I reduced the shares to one for the time being.

***@obelix:~ # mount
/dev/ufs/root on / (ufs, local, soft-updates)
devfs on /dev (devfs, local, multilabel)
/dev/ufs/var on /var (ufs, local, soft-updates)
/dev/ufs/usr on /usr (ufs, NFS exported, local, soft-updates)
arc1 on /zfs/arc1 (zfs, local, nfsv4acls)
arc1/home on /home (zfs, local, nfsv4acls)
arc1/Shared on /usr/archive/Shared (zfs, local, nfsv4acls)
arc1/Private on /usr/archive/Private (zfs, local, nfsv4acls)

***@obelix:~ # cat /etc/rc.conf | grep nfs
nfs_server_enable="YES"
nfsuserd_enable="YES"

The handbook did not say I needed anything more than those.

Post by Russell L. Carter
system/export on /export (zfs, NFS exported, local, nfsv4acls)

^^^^^^^^^^^^
As you can see, this is always missing in my lines. Please also see my other
post with the reference to the zfs manpage which states that nfs exports may
also be managed via the /etc/exports file.

Best regards,
Chris

[Christian Baer]

Post by Rainer Duffner
You must use the syntax of exports(5) also with zfs set sharenfs=
AFAIK, you shouldn’t use /etc/exports to do zfs exports but the above
command

But why shouldn't I use /etc/exports? I have read people writing this (don't
use /etc/exports) in forums when searching for answers, however the current
manpage for zfs says this:

sharenfs=on | off | opts
Controls whether the file system is shared via NFS, and what options
are used. A file system with a sharenfs property of off is managed
the traditional way via exports(5). Otherwise, the file system is
automatically shared and unshared with the "zfs share" and "zfs
unshare" commands. If the property is set to on no NFS export options
are used. Otherwise, NFS export options are equivalent to the con-
tents of this property. The export options may be comma-separated.
See exports(5) for a list of valid options.

To me this looks like I can choose whether I want to use the exports file
or if I wish to set the sharenfs flag. I don't really *that* much, although
I don't really think this is something that a file system should decide, but
should be set from the NFS server.

Post by Rainer Duffner
If your hosts you export to are in your nfs-server’s /etc/hosts, you will
need to use the names they resolve to also in the exports-statement.
(Though that might be wrong - it was the case with Solaris, though).

I used IPs. See other post.

Post by Rainer Duffner
uids/gids should match, too, of course.

They do. There aren't so many users so it's not too hard to keep up with
that. :-) But I just checked again to make sure.

Regards,
Chris

[Justin Clift]

But why shouldn't I use /etc/exports? I have read people writing this (don't
use /etc/exports) in forums when searching for answers, however the current

FreeNAS has more experience with sharing things from ZFS than anyone else in the BSD community (that’s not hyperbole, it’s simply fact). We don’t use any of the zfs sharing flags. Those were intended more for Solaris (sharesmb, for example - FreeBSD lets you do that, but what does it *mean* when you don’t have a native CIFS service?). FreeBSD has never integrated ZFS’s notion of sharing or, for that matter, a number of other things like drive hot sparing and automatic replacement, and you’re seeing the results of ZFS’s solaris roots still not lining up 100% with their new FreeBSD home. That’s all.
I would simplify things, just as FreeNAS has (for good reasons), and simply have ZFS be “a filesystem” from FreeBSD’s perspective and share it just as you would UFS.

As a possible alternative thought, if anyone has patches to make
the above work with FreeBSD, they'd probably be considered.

Just saying. ;)

Regards and best wishes,

Justin Clift

--
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift

[Rick Macklem]

Post by Rainer Duffner

On Feb 21, 2015, at 9:36 AM, Christian Baer
But why shouldn't I use /etc/exports? I have read people writing
this (don't
use /etc/exports) in forums when searching for answers, however
the current

FreeNAS has more experience with sharing things from ZFS than
anyone else in the BSD community (that’s not hyperbole, it’s
simply fact). We don’t use any of the zfs sharing flags. Those
were intended more for Solaris (sharesmb, for example - FreeBSD
lets you do that, but what does it *mean* when you don’t have a
native CIFS service?). FreeBSD has never integrated ZFS’s notion
of sharing or, for that matter, a number of other things like
drive hot sparing and automatic replacement, and you’re seeing the
results of ZFS’s solaris roots still not lining up 100% with their
new FreeBSD home. That’s all.
I would simplify things, just as FreeNAS has (for good reasons),
and simply have ZFS be “a filesystem” from FreeBSD’s perspective
and share it just as you would UFS.

Interesting.
I admit I don’t use NFS v4.
Is it much faster than NFS v3 these days?

Nope. If you are lucky, you'll be about performance neutral when
switching from v3 -> v4. If you access lots of files, you probably
won't be performance neutral, due to the extra overhead of Opens, etc.

NFSv4 isn't really a replacement for NFSv3 imho. It fills a different,
although somewhat overlapping solution space. It provides better byte
range locking, ACLs and, when pNFS becomes commonly available, better
scalability for I/O performance on relatively large servers (especially
if the clients are accessing a fairly small number of large files).
If you don't need any of the above, you don't need/want NFSv4, again imho.

Sorry to wander off topic, but Rainer did ask;-) rick

Post by Rainer Duffner
But I’ve always added the line from exports(5) into the sharenfs
property like
zfs get sharenfs datapool/nfs/ds3-documents
NAME PROPERTY VALUE
SOURCE
datapool/nfs/ds3-documents sharenfs -maproot=1003 -network
10.10.10.0 -mask 255.255.255.0 inherited from datapool/nfs
These lines get written into /etc/zfs/exports
I like it that way because if a filesystem is destroyed, I don’t have
to remember removing it from /etc/exports.
I also admit I’m heavily influenced by Solaris on this particular
setting…
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-fs

[Rick Macklem]

Post by Rick Macklem

Post by Rainer Duffner

Am 21.02.2015 um 19:23 schrieb Jordan Hubbard

On Feb 21, 2015, at 9:36 AM, Christian Baer
But why shouldn't I use /etc/exports? I have read people writing
this (don't
use /etc/exports) in forums when searching for answers, however
the current

FreeNAS has more experience with sharing things from ZFS than
anyone else in the BSD community (that’s not hyperbole, it’s
simply fact). We don’t use any of the zfs sharing flags. Those
were intended more for Solaris (sharesmb, for example - FreeBSD
lets you do that, but what does it *mean* when you don’t have a
native CIFS service?). FreeBSD has never integrated ZFS’s
notion
of sharing or, for that matter, a number of other things like
drive hot sparing and automatic replacement, and you’re seeing
the
results of ZFS’s solaris roots still not lining up 100% with
their
new FreeBSD home. That’s all.
I would simplify things, just as FreeNAS has (for good reasons),
and simply have ZFS be “a filesystem” from FreeBSD’s perspective
and share it just as you would UFS.

Interesting.
I admit I don’t use NFS v4.
Is it much faster than NFS v3 these days?

Nope. If you are lucky, you'll be about performance neutral when
switching from v3 -> v4. If you access lots of files, you probably
won't be performance neutral, due to the extra overhead of Opens,
etc.
NFSv4 isn't really a replacement for NFSv3 imho. It fills a
different,
although somewhat overlapping solution space. It provides better byte
range locking, ACLs and, when pNFS becomes commonly available, better
scalability for I/O performance on relatively large servers
(especially
if the clients are accessing a fairly small number of large files).
If you don't need any of the above, you don't need/want NFSv4, again
imho.

Oh, and NFSv4 allows clients to cross server mount point boundaries.
Some will find this a useful feature, others a hassle.

Post by Rick Macklem
Sorry to wander off topic, but Rainer did ask;-) rick

Post by Rainer Duffner
But I’ve always added the line from exports(5) into the sharenfs
property like
zfs get sharenfs datapool/nfs/ds3-documents
NAME PROPERTY VALUE
SOURCE
datapool/nfs/ds3-documents sharenfs -maproot=1003 -network
10.10.10.0 -mask 255.255.255.0 inherited from datapool/nfs
These lines get written into /etc/zfs/exports
I like it that way because if a filesystem is destroyed, I don’t
have
to remember removing it from /etc/exports.
I also admit I’m heavily influenced by Solaris on this particular
setting…
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to

_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-fs

[Christian Baer]

Post by Rainer Duffner
These lines get written into /etc/zfs/exports
I like it that way because if a filesystem is destroyed, I don’t have to
remember removing it from /etc/exports.
I also admit I’m heavily influenced by Solaris on this particular setting…

I didn't come from Solaris and I wasn't a big fan of it during my time at
university. It wasn't the really a problem with the OS itself but with the
userland which really sucked rocks at the time. We are talking SunOS 5.8
here.

I am guessing that in the future, ZFS will be far more important and UFS
will become more and more exotic. Then it would be fine to config everything
the ZFS-way. But currently, it seems pretty dumb to have to go through a
case list like:

case
fs == ZFS then /etc/zfs/exports
fs == $EXOTIC_OTHER_FS then goto whereever
else goto /etc/exports

Couldn't help myself with the gotos there. :-D

On the other hand, if you can configure the same thing in a number of files,
chaos is predestined. That is one machine I would not want to take care of.

Regards,
Christian

[Christian Baer]

Post by Russell L. Carter
When I was working out my own mounts, it seemed that sharenfs=on was
required to make them work, but I just checked and indeed I can
mount a zfs file system over NFS4.1 without it. So I would definitely
agree about not complicating things.

The complicated thing about the options here is not so much where they have
to be set (although I am doing a pretty good job ob messing that up), but
rather that it's a pain if a setting can be found in one of 10
configuration
files. That is a real pain.

Post by Russell L. Carter
Having both sharenfs and sharesmb *seem* to work does complicate
figuring out how to make NFS work if you don't already know this,
though.

Well, I always got NFS to work fine in the past and we use it quite heavily
at work. This is my first try at NFS with ZFS. And as I stated, the
directory /usr/archive (which is a subfolder of / and formated with UFSv2)
can be read fine. So if move or copy something from within
/usr/archive/Shared to /usr/archive, I can access that file or folder tree.
But let's say that is sub-optimal.

Post by Russell L. Carter
Back to Christian's problem, I don't see nfsv4_server_enable="YES"
in your rc.conf lines. I have it in mine, and NFSv4 works.
See man(4) nfsv4.

I was actually expecting NFSv4 to be that default in FreeBSD 10.1. But ok,
I
added the line and restarted the nfsd with

***@obelix:/usr/archive/Shared # /etc/rc.d/nfsd restart
Stopping nfsd.
Waiting for PIDS: 11247 11248, 11247.
Starting nfsd.

Post by Russell L. Carter
You might have a look at /var/log/messages after restarting nfsd.

There was nothing in /var/log/messages about the nfsd restarting. But there
was something when I tried to mount the export:

Feb 23 13:05:19 obelix mountd[50070]: mount request denied from
192.168.100.8 for /usr/archive/Shared

Is there a way to get a message about what motivated this reaction? The
mount command wasn't helpful either:

***@falbala:/mnt # mount obelix:/usr/archive/Shared /mnt/Shared/
[tcp] obelix:/usr/archive/Shared: Permission denied

Note that this keeps going and I have to exit it via ctl-c.

Kind regards,
Christian

[Martin Simmons]

Post by Christian Baer

Post by Russell L. Carter
Post your /etc/exports, and the nfs*_enable bits of /etc/rc.conf. And
as Rainer noted you definitely need to check that uid/gid match on
both server and client.

Pretty boring stuff...
V4: /usr/archive/Shared -alldirs -network 192.168.100/24
I reduced the shares to one for the time being.

According to exports(5), that reduces it to zero:

The third form has the string ``V4:'' followed by a single absolute path name,
to specify the NFSv4 tree root. This line does not export any file system,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
but simply marks where the root of the server's directory tree is for NFSv4
clients. The exported file systems for NFSv4 are specified via the other
lines in the exports file in the same way as for NFSv2 and NFSv3.

__Martin

[Martin Simmons]

Post by Christian Baer
There was nothing in /var/log/messages about the nfsd restarting. But there
Feb 23 13:05:19 obelix mountd[50070]: mount request denied from
192.168.100.8 for /usr/archive/Shared

This is a message from mountd, so make sure that it is restarted after
changing /etc/exports (I'm not sure if /etc/rc.d/nfsd restart does that).

__Martin

[Freddie Cash]

On Mon, Feb 23, 2015 at 4:30 AM, Christian Baer <

Post by Rainer Duffner

Post by Rainer Duffner
These lines get written into /etc/zfs/exports
I like it that way because if a filesystem is destroyed, I don’t have to
remember removing it from /etc/exports.
I also admit I’m heavily influenced by Solaris on this particular

setting…
I didn't come from Solaris and I wasn't a big fan of it during my time at
university. It wasn't the really a problem with the OS itself but with the
userland which really sucked rocks at the time. We are talking SunOS 5.8
here.
I am guessing that in the future, ZFS will be far more important and UFS
will become more and more exotic. Then it would be fine to config
everything
the ZFS-way. But currently, it seems pretty dumb to have to go through a

​You don't. All NFS-related configuration stuff goes into /etc/exports by
default. Including ZFS stuff. Just treat ZFS like any other filesystem
when it comes to NFS, and configure it just like any other filesystem.

If, and only if, you want to play with the ZFS property "sharenfs", then
you can. You aren't required to (and probably shouldn't as the syntax will
be different for every OS and may cause issues with replication to other
pools). If you do, then anything you put into that property will be
automatically copied into /etc/zfs/exports.

You should never be manually editing /etc/zfs/exports, as any manual
changes you make will be lost the next time you edit any "sharenfs"
property on any ZFS filesystem.

[Rick Macklem]

Post by Martin Simmons

Post by Christian Baer

Post by Russell L. Carter
Post your /etc/exports, and the nfs*_enable bits of /etc/rc.conf.
And
as Rainer noted you definitely need to check that uid/gid match
on
both server and client.

Pretty boring stuff...
V4: /usr/archive/Shared -alldirs -network 192.168.100/24
I reduced the shares to one for the time being.

As Martin notes below, the above does not export any file system.
Add a line for /usr/archive/Shared to /etc/exports just like you would
have for UFS and then send a HUP signal (kill -HUP <mountd-pid>) to
make the changes to /etc/exports take effect.
- After this, check for syslog messages, in case the exports syntax
isn`t correct.

I know nothing about ZFS, but my understanding is that you can do
everything in /etc/exports just like you would for UFS.
(I'm not even sure what ZFS calls a file system, but every line
you see when you type "mount" with no arguments is a file system
as far as FreeBSD is concerned.)
Every file system you want to access from client(s) must have an
line in exports (or in the ZFS stuff if you choose to do it that way).

The only difference for NFSv4 is that the client(s) don`t have to
do separate mounts for each file system, but they all must be
exported to the client(s).

Hope this helps, rick
ps: You only have one V4: line because there is only one place
in the server`s directory tree that can be a root for NFSv4.

Post by Martin Simmons
The third form has the string ``V4:'' followed by a single absolute
path name,
to specify the NFSv4 tree root. This line does not export any file
system,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
but simply marks where the root of the server's directory tree is for
NFSv4
clients. The exported file systems for NFSv4 are specified via the
other
lines in the exports file in the same way as for NFSv2 and NFSv3.
__Martin
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-fs

[Kurt Lidl]

Post by Rainer Duffner
You must use the syntax of exports(5) also with zfs set sharenfs=
AFAIK, you shouldn’t use /etc/exports to do zfs exports but the above
command

But why shouldn't I use /etc/exports? I have read people writing this (don't
use /etc/exports) in forums when searching for answers, however the current
sharenfs=on | off | opts
Controls whether the file system is shared via NFS, and what options
are used. A file system with a sharenfs property of off is managed
the traditional way via exports(5). Otherwise, the file system is
automatically shared and unshared with the "zfs share" and "zfs
unshare" commands. If the property is set to on no NFS export options
are used. Otherwise, NFS export options are equivalent to the con-
tents of this property. The export options may be comma-separated.
See exports(5) for a list of valid options.
To me this looks like I can choose whether I want to use the exports file
or if I wish to set the sharenfs flag. I don't really *that* much, although
I don't really think this is something that a file system should decide, but
should be set from the NFS server.

Well, I would argue (putting aside Jordan's semi-rant), that the correct
thing to do is use the sharenfs flag for ZFS filesystems, as already
recommended.

The mechanics of using it are straightforward:

zfs set sharenfs="things you would put in /etc/exports" path/to/zfs

In a more concrete example, on one of my machines, I have:

***@hostname-134: zfs get all |grep sharenfs|grep zroot/fbsd
zroot/fbsd sharenfs off
default
zroot/fbsd/10.0-amd64 sharenfs -maproot=root local
zroot/fbsd/9.1-amd64 sharenfs -maproot=root -alldirs local
zroot/fbsd/9.1-sparc64 sharenfs -maproot=root -alldirs local

Those were created via:
zfs set sharenfs="-maproot=root" zroot/fbsd/10.0-amd64

After doing that, the file /etc/zfs/exports was automatically created
for me (look, no need to manually edit /etc/exports):

***@hostname-135: cat /etc/zfs/exports
# !!! DO NOT EDIT THIS FILE MANUALLY !!!

/fbsd/10.0-amd64 -maproot=root
/fbsd/9.1-amd64 -maproot=root -alldirs
/fbsd/9.1-sparc64 -maproot=root -alldirs

All I had to do after this was restart my mountd daemon:

***@hostname-136: service mountd restart
Stopping mountd.
Starting mountd.
***@hostname-137: ps -auxww | grep mountd
root 58779 0.0 0.1 10232 2312 ?? Ss 10:30AM 0:00.01
/usr/sbin/mountd -r /etc/exports /etc/zfs/exports

Make sure that you have the appropriate NFS daemons started in your
server's /etc/rc.conf:

# NFS server things
# (inetd is needed for tftpd)
inetd_enable="YES"
mountd_enable="YES"
mountd_flags="-r"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4"
rarpd_enable="YES"
rpcbind_enable="YES"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

I enable inetd because I need to have tftpd running for diskless booting
of my sparcs when I play with them, along with some other, older
machines.

The examples above work fine for me on FreeBSD 9.1, and I've done the
same thing on FreeBSD 10.1 too - this has worked fine for pretty long
time.

-Kurt

[Christian Baer]

Post by Martin Simmons
The third form has the string ``V4:'' followed by a single absolute path
name,
to specify the NFSv4 tree root. This line does not export any file
system,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
but simply marks where the root of the server's directory tree is for
NFSv4
clients. The exported file systems for NFSv4 are specified via the other
lines in the exports file in the same way as for NFSv2 and NFSv3.

I see the part in the manpage you are referring to. The way nfs reacts
doesn't seem to be that way though. I have changed the contents of
/etc/exports to

/usr/archive/Shared -alldirs -network 192.168.100/24

I still cannot mount that share.

The V4: at the beginning of the line did not change anything I could notice.
If I let the path point to a ZFS file system, I get permission denied, when
it points to a path on UFS, it works fine.

Die directories in question have the correct owner and group. Is there some
way that ZFS may have a different setting for this?

Kind regards,
Christian

[Rick Macklem]

Post by Christian Baer

Post by Martin Simmons
The third form has the string ``V4:'' followed by a single absolute
path
name,
to specify the NFSv4 tree root. This line does not export any file
system,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
but simply marks where the root of the server's directory tree is
for
NFSv4
clients. The exported file systems for NFSv4 are specified via the
other
lines in the exports file in the same way as for NFSv2 and NFSv3.

I see the part in the manpage you are referring to. The way nfs
reacts
doesn't seem to be that way though. I have changed the contents of
/etc/exports to
/usr/archive/Shared -alldirs -network 192.168.100/24

You need both lines for an NFSv4 mount to work. For example:
V4: /usr/archive/Shared -network 192.168.100/24
/usr/archive/Shared -alldirs -network 192.168.100/24

Then the client mount command would look like:
mount -t nfs -o nfsv4 <server>:/ /mnt
- Note that if the V4: line specifies /usr/archive/Shared as its root,
then the client mounts that as "/".

If you want to mount the same dir as NFSv3, the mount would look like:
mount -t nfs -o nfsv3 <server>:/usr/archive/Shared /mnt

Post by Christian Baer
I still cannot mount that share.
The V4: at the beginning of the line did not change anything I could
notice.

It enables NFSv4 and tells the server where the client mount's "/" is.

Post by Christian Baer
If I let the path point to a ZFS file system, I get permission
denied, when
it points to a path on UFS, it works fine.
Die directories in question have the correct owner and group. Is
there some
way that ZFS may have a different setting for this?

Not that I am aware, but I am not a ZFS guy, rick

Post by Christian Baer
Kind regards,
Christian
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-fs