Manual Pages

Table of Contents


na_exports - directories and files exported to NFS clients




The /etc/exports file contains a list of export entries for all file system paths that Data ONTAP exports automatically when NFS starts up. The /etc/exports file can contain up to 10,240 export entries. Each export entry can contain up to 4,096 characters, including the end-of-line character. To specify that an export entry continues onto the next line, you must use the line continuation character "\".

An export entry has the following syntax:

Each export entry is a line in the following format:

pathname -option[,option ] ...

The following list describes the fields in an export entry:

path name of a file or directory to be exported.

the export option specifying how a file or directory is exported.

You can specify an option in one of the following formats:

Specifies the actual path to use when a NFS client attempts to mount the original path. This option is useful for moving mount points without reconfiguring the clients right away. Note that while the exported pathname need not exist, the pathname given as a parameter to actual must exist.

anon=uid|name If a request comes from user ID of 0 (root user ID on the client), use uid as the effective user ID unless the client host is included in the root option. The default value of uid is 65534. To disable root access, set uid to 65535. To grant root access to all clients, set uid to 0. The user ID can also be specified by a name string corresponding to an entry in /etc/passwd.

Disables setuid and setgid executables and mknod commands on the file system path. Unless the file system is a root partition of a diskless NFS client, you should set the nosuid option to prevent NFS client users from creating setuid executables and device nodes that careless or cooperating NFS server users could use to gain root access.

ro | ro=hostname[:hostname]...
A pathname can be either exported ro to all hosts or to a set of specified hosts.

rw | rw=hostname[:hostname]...
A pathname can be either exported rw to all hosts or to a set of specified hosts. If no access modifiers are provided, then the default is rw.

Give root access only to the specified hosts. Note that there is no -root option, i.e., this option always takes at least one hostname as a parameter.

Allow access to the mounted directory only using the listed security flavors. If no sec directive is provided, then the default of sys is applied to the export. The sec directive may appear multiple times in a rule, which each appearance setting the context of the following directives: anon, nosuid, ro, root, and rw. The contexts apply in order. If only one security context is provided in an export, then it applies regardless of where it appears in the export. Note that any given secflavor can only appear once in an export rule.

The supported security flavors are:

for Unix(tm) style security based on uids and gids

for Kerberos(tm) Version 5 authentication.

for Kerberos(tm) Version 5 integrity service

for Kerberos(tm) Version 5 privacy service

The Kerberos(tm) authentication service verifies the identity of the users accessing the filer on all accesses, and also verifies to the client that the responses are from the filer. The integrity service provides a strong assurance that the messages have not been tampered with. The privacy service ensures that messages intercepted on the wire cannot be read by any other party. The integrity and privacy services both include authentication. The default security flavor is sys.

The security flavor of none can also be applied to an export. If the client uses this flavor, then all requests get the effective UID of the anonymous user. Also, if a request arrives with a security context which is not present in the export, and none is allowed, then that request is treated as if it arrived with the flavor of none.


A host is allowed to mount an export if it has either ro or rw access permissions.

A hostname is described as:

[-][machine name|netgroup|machine IP|subnet|DNS domain]

Where, `-' indicates that the host is to be denied access.

A machine name is an alphanumeric string.

A netgroup is also an alphanumeric string and describes a group of machine names. If NIS is not enabled, then each netgroup must be defined in the /etc/netgroup file. If NIS is enabled, then each netgroup may either be in a NIS mapping or defined in the /etc/netgroup file.

If a netgroup occurs in both NIS and /etc/netgroup, then the ordering given in /etc/nsswitch.conf determines which definition is used.

A netgroup can be differentiated from a hostname by prepending an `@' to the name. When an entry begins with an `@', ONTAP treats it as netgroup and not a hostname. When an entry does not begin with `@', the handling depends on the setting of the option nfs.netgroup.strict.

If nfs.netgroup.strict is set, then the `@' determines whether an entry is either a netgroup or a hostname. In this case, when an entry appears without a prepended `@', it is assumed to be a hostname, i.e., it cannot be a netgroup.

If nfs.netgroup.strict is not set, then an entry with `@' will still only denote a netgroup, but the absence of the `@' does not determine that an entry is a host.

