On reboot, our system with a RAID-Z of about 200 filesystems, all inheriting the same sharenfs rule, failed to export, while the dozen or so filesystems with their own individual sharenfs rules all succeeded. At first, it appeared that we'd somehow bungled the sharenfs configuration without reloading the exports file pre-reboot (...!?), but as time passed, it became clear this wasn't a problem with the export line, but with the state nfsd/mountd were in - no matter what we tried (including "ro"), we always got back a flood of "can't change attributes for [FS]", each followed by an error "bad exports list line [FS] [old line]". We also tried sharenfs=[one of the lines from a working sharenfs export], to the same effect. It turned out our sharenfs line was perfectly fine - I shut down nfsd and mountd, zfs set sharenfs=[old export line];started mountd and nfsd again, and everything ran happily, and everything was exported properly. This sounds like some internal state got muddled somewhere, or a race condition was lost, but I can't imagine where. It's worth noting this is the first time in a number of reboots this has ever happened, and we haven't modified the sharenfs line in many months prior to this. How-To-Repeat: 1) Reboot system 2) Maybe nfsd will fail to export?
Responsible Changed From-To: freebsd-bugs->freebsd-fs Over to maintainer(s).
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
There isn't enough information to debug this.