As part of our move from OmniOS based fileservers to ones based on Linux, I've recently been looking into how to map our current NFS export permissions into Linux's NFS export permissions. As part of this I've been looking into the similarities and differences between the Linux model of NFS export permissions and the Illumos one. The end results you can get are mostly similar (with one difference that may matter for us someday), but Linux gets there in a significantly different way.

To simplify a bit, in Illumos you have permissions that apply to things, such as netgroups. If a host would match multiple things, whichever read or read/write permission is listed first takes priority (more or less). If you write 'rw=...,ro=...', rw permissions take priority for any host in both. In Linux, this is inverted; you have things (aka NFS clients), such as netgroups, that have permissions and other options specified for them. If a host would match multiple netgroups, the first matching one wins and specifies all of the host's permissions and options. This can duplicate the Illumos read versus read/write behavior but it gives you more flexibility in general. However, it's more verbose if you have several netgroups.

To see this extra verbosity, consider an Illumos share of 'rw=A:B:C,ro=D:E', where all of these are netgroups. In Linux, you turn this inside out and wind up writing:

@A(rw,...) @B(rw,...) @C(rw,...) @D(ro,...) @E(ro,...)

As far as I know Linux has no way to specify 'any of these N netgroups' in a single match, so you have to have a separate entry for each netgroup. If you do this a lot you presumably create yourself a superset netgroup, but that doesn't necessarily scale if you're doing this on an ad-hoc basis with various different shares, as we are.

The one place where Illumos and Linux are different in an important way for us is remapping or not remapping UID 0. Illumos supports a 'root=' option, where hosts specified in it don't remap UID 0, and this is applied to them separately from whether they have read or read/write permissions. In Linux, UID 0's mapping (or lack of it) is part of a NFS client's options, and so it must be specified together with whether the client has read or read/write permission. This makes it impossible to translate some Illumos root= settings without changing your netgroups and makes translating others require local knowledge (for example, of what netgroups are a subset of what other ones).

(Linux is more flexible here in some ways, but you have to want to map UID 0 to different UIDs for different clients.)

We're fortunately not doing anything tricky with our Illumos root= permissions; the machines that we give root access to are always a subset of the machines that we give read/write access to. With this local knowledge in hand, it's easy (but verbose) to automatically translate Illumos ZFS sharenfs settings to equivalent Linux ones, although we can't manage them through ZFS on Linux's sharenfs property.

PS: The Linux NFS(v3) server doesn't support the sort of general UID and GID remapping that Illumos does; it only remaps UID 0. This fortunately doesn't matter for us in general, although it's very slightly inconvenient for me.

PPS: For NFS exporting ZFS filesystems specifically, you probably want to include the Linux crossmnt share option because, if I'm reading the tea leaves correctly, it allows NFS clients to have access to the filesystem's .zfs/snapshot pseudo-directory of ZFS snapshots, which are independent sub-filesystems. This is automatic on Illumos.