The use of the nfs.netgroup.strict option eliminates spurious netgroup lookups (which can be helpful to performance). If it is not used, backwards compatibility with export specifications in which netgroups are not specified with an `@' is retained.

For IPv4, a machine IP is in dotted decimal format (AAA.BBB.CCC.DDD), and for IPv6, machine IP is of the form [AAAA:BBBB:CCCC:DDDD::FFFF].

A subnet is in the forms:

The IP_address field is a subnet number. It can be a IPv4 or IPv6 address in the format specified above. The num_bits field specifies the size of the subnet by the number of leading bits of the netmask.

"[network] subnet [netmask] netmask" The subnet field is the subnet number. The netmask field is the netmask. Note that the keywords network and netmask are optional.

A DNS domain starts with a `.' and is alphanumeric.

If there is a machine name and a netgroup with the same name, then the hostname is assumed to be the name of a machine.

In UNIX, it is illegal to export a directory that has an exported ancestor in the same file system. Data ONTAP does not have this restriction. For example, you can export both the /vol/vol0 directory and the /vol/vol0/home directory. In determining permissions, the filer uses the longest matching prefix.


Neither the same path nor the same file handle can be advertised for exports. We restrict the path names to make mounts unique and the file handle restriction makes per NFS request checking also be unique.

As the /etc/exports file is parsed and the same path is determined to be used for exporting, then the last instance of the export rule is stored in memory. Note that different path names may evaluate to the same advertised path:




The addition of actual complicates the rules for determining what gets exported. If an export uses -actual, then neither the advertised path nor the actual storage path may be duplicated in memory.


There is no set ordering of options, but as the ro and rw options interact, there is a strict interpretation of these options:

1) -rw is the default if -ro, -ro=, -rw, and -rw= are all not present.

2) If only -rw= is present, ro is not the default for all other hosts. This rule is a departure from pre-6.5 semantics.

3) -ro,ro= and -rw,rw= are errors.

4) -ro=A,rw=A is an error

5) -ro=A,rw=-A is an error

6) -ro=-A,rw=A is an error

7) The position of -rw, -rw= -ro, and -ro= in the options does not have any significance

8) -ro trumps -rw

9) -ro= trumps -rw

10) -rw= trumps -ro

11) A specific host name in either -ro= or -rw= overrides a grouping in the other access specifier.

12) -ro= trumps -rw=

