exportfs [ -c ] host pathname [ ro | rw | root ]
exportfs -s pathname
exportfs -d
exportfs -r
exportfs -w pathname
exportfs -h
If no pathname is specified, exportfs lists all currently exported directories and files. If pathname is specified, exportfs makes the specified file or directory available or unavailable for mounting by NFS clients.
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.
pathname
the path of the export node to check in the
access cache.
[ ro | rw | root ]
whether to check for read-only (ro),
read-write (rw), or root ((root)
permissions. Note that if this final parameter
is not provided, the exportfs -c command
will check to see if the client has
mount permissions to the export.
Note that if you flip the order of such duplicate rules in /etc/exports, then the expected export will change.
This functionality was added to mitigate the slight open window in which applications would recieve an ESTALE. Note that exportfs -au followed by exportfs -a will still reload the exports in memory.
exportfs -o rw=adminhost,root=adminhost /vol/vol0 exportfs -o rw /vol/vol0/home
exportfs -p rw=adminhost,ro,anon=0 /vol/charts
The following examples show different forms of the exportfs command that export the /vol/vol0/home directory to the 10.45.67.0 subnet with the 255.255.255.0 netmask:
exportfs -o rw=10.45.67.0/24 /vol/vol0/home exportfs -o rw=10.45.67/24 /vol/vol0/home exportfs -o rw="network 10.45.67.0 netmask 255.255.255.0" \\ /vol/vol0/home exportfs -o rw="10.45.67.0 255.255.255.0" /vol/vol0/home
exportfs -i -o rw=10.45.67.0/24 /vol/vol0/home exportfs -o rw=10.45.67/24 -i /vol/vol0/home exportfs -io rw="network 10.45.67.0 netmask 255.255.255.0" \\ /vol/vol0/home exportfs -i -o rw="10.45.67.0 255.255.255.0" /vol/vol0/home
exportfs -io \\ rw=10.0.0.0/8:"network 172.28.2.0 netmask 255.255.255.0" \\ /vol/vol0 exportfs -io \\ ro="network 172.28.2.0 netmask 255.255.255.0":"10.45.67.0 255.255.255.0" \\ /vol/vol0/home
-i -o-o -i -io
-oi
exportfs -o actual=/vol/vfilers/vf19,rw=pets,root=workers \\ /vol/vol9/vf19
and at some later point we want to determine the actual path to storage, we can use -s to determine that information:
> exportfs -s /vol/vol9/vf19 /vol/vfilers/vf19 > exportfs -s /vol/vol9/vf19/src /vol/vfilers/vf19/src
Remember that the -actual parameter allows for a server side aliasing of path names in the event that the storage has been moved and clients have not yet been updated to the new path.
If we then want to check to see if the client dog could mount this export, we would use -c:
> exportfs -c 192.168.208.51 /vol/vfilers/vf19 exportfs: 192.168.208.51 has mount access to /vol/vfilers/vf19
Note that as RPC requests come across the wire with IP addresses and not machine names, to test the algorithm to determine access, it is best to pass in the IP address and not the name.
Also, -c does not convert the path to the actual storage path, again because the RPC calls only reference the exported path name.
If a host has established a mount session for an export and is unable to either read, write, or have root permissions, you can further check such access:
> exportfs -c 192.168.208.51 /vol/vfilers/vf19 root exportfs: 192.168.208.51 has root access to /vol/vfilers/vf19
Every NFS request that comes across the wire results in an access check. To reduce name resolution calls, an access cache is created to store a clients access rights for an export. Access cache entries expire as controlled by the options:
nfs.export.neg.timeout
dictates how long an entry which has been
denied access lives
nfs.export.pos.timeout
dictates how long an entry which has been
granted access lives
If a client's IP is changed and there is still a long time before an expunging occurs, the cache entry can be flushed from the access cache:
> exportfs -f /vol/vfilers/vf19
If there has been a massive restructuring of the network architecture, all access cache entries may be flushed:
> exportfs -f
If a flush is tried while an access cache entry is being utilized, a message will be reported:
exportfs: Cache in use, please try again
If this message persists and the cache has to be flushed for new connections, then reloading the exports will force the cache to be reloaded:
> exportfs /vol/vfilers/vf19
All of the entries can be forced to flush as well:
> exportfs -a
Note that if -a is used, any exports loaded manually via the exportfs command will not be reloaded or flushed. These exports will have to be manually redone.
To aid in debugging why a particular host can not mount an export, you can temporarily set nfs.mountd.trace to on. The resulting log messages can help you trace down access problems.
A common access problem is that a host does not have a reverse DNS entry and as such, the hostname for the incoming Internet address can not be determined. Either add the host's name to DNS or add an entry into the /etc/hosts file.
Prior to ONTAP 6.5, when an export was loaded into memory, the -rw= and -root= entries underwent name lookups and the results were permamently stored with the export. If the names were changed, then until the exports were reloaded, the old values were used. Starting with ONTAP 6.5, this preloading of names no longer occurs. As a result, name changes can occur after an access cache entry is purged. One thing to note here is that for DNS lookups, as the order in the search field is changed in /etc/resolv.conf, then non-FQDN names may resolve to different hosts.