mountd Invalid radix node head (9-STABLE)

Tue Jan 14 00:05:07 UTC 2014

Alban Hertroys wrote:
> On 13 Jan 2014, at 1:06, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> 
> > Alban Hertroys wrote:
> >> I’ve been messing around with my NFS exports definitions to add
> >> some
> >> new mount-points to the list and I got most of it working again
> >> (at
> >> least, the important bits).
> >> 
> >> However, 2 exports in that file are causing problems. When I
> >> restart
> >> mountd, they log lines like:
> >> 
> >> 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
> >> 
> >> What does that message mean? Where do I look to fix this?
> >> 
> > Are these paths (/usr/home/smb and /usr/home/vhosts/django)
> > separate file
> > systems on the server from the others?
> > 
> > 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.
> 
> Ah, you’re right! Makes sense now, thanks.
> 
> Still, that error message I got seems rather peculiar; is that
> supposed to happen if you mix directories and mount points like
> that?
> 
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’t.
> And you can’t mix those, as you say.
> I even read the section of the man page about that, but that bit
> didn’t register.
> 
> I find that man-page to be a bit unclear frankly.
> 
> 1). From a configuration point of view it doesn’t 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’t make that distinction, it would save head-aches
> for a lot of users who mix the two without realising.
> 
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’t 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’s not the case, but what does that line really do?
> Why do we need that? It’s not clear from the man page and it sounds
> like the NFS server should be able to figure the tree root(s) out by
> itself from the list of directories to export.
> 
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’s a lot of “and
> this and that and so and so” going on, all within the same section
> 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.
> 
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.
> 
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 “wrong".
> For those interested: The “proper approach” (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’s described in more detail here:
> http://mbcdev.com/2012/09/15/adding-nfs-shares-on-os-x-with-directory-utility/
> 
> Here’s the kicker though: Mount points are not allowed to mount in
> the local directory /Volumes, where they used to be created by
> default in earlier versions of OS X - such definitions will silently
> fail!
> 
> And that’s just the client; I don’t want to find out how to set up an
> NFS *server* on OS X… Thankfully, that part’s covered by FreeBSD.
> 
> 
> Anyway, thanks for the help and I hope my suggestions prove useful to
> someone.
> 
> Alban Hertroys
> --
> If you can't see the forest for the trees,
> cut the trees and you'll find there is no forest.
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"
> 