Unix (NFS) Shares
FreeNAS® supports the Network File System (NFS) for sharing volumes over a network. Once the NFS share is configured, clients use the mount command to mount the share. Once mounted, the share appears as just another directory on the client system. Some Linux distros require the installation of additional software in order to mount an NFS share. On Windows systems, enable Services for NFS in the Ultimate or Enterprise editions or install an NFS client application.
NOTE: for performance reasons, iSCSI is preferred to NFS shares when FreeNAS is installed on ESXi. If you are considering creating NFS shares on ESXi, read through the performance analysis at Running ZFS over NFS as a VMware Store.
Configuring NFS is a multi-step process that requires you to create NFS share(s), configure NFS, then start NFS in Services → Control Panel. It does not require you to create users or groups as NFS uses IP addresses to determine which systems are allowed to access the NFS share.
This section demonstrates how to create an NFS share, provides a configuration example, demonstrates how to connect to the share from various operating systems, and provides some troubleshooting tips.
To create an NFS share, click Sharing → Unix (NFS) Shares → Add Unix (NFS) Share, shown in Figure 7.2a.
Figure 7.2a: Creating an NFS Share
Once you press the OK button when creating the NFS share, a pop-up menu will ask "Would you like to enable this service?" Click Yes and Services → Control Services will open and indicate whether or not the NFS service successfully started.
Table 7.2a summarizes the options in this screen.
Table 7.2a: NFS Share Options
|Comment||string||used to set the share name; if left empty, share name will be the list of selected Paths|
|Authorized networks||string||a space delimited list of allowed network addresses in the form 220.127.116.11/24 where the number after the slash is a CIDR mask|
|Authorized IP addresses or hosts||string||a space delimited list of allowed IP addresses or hostnames|
|All directories||checkbox||if checked, the client can mount any subdirectory within the Path|
|Read only||checkbox||prohibits writing to the share|
|Quiet||checkbox||inhibits some syslog diagnostics which can be useful to avoid some annoying error messages; see exports(5) for examples|
|Maproot User||drop-down menu||if a user is selected, the root user is limited to that user's permissions|
|Maproot Group||drop-down menu||if a group is selected, the root user will also be limited to that group's permissions|
|Mapall User||drop-down menu||the specified user's permissions are used by all clients|
|Mapall Group||drop-down menu||the specified group's permission are used by all clients|
|Path||browse button||browse to the volume/dataset/directory to share; click “Add extra path” to select multiple paths|
When creating the NFS share, keep the following restrictions in mind:
1. The Maproot and Mapall options are exclusive, meaning you can only use one or the other--the GUI will not let you use both. The Mapall options supersede the Maproot options. If you only wish to restrict the root user's permissions, set the Maproot option. If you wish to restrict the permissions of all users, set the Mapall option.
2. Each volume or dataset is considered to be its own filesystem and NFS is not able to cross filesystem boundaries.
3. The network or host must be unique per share and per filesystem or directory.
4. The "All directories" option can only be used once per share per filesystem.
To better understand these restrictions, consider the following scenario where there are:
- 2 networks named 10.0.0.0/8 and 18.104.22.168/8
- a ZFS volume named volume1 with 2 datasets named dataset1 and dataset2
- dataset1 has a directory named directory1
Because of restriction #3, you will receive an error if you try to create one NFS share as follows:
- Authorized networks: 10.0.0.0/8,22.214.171.124/8
- Path: /mnt/volume1/dataset1 and /mnt/volume1/dataset1/directory1
Instead, you should select the Path of /mnt/volume1/dataset1 and check the "All directories" box.
However, you could restrict that directory to one of the networks by creating two shares as follows.
First NFS share:
- Authorized networks: 10.0.0.0/8
- Path: /mnt/volume1/dataset1
Second NFS share:
- Authorized networks: 126.96.36.199/8
- Path: /mnt/volume1/dataset1/directory1
Note that this requires the creation of two shares as it can not be accomplished in one share.
By default the Mapall options shown in Figure 7.2a show as N/A. This means that when a user connects to the NFS share, they connect with the permissions associated with their user account. This is a security risk if a user is able to connect as root as they will have complete access to the share.
A better scenario is to do the following:
1. Specify the built-in nobody account to be used for NFS access.
2. In the permissions of the volume/dataset that is being shared, change the owner and group to nobody and set the permissions according to your specifications.
3. Select nobody in the Mapall User and Mapall Group drop-down menus for the share in Sharing → Unix (NFS) Shares.
With this configuration, it does not matter which user account connects to the NFS share, as it will be mapped to the nobody account and will only have the permissions that you specified on the volume/dataset. For example, even if the root user is able to connect, it will not gain root access to the share.
In the following examples, an NFS share on a FreeNAS® system with the IP address of 192.168.2.2 has been configured as follows:
1. A ZFS volume named /mnt/data has its permissions set to the nobody user account and the nobody group.
2. A NFS share has been created with the following attributes:
- Path: /mnt/data
- Authorized Network: 192.168.2.0/24
- MapAll User and MapAll Group are both set to nobody
- the All Directories checkbox has been checked
From BSD or Linux Clients
To make this share accessible on a BSD or a Linux system, run the following command as the superuser (or with sudo) from the client system (repeat for each client that needs access to the NFS share):
mount -t nfs 192.168.2.2:/mnt/data /mnt
The mount command uses the following options:
- -t nfs: specifies the type of share.
- 192.168.2.2: replace with the IP address of the FreeNAS® system
- /mnt/data: replace with the name of the NFS share
- /mnt: a mount point on the client system. This must be an existing, empty directory. The data in the NFS share will be made available to the client in this directory.
The mount command should return to the command prompt without any error messages, indicating that the share was successfully mounted.
Once mounted, this configuration allows users on the client system to copy files to and from /mnt (the mount point) and all files will be owned by nobody:nobody. Any changes to /mnt will be saved to the FreeNAS® system's /mnt/data volume.
Should you need to make any changes to the NFS share's settings or wish to make the share inaccessible, first unmount the share on each client as the superuser:
From Microsoft Clients
Enterprise versions of Windows systems can connect to NFS shares using Services for NFS. Connecting to NFS shares is often faster than connecting to CIFS shares due to the single-threaded limitation of Samba. Instructions for connecting from an Enterprise version of Windows 7 can be found at Mount Linux NFS Share on Windows 7.
NOTE: Services for NFS is only available in the Ultimate or Enterprise editions of Windows.
If your Windows client is running a Home Edition of Windows 7, Nekodrive provides an open source graphical NFS client. To use this client, you will need to install the following on the Windows system:
- 7zip to extract the Nekodrive download files
- NFSClient and NFSLibrary from the Nekodrive download page; once downloaded, extract these files using 7zip
Once everything is installed, run the NFSClient executable to start the GUI client. In the example shown in Figure 7.2b, the user has connected to the example /mnt/data share of the FreeNAS® system at 192.168.2.2.
Figure 7.2b: Using the Nekodrive NFSClient from Windows 7 Home Edition
From Mac OS X Clients
To mount the NFS volume from a Mac OS X client, click on Go → Connect to Server. In the Server Address field, input nfs:// followed by the IP address of the FreeNAS® system and the name of the volume/dataset being shared by NFS. The example shown in Figure 7.2c continues with our example of 192.168.2.2:/mnt/data:
Figure 7.2c: Mounting the NFS Share from Mac OS X
Once connected, Finder will automatically open. The IP address of the FreeNAS® system will be displayed in the SHARED section in the left frame and the contents of the share will be displayed in the right frame. In the example shown in Figure 7.2d /mnt/data has one folder named images. The user can now copy files to and from the share.
Figure 7.2d: Viewing the NFS Share in Finder
Some NFS clients do not support the NLM (Network Lock Manager) protocol used by NFS. You will know that this is the case if the client receives an error that all or part of the file may be locked when a file transfer is attempted. To resolve this error, add the option -o nolock when running the mount command on the client in order to allow write access to the NFS share.
If you receive an error about a "time out giving up" when trying to mount the share from a Linux system, make sure that the portmapper service is running on the Linux client and start it if it is not. If portmapper is running and you still receive timeouts, force it to use TCP by including -o tcp in your mount command.
If you receive an error "RPC: Program not registered", upgrade to the latest version of FreeNAS® and restart the NFS service after the upgrade in order to clear the NFS cache.
If your clients are receiving "reverse DNS" or timeout errors, add an entry for the IP address of the FreeNAS® system in the "Host name database" field of Network → Global Configuration.