On Fri, 19 Mar 2010 20:18, Jeremy Chadwick wrote:
In Message-Id: <[email protected]>
On Fri, Mar 19, 2010 at 07:50:24PM -0400, Charles Sprickman wrote:
On Fri, 19 Mar 2010, Willem Jan Withagen wrote:
On 17-3-2010 9:27, Matthias Gamsjager wrote:
sharenfs does work in freebsd but iscsi does not. I'm not sure about smb.
about nfs: you should take a look at /etc/zfs/exports
On Wed, Mar 17, 2010 at 9:15 AM, Harald Schmalzbauer
<[email protected]> wrote:
Hello,
I observed some very strange filesystem security problems.
Now I found that if I set sharenfs=yes data/pub I can mount_nfs but it
does't respect any settings in /etc/exports. Also I get very strange uid
numbers when writing.
If I turn sharenfs off, limitations in /etc/exports work as expected.
I thought sharenfs and sharesmb are only working on
OpenSolaris. What about
shareiscsi?
I do not use /etc/exports for zfs shares....
But instead of yes as value, you can use the NFS-options as string
and that gets it into /etc/zfs/exports.
Just wondering, is this using the base nfsd/mountd, or is there some
in-kernel nfs code strictly for zfs? I haven't found much info on
the share* options in the manpage or wiki.
ZFS on FreeBSD's "sharenfs" option does nothing more than manage data in
a flat file (/etc/zfs/exports) and automatically send a SIGHUP to
mountd's pid (based on reading the contents of the file
_PATH_MOUNTDPID). If you grep through /usr/src/cddl you can see what
I'm referring to.
"So how does mountd know about /etc/zfs/exports?"
$ ps -auxw | grep mount
root 861 0.0 0.0 6836 1716 ?? Is 10Mar10 0:00.00
/usr/sbin/mountd -r -l /etc/exports /etc/zfs/exports
This is defined/referenced in /etc/rc.d/mountd.
All that said:
I avoid use of the "sharenfs" option in ZFS on RELENG_7 and RELENG_8, as
I found certain quirks/behavioural oddities (such as mountd not picking
up changes, or claims of not exporting something which visually
confirmed should have been exported -- and in one case, mounting of a
ZFS-exported NFS filesystem worked but then any I/O would block on the
client indefinitely. Don't ask me how/why that happened). Possibly
these were bugs that existed during ZFS's transitional phase between 7.x
and 8.x, but the unreliable nature of the situation left a bad taste in
my mouth. The workaround:
Using /etc/exports to reference the local ZFS filesystems I want
exported, HUP mountd, done. Above oddities/quirks no longer happened.
And there's an added bonus: all your exports are therefore kept in one
single place: a text file that's existed since what, 1989 or so?
Of course, the advantage is that with ZFS properties you can inherit
options -- that might be useful to some, but not to me.
There's also known quirks/issues with the parsing logic with "sharenfs".
This was discussed in December 2009.
Could you give an example of passing options that would say, limit
to a subnet and map root to root using the zfs sharenfs command?
zfs create pool/fs
zfs set sharenfs="-maproot=blah -network x.x.x.x -mask y.y.y.y" pool/fs
Right now I'm more or less "avoiding" NFS as much as possible, as the
number of severe/major bug reports on RELENG_8 keep coming in, and that
scares me greatly.
There is also this:
http://www.freebsd.org/cgi/query-pr.cgi?pr=144447
Which I filed a while back that shows a bug in at least stable/7 that does
not unshare/remove shared filesystems from /etc/zfs/exports.
PJD has taken this PR and asked for a followup if this can be confirmed on
a 8.X system as he believes it is fixed there.
If someone of this thread is running a 8.X system would you please
followup to this PR with YES/NO it exists or not, and it would be greatly
appreciated.
I believe this also has a part of sending HUP to mountd but I could not
test that either on stable/7 or stable/8.
--
jhell
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
