Date: Mon, 13 Jan 2014 19:04:59 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Alban Hertroys <haramrae@gmail.com> Cc: freebsd-stable List <freebsd-stable@freebsd.org> Subject: Re: mountd Invalid radix node head (9-STABLE) Message-ID: <336193918.9334183.1389657899483.JavaMail.root@uoguelph.ca> In-Reply-To: <A89E7B29-31EC-4AD7-9FC9-10C17425285A@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alban Hertroys wrote:
> On 13 Jan 2014, at 1:06, Rick Macklem <rmacklem@uoguelph.ca> wrote:
>=20
> > Alban Hertroys wrote:
> >> I=E2=80=99ve been messing around with my NFS exports definitions to ad=
d
> >> some
> >> new mount-points to the list and I got most of it working again
> >> (at
> >> least, the important bits).
> >>=20
> >> However, 2 exports in that file are causing problems. When I
> >> restart
> >> mountd, they log lines like:
> >>=20
> >> Jan 12 16:01:14 solfertje mountd[99349]: can't change attributes
> >> for
> >> /usr/home/smb: Invalid radix node head, rn: 0 0xfffffe0023e1c600
> >> Jan 12 16:01:14 solfertje mountd[99349]: bad exports list line
> >> /usr/home/smb -mapall
> >> Jan 12 16:01:14 solfertje mountd[99349]: can't change attributes
> >> for
> >> /usr/home/vhosts/django: Invalid radix node head, rn: 0
> >> 0xfffffe0023e1c600
> >> Jan 12 16:01:14 solfertje mountd[99349]: bad exports list line
> >> /usr/home/vhosts/django -mapall
> >>=20
> >> What does that message mean? Where do I look to fix this?
> >>=20
> > Are these paths (/usr/home/smb and /usr/home/vhosts/django)
> > separate file
> > systems on the server from the others?
> >=20
> > If they are on the same server file system as one of the other
> > entries,
> > then the paths need to be added to that entry. You cannot have
> > multiple
> > entries for the same server file system and exported host/subnet.
>=20
> Ah, you=E2=80=99re right! Makes sense now, thanks.
>=20
> Still, that error message I got seems rather peculiar; is that
> supposed to happen if you mix directories and mount points like
> that?
>=20
I agree that a message about radix tree doesn't make much sense;-)
(It comes from the fact that the kernel uses a radix tree of subnet/host
addresses hanging off the server mount point for exports to the various
hosts.) I'll take a look someday and see if a better error message can
be generated.
> I think I got thrown off by the bad exports line errors that the new
> directories I added were causing originally, but those new entries
> were file-system mount points while the original entries weren=E2=80=99t.
> And you can=E2=80=99t mix those, as you say.
> I even read the section of the man page about that, but that bit
> didn=E2=80=99t register.
>=20
> I find that man-page to be a bit unclear frankly.
>=20
> 1). From a configuration point of view it doesn=E2=80=99t seem to make a
> whole lot of sense to separate plain directories from file-system
> mount points, why the distinction? Is it really necessary? I think
> if exports wouldn=E2=80=99t make that distinction, it would save head-ach=
es
> for a lot of users who mix the two without realising.
>=20
Personally, I agree. But because it's been that way for many years,
I don't see it changing.
The history (way back in the 1980s) goes something like this:
- When Sun introduced NFS, the decision to allow a mount was left
up to the mountd daemon, so server mount points weren't relevant.
- The problem with this was it was easy for a naughty client to
guess what a root file handle would look like and mount avoiding
use of mountd.
- When I first did an NFS server for BSD (4.3 Reno to be exact), the
CSRG folk and I agreed that the kernel should enforce exports because
of the above. To enforce the exports in the kernel, they needed to
be hung off the server's mount points, which restricted them to server
mount points only.
--> This was viewed as less "convenient" than the Sun way, so the
specification of exports for non-mount point directories was
included, with the understanding that these could only be enforced
by mountd (w.r.t. the exact mount directory) and the kernel
could only enforce at the level of the server file system the
directory lived in.
Others have referred to these directory mount point restrictions as
"administrative controls", since they aren't enforced by the NFS server,
but only the mountd daemon.
(ie. They stop the typo error types of mount point blunders.)
If you can come up with better words for the exports man page, feel
free to post them. The syntax is complex and convoluted enough that
I think you'll find any description gets wordy and complex, but that
doesn't imply it won't be clearer than what is already there.
> 2). The distinction between directories and mount points doesn=E2=80=99t =
get
> any clearer with the addition of the NFSv4 tree root syntax that (by
> its syntax) suggests that a whole file-system (the tree root) will
> be exported - which is often very much not what you want. There is
> mention that that=E2=80=99s not the case, but what does that line really =
do?
> Why do we need that? It=E2=80=99s not clear from the man page and it soun=
ds
> like the NFS server should be able to figure the tree root(s) out by
> itself from the list of directories to export.
>=20
For NFSv4, there is only a single server directory tree which can
span multiple server file systems. (For NFSv3, each server file system
is an independent entity and server mount points are ignored by the NFSv3
server.)
As such, the NFS server needs to know where in the server's directory
tree the NFSv4 tree is rooted. Also, unlike NFSv3,for NFSv4 there are RPCs =
that
do not refer to any location in the file system(s) and the server needed
to know what security flavor restrictions should be applied to those,
since it cannot refer to the server mount point info for these cases.
In summary, it does 2 things:
- defines where the root of the NFSv4 tree is in the server's tree
- defines what security flavors, etc, are required for RPCs that
don't involve file handles (ie. reference no location in the tree)
> 3). The text in that man page is rather dense. There=E2=80=99s a lot of =
=E2=80=9Cand
> this and that and so and so=E2=80=9D going on, all within the same sectio=
n
> that describes the 3 fields in an export line *and* several methods
> to implement them.
> I expect that document would get quite a bit clearer if the various
> enumerations would be separated, for example by giving the 3 fields
> a separate paragraph each with (optional) enumerated lists for the
> various ways those fields can be implemented.
>=20
Like I said above, feel free to post improved text for the exports
man page. (I won't be able to do commits until mid-April, but if you
post a patch and it looks good, I could commit it then.)
> The above points give me the impression that setting up an NFS server
> (on FreeBSD?) is harder than it needs to be.
>=20
I'd agree, in the sense that the /etc/exports file is rather complex.
(Personally, I always just used entries for the server mount points
with -alldirs, which avoid most of the complexity, but I'm sure
others feel the "administrative controls" are worth the added complexity.)
> That said, try setting up OS X Mavericks as an NFS client! Most of
> the Google results you get for how to set that up get it =E2=80=9Cwrong".
> For those interested: The =E2=80=9Cproper approach=E2=80=9D (the one the =
colour of my
> bikeshed) turns out to use the hidden
> /System/Library/CoreServices/Directory\ Utility.app to create mount
> point entries.
> It=E2=80=99s described in more detail here:
> http://mbcdev.com/2012/09/15/adding-nfs-shares-on-os-x-with-directory-uti=
lity/
>=20
> Here=E2=80=99s the kicker though: Mount points are not allowed to mount i=
n
> the local directory /Volumes, where they used to be created by
> default in earlier versions of OS X - such definitions will silently
> fail!
>=20
> And that=E2=80=99s just the client; I don=E2=80=99t want to find out how =
to set up an
> NFS *server* on OS X=E2=80=A6 Thankfully, that part=E2=80=99s covered by =
FreeBSD.
>=20
>=20
> Anyway, thanks for the help and I hope my suggestions prove useful to
> someone.
>=20
> Alban Hertroys
> --
> If you can't see the forest for the trees,
> cut the trees and you'll find there is no forest.
>=20
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe@freebsd.org"
>=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?336193918.9334183.1389657899483.JavaMail.root>