Sun Storage 7000 Unified Storage System: Configuring NFS Exceptions for root access

Asset ID:	1-71-1439295.1
Update Date:	2017-02-18
Keywords:

Solution Type Technical Instruction Sure

Solution 1439295.1 : Sun Storage 7000 Unified Storage System: Configuring NFS Exceptions for root access

Applies to:

Sun Storage 7110 Unified Storage System - Version All Versions and later
Sun Storage 7410 Unified Storage System - Version All Versions and later
Sun ZFS Storage 7120 - Version All Versions and later
Sun ZFS Storage 7320 - Version All Versions and later
Sun ZFS Storage 7420 - Version All Versions and later
7000 Appliance OS (Fishworks)

Goal

This document explains how to provide root access to NFS mounted clients, and also the concepts of root squash and NFS exceptions on the ZFS-SA.

Solution

The image below is an example of the NFS section of the Shares/Properties screen in the BUI:

The first thing to check or select is the Share Mode. The options are read/write, read only and none. In most cases, we'll select the first option, read/write.

By default, the share is configured for root squash. Root squash is a standard NFS server behavior that prevents root on client machines from having privileged access to exported files. Servers do this by mapping the "root" user to some unprivileged user (usually the user "nobody") on the server side.

The user that non-trusted root is mapped to can be configured on this screen under "Anonymous User Mapping". This should only be changed in environments where a different account for a non-privileged user is used.

IMPORTANT: DO NOT use "root" for Anonymous User Mapping. This will give virtually unlimited root access for all clients to every file on the share.

To properly allow root access for selected clients, an exception to the standard read/write/no root share mode must be configured. This is done by adding NFS Exceptions. As shown in the example, this can be done for a single host, a netgroup, an entire domain or a network address.

The network address is the preferred method, as hostnames and domain names need to be resolved from incoming IP addresses, which adds a small delay and creates a dependency on name resolution. The network addresses use CIDR notation, which list the network address and the length of the subnet mask in decimal. The two examples above show a class C subnet (/24), and a single host (/32).

NOTE: This process was used, but the customer was still getting "operation not permitted" when root would try to change ownership - or denied when changing permissions. When we changed from FQDN in the BUI to Network and placed the IP address instead, it worked fine. The issue was that there was no reverse lookup entry for this client in DNS.

Other exceptions besides root access can also be configured. The above example includes read only exceptions. It is also possible to flip this around, creating the Share Mode as read only, and allowing read/write access on an exception basis only.

PLEASE NOTE: The ordering of the exceptions is important.

Exceptions to the overall sharing modes may be defined for clients or collections of clients.

When a client attempts access, its access will be granted according to the first exception in the list that matches the client.

Attachments

This solution has no attachment