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.
- 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.
- If a request tries to set either with either setuid or setgid or if a special file, i.e., block or character type via mknod, then nosuid disallows that request. The default mode is to allow such requests.
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 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 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.
A machine IP is in dotted decimal format: AAA.BBB.CCC.DDD
A subnet is in the forms:
The dotted_IP field is a subnet number. 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.
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.
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.
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:
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 -ro=@workers, rw=@farm:canary /vol/vol1 -rw=@farm:canary, ro=@workers
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 -ro=@pets, rw
All hosts have rw access, except for dog, cat, skunk, pig, and crow, all of which have ro access.
/vol/vol2 -ro=-@pets, 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, rw=@pets:canary
All hosts have ro access, except for canary, dog, cat, skunk, pig, and crow, all of which have rw access.
/vol/vol2 -ro, rw=-@pets:canary
All hosts have ro access, except for canary which has rw access.
/vol/vol2 -ro, rw=@pets:@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, rw=-@pets:@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 -@pets, @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, rw=@farm:-@pets: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, -@pets, and finally canary. We match cat in the netgroup farm, by expansion, and therefore cat is granted rw access.
/vol/vol2a -rw=@pets:-@workers, ro=@livestock
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 -rw=-@workers:pets, ro=@livestock
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 -ro=@pets, rw=@farm: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.
All hosts in the subnet 10.56.17/24 have ro access, except, by rule #11, for 10.56.17.5 and 10.56.17.6, 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=10.56.17.9:.frogs.fauna.mycompany.com, \\ 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 10.56.17.9 is in the subdomain .fauna.mycompany.com, then by rule #11, it gets ro access.
/vol/vol21 -ro=10.56.17.9, 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, 10.56.17.9 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.
-ro=.farm.mycompany.com, sec=krb5, rw, anon=0
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.
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.
By rule #2, this becomes:
/vol/vol0 -rw, anon=0
/vol/vol3 -ro By rule #4, this becomes:
/vol/vol0/home -rw=dog:cat:skunk:pig:mule By rule #6, this becomes:
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:
Also, if the security style is desired to be the older style, this could be further rewritten as:
/vol/vol0/home -ro, rw=@pets
- -access=pets:workers:alligator:mule, \\ rw=dog:cat:skunk:pig:horse:ox:mule
- -ro=pets:workers:alligator, \\ rw=dog:cat:skunk:pig:horse:ox:mule
- -ro=pets:workers:alligator, \\ rw=pets:workers
/vol/vol1 -ro=alligator, rw=@pets:@workers
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.
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.
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 dotted_IP/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.
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:
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.
A common problem with reverse DNS lookups is the existence of a mapping from name to IP, but not IP to name.
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.
/etc/nsswitch.conf determines name resolution search order
- DUPLICATE DETECTION
- ACCESS RULES
- ACCESS RULES EXAMPLES
- UPGRADE EXAMPLES
- AUTOMATIC EDITING
- ACCESS CACHE
- DEPRECATED FEATURES
- SEE ALSO
Copyright © 1994-2008 NetApp, Inc. Legal Information