Export volumes

Mapping volumes for export

Appliance export settings allow machines to mount disk partitions in the same way that an NFS server does. The appliance maps from a unique name to a volume on an NFS server. All deployments require you to configure at least one export on the appliance, but also allow you to configure multiple export volumes.

Export settings

Export settings are virtual and do not reflect actual volumes that exist on the cache. A volume on an origin server can be used by many exports. Once export settings are configured, MOUNT, NFS, and PORTMAP requests are then directed to the appliance, which either responds or proxies the request to the origin server, and then responds to the client.

How an NFS request is made

The following example illustrates the connect sequence or handshake that occurs the first time a client sends an NFS request to a server.

Stage	Description
1	Client asks the server (PORTMAP) what services are available.
2	Server (PORTMAP) responds that MOUNT v1 and v3, NFS v2 and v3, TCP, and UDP are available.
3	Client asks server (MOUNT) to mount /vol/vol0.
4	Server (MOUNT) responds with a file handle for /vol/vol0.
5	Client requests server (NFS) to perform operation x on <file handle> with parameters <params>.
6	Server (NFS) responds with the <results of operation>.

Command options and syntax

The following table provides an in-depth description of each element in the export command syntax.

Command	Description
<virtual export name>	The name of the volume that a client will mount on the appliance itself.
<origin server name>	The name of the NFS server where this volume actually exists.
<origin server path>	The path to the volume on the NFS server.
<options>	There are several options you can specify per volume. Network Appliance supports the following mount options. Note The following values are optional and can be configured from the Appliance Manager, or entered from the command line as a comma separated list.
Maximum age Time before reverification of objects CLI: max-age=#	This option enables you to set the amount of time the cache will answer a request without verifying the content with the origin server. If all of the traffic for this particular volume will be sent through the appliance, set the max-age value as high as possible. If you are modifying the volume on the origin server directly, the value should be set lower. If the value is set to 0, the cache revalidates every request. Standard client caches cache directories from 30 to 60 seconds and files from 10 to 30 seconds. Enter a number and an alphabetical character to indicate the unit (s = seconds, m = minutes, h = hours, d = days). The default setting, 30 seconds, is used when no unit is indicated.
Disconnected operations Type of behavior when servers are down CLI: hard, firm, or soft	This option allows you to determine the type of behavior the cache will exhibit when its connection to the origin server is lost. You can select from the list options: Hard: Cache blocks any operation that attempts to communicate with the origin server (default). Firm: Cache serves cached data only. All other attempts to communicate with the origin server are blocked. Soft: Cache serves cached data only, and returns error messages to the client for all other attempts to communicate with the origin server. Note The consistency model for firm and soft settings is relaxed. This means that data is consistent, but content served is potentially out of date with respect to content on the origin server.
Anon UID Uid to use for requests with root uid CLI: anon=<uid>	This option enables you to specify the UID from which to translate requests from root. If you want root to be trusted on this volume, set `anon=0`. If you want root to be interpreted as the UNIX® user, set `anon=65535` (default).
Mount access Hosts allowed to mount this volume CLI: access=<host list>	Mount access -- This option enables you to set all mount requests to be rejected unless they come from the root user. Example: <hostname \| netgroup \| ip_address \| ip_address/bits> where host name is "company.com", netgroup is "groupname", IP address is "10.1.27.5", and IP_address/bits is "10.1.27/24" The hosts listed are the only hosts allowed to mount the volume. The default is everyone.
Root access Hosts with root access to this volume CLI: root=<host list>	Root access -- This option enables you to set a list of client IPs with root access to the specified volume. Example: <hostname \| netgroup \| ip_address \| ip_address/bits> where host name is "company.com", netgroup is "groupname", IP address is "10.1.27.5", and IP_address/bits is "10.1.27/24" The hosts listed are the only clients that are trusted with user root.
Read-write access Hosts with read/write access to this volume CLI: rw=<host list>	This option enables you to set a list of client IPs with write access. Example: <hostname \| netgroup \| ip_address \| ip_address/bits> where host name is "company.com", netgroup is "groupname", IP address is "10.1.27.5", and IP_address/bits is "10.1.27/24" The hosts listed are the only clients allowed to write to the file system. All other clients have only read-only access.
Read-only Restrict access for this volume to be read only CLI: ro	This option specifies to export a volume as read-only. The appliance rejects all operations that would modify the file system, such as writing a file or creating a directory.
Bridging Always use TCP to connect to origin server CLI: tcp	This option upgrades all connections between the appliance and server to TCP, regardless of the protocol that the client used to connect to the appliance. It is designed to be used over a WAN where UDP connections are unreliable. Note The appliance uses the same transport protocol to connect to the server that the client used to connect to the appliance. If you configure the export to use TCP to connect to the server, then the appliance uses TCP to connect to the server, regardless of what protocol the client used to connect to the appliance. If the server does not support TCP, the appliance detects this and uses UDP to connect to that server, regardless of what the client used.
Verification schedule Cron style entries for scheduling (reverification of objects) CLI: verify_sched= <cron entry>	This option enables you to set the schedule the appliance will use to determine when to reverify requested objects. A cron entry is a combination of the following: <minute><hour><day of month><month><year><day of week> or * for wild card. For example, `30 1 * * * 0` = every Sunday at 1:30 a.m. Use a larger max-age (the default max-age becomes infinite) if you can schedule times for objects on an export to become unverified.