13) Left to right precedence, which determines `-' and the order we go across the wire.

Note, "A trumps B" means that option A overrules option B.


Given the following netgroups:

farm pets (alligator,,) livestock workers

pets (dog,,) (cat,,) (skunk,,) (pig,,) (crow,,)

(cow,,) (pig,,) (chicken,,) (ostrich,,)

(dog,,) (horse,,) (ox,,) (mule,,)

(coyote,,) (puma,,) (fox,,) (crow,,)

We can illustrate the access rules thusly:

/vol/vol0 -anon=0

All hosts have rw access, and root at that.

/vol/vol0 -root=horse,rw

All hosts have rw access, but only horse has root access.

/vol/vol0 -anon=0,rw=horse

Only horse has access and it is rw. Note the departure from the prior rule format, in which all other hosts would by default have ro access.

/vol/vol0 -anon=0,ro,rw=horse

All hosts have ro access, except horse, which has rw access.

/vol/vol1 [email protected],[email protected]:canary /vol/vol1 [email protected]:canary,[email protected]

All hosts in the netgroup farm have rw access, except dog, horse, ox, and mule. All of which have ro access. In addition, canary has rw access to the export. Note that both lines are identical with respect to determining access rights.

/vol/vol2 [email protected],rw

All hosts have rw access, except for dog, cat, skunk, pig, and crow, all of which have ro access.

/vol/vol2 [email protected],rw

All hosts have rw access, except for dog, cat, skunk, pig, and crow, all of which have no access at all.

By rule #9, all members of the netgroup pets are denied rw access. By negation, all members of the netgroup pets are denied ro access.

/vol/vol2 -ro,[email protected]:canary

All hosts have ro access, except for canary, dog, cat, skunk, pig, and crow, all of which have rw access.

/vol/vol2 -ro,[email protected]:canary

All hosts have ro access, except for canary which has rw access.

/vol/vol2 -ro,[email protected]:@farm:canary

All hosts have ro access, except for canary and all hosts in the netgroups pets and farm, which all have rw access.

/vol/vol2 -ro,[email protected]:@farm:canary

All hosts have ro access, except for all hosts in the netgroup farm, excluding all hosts in the netgroup pets, which have rw access. The host canary also has rw access.

If the host cat wants to write to /vol/vol2, by rule #10, we first check the -rw= access list. By rule #13, we check for access in order of [email protected], @farm, and finally canary. We match cat in the netgroup pets and therefore cat is denied rw access. It will however be granted ro access.

/vol/vol2 -ro,[email protected]:[email protected]:canary

Effectively, all hosts have ro access, except for canary and all hosts in the netgroup farm, which all have rw access.

If the host cat wants to write to /vol/vol2, by rule #10, we first check the -rw= access list. By rule #13, we check for access in order of @farm, [email protected], and finally canary. We match cat in the netgroup farm, by expansion, and therefore cat is granted rw access.

/vol/vol2a [email protected]:[email protected],[email protected]

By rule #12, cow, pig, chicken, and ostrich all have ro access.

By rule #13, dog, cat, and skunk all have rw access.

By negation, horse, ox, and mule have no rw access and by rule #2, they have no access at all.

/vol/vol2a [email protected]:pets,[email protected]

By rule #12, cow, pig, chicken, and ostrich all have ro access.

By rule #13, negation, and rule #2, dog, horse, ox, and mule have no access.

cat and skunk have rw access.

/vol/vol3 [email protected],[email protected]:lion

All hosts in the netgroup farm have rw access, except for all hosts in the netgroup pets, which all have ro access. In addition, the host lion has rw access.

If the host cat wants to write to /vol/vol3, by rule #12, we first check the -ro= access list. We match cat in the netgroup pets and therefore we deny rw access.

/vol/vol4 -ro=10.56.17/24,rw=10.56/16

All hosts in the subnet 10.56/16 have rw access, except those in the subnet 10.56.17/24, which have ro access.

-ro=[A1C0:4C34:5D32:6F34::1]/64,\\ rw=[BA32:235C:5D24:23F::32]

All hosts in the subnet A1C0:4C34:5D32:6F34::1/64 have ro access and the host whose IPv6 address is BA32:235C:5D24:23F::32 has rw access.


All hosts in the subnet 10.56.17/24 have ro access, except, by rule #11, for and, which have rw access. If the hosts in the netgroup farm are on the 10.56.17/24 subnet, they have ro access, else they have rw access. Rule #11 allows for specific hosts to be excluded from a range provided by a group. Since it makes no sense to compare netgroups to subnets, we do not allow exceptions by groups.

-ro=,\\ rw=.fauna.mycompany.com

All hosts in the subdomain .fauna.mycompany.com get rw access, except those in the subdomain Note that we determine this result from rule #12 and not rule #11; we do not evaluate if one grouping construct is a subset of another. If is in the subdomain .fauna.mycompany.com, then by rule #11, it gets ro access.

/vol/vol21 -ro=,rw=-pets:farm:skunk

Rule #11 interacts with rules #5 and #6 in an interesting way, if a host is mentioned in an export by either name or IP, then it appears that it will always be granted the access given by whether it is in -ro= or -rw=. However, rule #13 still applies. Thus, always gets ro access, but in this case by rule #13, skunk is denied access to the mount. Since skunk is a member of the netgroup pets, and pets is denied rw access by negation, skunk is denied access.


If the secflavor is sys, then all hosts in the DNS subdomain of .farm.mycompany.com are granted ro access. If the secflavor is krb5, then all hosts are granted rw access.

/vol/vol6 -sec=sys:none,rw,sec=krb5:krb5i:k4b5p,rw,anon=0

If the secflavor is sys or none, then all hosts are granted rw access, but effectively all root access is blocked. If the secfla_vor is from one of the secure krb5, krb5i, or krb5p, then rw and effectively root access are both granted.


Exports defined prior to ONTAP 6.5 contain a different option, -access, which defined which hosts were permitted to mount an export. With the newer finer grained options, and by allowing more flexibility such as netgroups in the options, -access has been removed as an option.

Another significant change is that -ro is no longer the default if -rw= is present as an option.

During the upgrade process, the /etc/exports file is converted to the newer format.

The rules for upgrading to the new format are:

1) -root= options stay the same

2) No access list => -rw

3) -access=X => -rw=X

4) -ro => -ro

5) -access=X,ro => -ro=X

6) -rw=X => -rw=X

This is more secure than the change -rw=X,ro.

Remember from Access Rule #2, -ro is never a default.

If the less restrictive form is desired, then the option needs to be manually changed. Note that if an export file has a mix of old and new style options, the more secure new style option of -rw=X can not be differentiated from the less secure option of -rw=X(,ro) with the implicit ro modifier. To solve this problem, we always interpret -rw=X in the most secure format.

7) -access=Y,rw=X => -rw=X,ro=(Y-X)
There is a potential to remove write access here, but we keep the most secure translation.

In all cases, we preserve ordering inside an option.


/vol/vol0 -anon=0
By rule #2, this becomes:

/vol/vol0 -rw,anon=0

/vol/vol3 -ro By rule #4, this becomes:

/vol/vol3 -ro

/vol/vol0/home -rw=dog:cat:skunk:pig:mule By rule #6, this becomes:

/vol/vol0/home -rw=dog:cat:skunk:pig:mule

Note that by the access rules given above, all other hosts are denied ro access.

Since the upgrade code does not know about netgroups and netgroups used to not be allowed inside the -rw host list, this could be rewritten as:

/vol/vol0/home [email protected]

Also, if the security style is desired to be the older style, this could be further rewritten as:

/vol/vol0/home -ro,[email protected]

-access=pets:workers:alligator:mule,\\ rw=dog:cat:skunk:pig:horse:ox:mule

By rule #7, this becomes:

-ro=pets:workers:alligator,\\ rw=dog:cat:skunk:pig:horse:ox:mule

This can be rewritten as:

-ro=pets:workers:alligator,\\ rw=pets:workers

And should be:

/vol/vol1 -ro=alligator,[email protected]:@workers


The /etc/exports file is changed by ONTAP for any of the following conditions:

vol create
A default entry is added for the new volume. If an admin host had been defined during the setup process, access is restricted to that host, otherwise all hosts have access to the new volume.

vol rename
All entries which have either a pathname or an -actual pathname which matches the old volume name are changed to be that of the new volume name.

vol destroy
All entries which have either a pathname or an -actual pathname which matches the old volume name are removed from the file.

During every invocation of exportfs -a, the exports file is checked for old style formatting. If this style is found, the exports file is upgraded to follow the current formatting.

Please note that when we upgrade exports which contain subnets, we always rewrite the subnets in the compact format of IP_address/num_bits.

If the option nfs.export.auto-update is disabled, then the automatic updates for the vol commands will not take place. Instead the need for manual updates is syslogged.


A new feature in ONTAP 6.5 is the access cache, which allows netgroups to appear in -ro=, -rw=, and -root= options. Each time a request arrives from a host, it refers to an exported path. To avoid lengthy delays, we first check for that host and path in the cache to determine if we will accept or reject the request. If there is cache miss, we reject the request and do name resolution in another thread. On the next request, we should get a cache hit (i.e., the hit or miss depends on network traffic).

The time that a entry lives in the cache is determined by the two options:

dictates how long an entry which has been denied access lives

dictates how long an entry which has been granted access lives

There are several ways that the cache can be flushed:

exportfs -f
Flushes the entire access cache.

exportfs -f pathname
Flushes the cache for the longest leading prefix match for the path.

Also, any command which alters an export entry will result in the access cache for that export being flushed. E.g., exportfs -au, exportfs -a, exportfs -io -rw /vol/vol1, etc.

As the access cache is designed to eliminate name service lookups, entries inside it can become stale when the name services are modified. For example, if a netgroup is changed or a DNS server is found to have corrupt maps. If the access cache is found to have stale data, then either parts of it or all of it must be flushed. If the stale data applies to only a few exports, then each may be flushed with the exportfs -f pathname command. The entire cache may be cleared with the exportfs -f command.

Note that the same effect may be had by using commands to reload the exports table. In prior versions of ONTAP, either the exportfs -au; exportfs -a command sequence or a simple exportfs -a command was commonly used to clear away exports issues. While these can be used to clear the access cache, they can also result in extra work and lead to very small windows when an export is unavailable.


All mount requests, and NFS requests, come across the wire with an IP address and not the hostname. In order for an address to be converted to a name, a reverse lookup must be performed. Depending on the contents and ordering in /etc/nsswitch.conf, DNS, NIS, and/or /etc/hosts may be examined to determine the mapping.

A common problem with reverse DNS lookups is the existence of a mapping from name to IP, but not IP to name. Note: Data ONTAP cannot resolve a IPv6 address to multiple hostnames (including aliases), when doing a reverse host name lookup.

The option nfs.mountd.trace can be turned on to help debug access requests. Note that as this option can be very verbose and it writes to the syslog, care should be taken to only enable it while trying to resolve an access problem.

Another useful tool is to use exportfs -c to check for access permissions.


All exported pathnames which do not begin with a leading "/vol/" or "/etc/" pathname are being deprecated.


Exporting the root volume as / can be misleading to some automounters.


/etc/hosts host name database

/etc/nsswitch.conf determines name resolution search order


na_exportfs(1), na_reboot(1), na_hosts(5), na_netgroup(5), na_nsswitch.conf(5), na_options(1), na_passwd(5)

Table of Contents