Command

Description

The name of the volume that a client will mount on the appliance itself.

The name of the NFS server where this volume actually exists.

The path to the volume on the NFS server.

There are several options you can specify per volume. Network Appliance supports the following mount options.

Note
The following values are optional and can be configured from the Appliance Manager, or entered from the command line as a comma separated list.

Maximum age

Time before reverification of objects

CLI: max-age=#

This option enables you to set the amount of time the cache will answer a request without verifying the content with the origin server.

If all of the traffic for this particular volume will be sent through the appliance, set the max-age value as high as possible. If you are modifying the volume on the origin server directly, the value should be set lower. If the value is set to 0, the cache revalidates every request.

Standard client caches cache directories from 30 to 60 seconds and files from 10 to 30 seconds. Enter a number and an alphabetical character to indicate the unit (s = seconds, m = minutes, h = hours, d = days). The default setting, 30 seconds, is used when no unit is indicated.

Disconnected operations

Type of behavior when servers are down

CLI: hard, firm, or soft

This option allows you to determine the type of behavior the cache will exhibit when its connection to the origin server is lost. You can select from the list options:

Hard: Cache blocks any operation that attempts to communicate with the origin server (default).

Firm: Cache serves cached data only. All other attempts to communicate with the origin server are blocked.

Soft: Cache serves cached data only, and returns error messages to the client for all other attempts to communicate with the origin server.

Note
The consistency model for firm and soft settings is relaxed. This means that data is consistent, but content served is potentially out of date with respect to content on the origin server.

Anon UID

Uid to use for requests with root uid

CLI: anon=<uid>

This option enables you to specify the UID from which to translate requests from root.

If you want root to be trusted on this volume, set anon=0. If you want root to be interpreted as the UNIX® user, set anon=65535 (default).

Mount access

Hosts allowed to mount this volume

CLI: access=<host list>

Mount access -- This option enables you to set all mount requests to be rejected unless they come from the root user.

Example: <hostname | netgroup | ip_address | ip_address/bits>

where host name is "company.com", netgroup is "groupname", IP address is "10.1.27.5", and IP_address/bits is "10.1.27/24"

The hosts listed are the only hosts allowed to mount the volume. The default is everyone.

Root access

Hosts with root access to this volume

CLI: root=<host list>

Root access -- This option enables you to set a list of client IPs with root access to the specified volume.

Example: <hostname | netgroup | ip_address | ip_address/bits>

where host name is "company.com", netgroup is "groupname", IP address is "10.1.27.5", and IP_address/bits is "10.1.27/24"

The hosts listed are the only clients that are trusted with user root.

Read-write access

Hosts with read/write access to this volume

CLI: rw=<host list>

This option enables you to set a list of client IPs with write access.

Example: <hostname | netgroup | ip_address | ip_address/bits>

where host name is "company.com", netgroup is "groupname", IP address is "10.1.27.5", and IP_address/bits is "10.1.27/24"

The hosts listed are the only clients allowed to write to the file system. All other clients have only read-only access.

Read-only

Restrict access for this volume to be read only

CLI: ro

This option specifies to export a volume as read-only.

The appliance rejects all operations that would modify the file system, such as writing a file or creating a directory.

Bridging

Always use TCP to connect to origin server

CLI: tcp

This option upgrades all connections between the appliance and server to TCP, regardless of the protocol that the client used to connect to the appliance. It is designed to be used over a WAN where UDP connections are unreliable.

Note
The appliance uses the same transport protocol to connect to the server that the client used to connect to the appliance. If you configure the export to use TCP to connect to the server, then the appliance uses TCP to connect to the server, regardless of what protocol the client used to connect to the appliance. If the server does not support TCP, the appliance detects this and uses UDP to connect to that server, regardless of what the client used.

Verification schedule

Cron style entries for scheduling (reverification of objects)

CLI: verify_sched= <cron entry>

This option enables you to set the schedule the appliance will use to determine when to reverify requested objects.

A cron entry is a combination of the following: <minute><hour><day of month><month><year><day of week> or * for wild card.

For example, 30 1 * * * 0 = every Sunday at 1:30 a.m.

Use a larger max-age (the default max-age becomes infinite) if you can schedule times for objects on an export to become unverified.

Caution
The appliance access options supersede the origin server access options. On hits, only the appliance options root, anon, and access matter; on misses, the server and appliance options both matter. This means that unless the file server and the appliance have the same options, security holes could exist.