9. Sharing¶

9.1.1. Creating AFP Guest Shares¶

AFP supports guest logins, meaning that Mac OS X users can access the AFP share without requiring their user accounts to first be created on or imported into the TrueNAS^® system.

Before creating a guest share, go to Services → AFP and make sure that the Guest Access box is checked.

To create the AFP guest share, click Wizard, then click the Next button twice to display the screen shown in Figure 9.1.2. Complete these fields in this screen:

1. Share name: enter a name for the share that is identifiable but less than 27 characters long. This name cannot contain a period. In this example, the share is named afp_guest.
2. Click the button for Mac OS X (AFP).
3. Click the Ownership button. Click the drop-down User menu and select nobody. Click the Return button to return to the previous screen.
4. Click the Add button. The share is not created until the button is clicked. Clicking the Add button adds an entry to the Name frame with the name that was entered in Share name.

Fig. 9.1.2 Creating a Guest AFP Share

Click the Next button twice, then the Confirm button to create the share. The Wizard automatically creates a dataset for the share that contains the correct default permissions and starts the AFP service so the share is immediately available. The new share is also added as an entry to Sharing → Apple (AFP).

Mac OS X users can connect to the guest AFP share by clicking Go → Connect to Server. In the example shown in Figure 9.1.3, the user has entered afp:// followed by the IP address of the TrueNAS^® system.

Click the Connect button. Once connected, Finder opens automatically. The name of the AFP share is displayed in the SHARED section in the left frame and the contents of any data saved in the share is displayed in the right frame.

Fig. 9.1.3 Connect to Server Dialogue

To disconnect from the volume, click the eject button in the Shared sidebar.

9.1.2. Creating Authenticated and Time Machine Shares¶

Mac OS X includes the Time Machine application which can be used to schedule automatic backups. In this configuration example, a Time Machine user will be configured to backup to an AFP share on a TrueNAS^® system. It is recommended to create a separate Time Machine share for each user that will be using Time Machine to backup their Mac OS X system to TrueNAS^®. The process for creating an authenticated share for a user is the same as creating a Time Machine share for that user.

To use the Wizard to create an authenticated or Time Machine share, enter the following information, as seen in the example in Figure 9.1.4.

1. Share name: enter a name for the share that is identifiable but less than 27 characters long. The name cannot contain a period. In this example, the share is named backup_user1.
2. Click the button for Mac OS X (AFP) and check the box for Time Machine.
3. Click the Ownership button. If the user already exists on the TrueNAS^® system, click the drop-down User menu to select their user account. If the user does not yet exist on the TrueNAS^® system, type their name into the User field and check the Create User checkbox. If the user will be a member of a group that already exists on the TrueNAS^® system, click the drop-down Group menu to select the group name. To create a new group to be used by Time Machine users, enter the name in the Group field and check the Create Group checkbox. Otherwise, enter the same name as the user. In the example shown in Figure 9.1.5, both a new user1 user and a new tm_backups group will be created. Since a new user is being created, this screen prompts for the user password to be used when accessing the share. It also provides an opportunity to change the default permissions on the share. When finished, click Return to return to the screen shown in Figure 9.1.4.
4. Click the Add button. Remember to do this or the share will not be created. Clicking the Add button adds an entry to the Name frame with the name that was entered in Share name.

To configure multiple authenticated or Time Machine shares, repeat for each user, giving each user their own Share name and Ownership. When finished, click the Next button twice, then the Confirm button to create the shares. The Wizard automatically creates a dataset for each share with the correct ownership and starts the AFP service so the shares are immediately available. The new shares are also added to Sharing → Apple (AFP).

Fig. 9.1.4 Creating a Time Machine Share

Fig. 9.1.5 Creating an Authenticated User

At this point, it may be desirable to configure a quota for each Time Machine share, to restrict backups from using all of the available space on the TrueNAS^® system. The first time Time Machine makes a backup, it will create a full backup after waiting two minutes. It will then create a one hour incremental backup for the next 24 hours, and then one backup each day, each week and each month. Since the oldest backups are deleted when a Time Machine share becomes full, make sure that the quota size is sufficient to hold the desired number of backups. Note that a default installation of Mac OS X is ~21 GB in size.

To configure a quota, go to Storage → Volumes and highlight the entry for the share. In the example shown in Figure 9.1.6, the Time Machine share name is backup_user1. Click the Edit Options button for the share, then Advanced Mode. Enter a value in the Quota for this dataset field, then click Edit Dataset to save the change. In this example, the Time Machine share is restricted to 200 GB.

Fig. 9.1.6 Setting a Quota

To configure Time Machine on the Mac OS X client, go to System Preferences → Time Machine which opens the screen shown in Figure 9.1.7. Click ON and a pop-up menu shows the TrueNAS^® system as a backup option. In our example, it is listed as backup_user1 on “freenas”. Highlight the TrueNAS^® system and click Use Backup Disk. A connection bar opens and prompts for the user account’s password–in this example, the password that was set for the user1 account.

Fig. 9.1.7 Configuring Time Machine on Mac OS X Lion

If Time Machine could not complete the backup. The backup disk image could not be created (error 45) is shown when backing up to the TrueNAS^® system, a sparsebundle image must be created using these instructions.

If Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you. is shown, follow the instructions in this post to avoid making another backup or losing past backups.

9.2.1. Example Configuration¶

By default, the Mapall fields are not set. This means that when a user connects to the NFS share, the user has 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 option is to do this:

1. Specify the built-in nobody account to be used for NFS access.
2. In the Change Permissions screen of the volume/dataset that is being shared, change the owner and group to nobody and set the permissions according to your requirements.
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 user account and will only have the permissions that were 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.

9.2.2. Connecting to the Share¶

The following examples share this configuration:

1. The TrueNAS^® system is at IP address 192.168.2.2.
2. A dataset named /mnt/volume1/nfs_share1 is created and the permissions set to the nobody user account and the nobody group.
3. An NFS share is created with these attributes:
   • Path: /mnt/volume1/nfs_share1
   • Authorized Networks: 192.168.2.0/24
   • All Directories checkbox is checked
   • MapAll User is set to nobody
   • MapAll Group is set to nobody

mount -t nfs 192.168.2.2:/mnt/volume1/nfs_share1 /mnt

umount /mnt

9.2.2.3. From Mac OS X¶

To mount the NFS volume from a Mac OS X client, click on Go → Connect to Server. In the Server Address field, enter nfs:// followed by the IP address of the TrueNAS^® system and the name of the volume/dataset being shared by NFS. The example shown in Figure 9.2.3 continues with our example of 192.168.2.2:/mnt/volume1/nfs_share1.

Finder opens automatically after connecting. The IP address of the TrueNAS^® system is displayed in the SHARED section in the left frame and the contents of the share are displayed in the right frame. In the example shown in Figure 9.2.4, /mnt/data has one folder named images. The user can now copy files to and from the share.

Fig. 9.2.3 Mounting the NFS Share from Mac OS X

Fig. 9.2.4 Viewing the NFS Share in Finder

9.2.3. Troubleshooting NFS¶

Some NFS clients do not support the NLM (Network Lock Manager) protocol used by NFS. 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 to allow write access to the NFS share.

If a “time out giving up” error is shown when trying to mount the share from a Linux system, make sure that the portmapper service is running on the Linux client. If portmapper is running and timeouts are still shown, force the use of TCP by including -o tcp in the mount command.

If a “RPC: Program not registered” error is shown, upgrade to the latest version of TrueNAS^® and restart the NFS service after the upgrade to clear the NFS cache.

If clients see “reverse DNS” errors, add the TrueNAS^® IP address in the Host name database field of Network → Global Configuration.

If clients receive timeout errors when trying to mount the share, add the client IP address and hostname to the Host name data base field in Network → Global Configuration.

Some older versions of NFS clients default to UDP instead of TCP and do not auto-negotiate for TCP. By default, TrueNAS^® uses TCP. To support UDP connections, go to Services → NFS and check the box Serve UDP NFS clients.

The nfsstat -c or nfsstat -s commands can be helpful to detect problems from the Shell. A high proportion of retries and timeouts compared to reads usually indicates network problems.

9.4.1. Configuring Unauthenticated Access¶

SMB supports guest logins, meaning that users can access the SMB share without needing to provide a username or password. This type of share is convenient as it is easy to configure, easy to access, and does not require any users to be configured on the TrueNAS^® system. This type of configuration is also the least secure as anyone on the network can access the contents of the share. Additionally, since all access is as the guest user, even if the user inputs a username or password, there is no way to differentiate which users accessed or modified the data on the share. This type of configuration is best suited for small networks where quick and easy access to the share is more important than the security of the data on the share.

To configure an unauthenticated SMB share, click Wizard, then click the Next button twice to display the screen shown in Figure 9.4.2. Complete the following fields in this screen:

1. Share name: enter a name for the share that is useful to you. In this example, the share is named smb_insecure.
2. Click the button for Windows (SMB) and check the box for Allow Guest.
3. Click the Ownership button. Click the drop-down User menu and select nobody. Click the Return button to return to the previous screen.
4. Click the Add button. If you forget to do this, the share will not be created. Clicking the Add button adds an entry to the Name frame with the name that was entered in Share name.

Fig. 9.4.2 Creating an Unauthenticated SMB Share

Click the Next button twice, then the Confirm button to create the share. The Wizard automatically creates a dataset for the share and starts the SMB service so the share is immediately available. The new share is also be added to Sharing → Windows (SMB).

Users can now access the share from any SMB client and will not be prompted for their username or password. For example, to access the share from a Windows system, open Explorer and click on Network. For this configuration example, a system named FREENAS appears with a share named insecure_smb. The user can copy data to and from the unauthenticated SMB share.

9.4.2. Configuring Authenticated Access Without a Domain Controller¶

Most configuration scenarios require each user to have their own user account and to authenticate before accessing the share. This allows the administrator to control access to data, provide appropriate permissions to that data, and to determine who accesses and modifies stored data. A Windows domain controller is not needed for authenticated SMB shares, which means that additional licensing costs are not required. However, since there is no domain controller to provide authentication for the network, each user account needs to be created on the TrueNAS^® system. This type of configuration scenario is often used in home and small networks as it does not scale well if many users accounts are needed.

Before configuring this scenario, determine which users will need authenticated access. While not required for the configuration, it eases troubleshooting if the username and password that will be created on the TrueNAS^® system matches that information on the client system. Next, determine if each user should have their own share to store their own data or if several users will be using the same share. The simpler configuration is to make one share per user as it does not require the creation of groups, adding the correct users to the groups, and ensuring that group permissions are set correctly.

To use the Wizard to create an authenticated SMB share, enter the following information, as shown in the example in Figure 9.4.3.

1. Share name: enter a name for the share that is useful to you. In this example, the share is named smb_user1.
2. Click the button for Windows (SMB).
3. Click the Ownership button. To create the user account on the TrueNAS^® system, type their name into the User field and check the Create User checkbox. The user’s password is then entered and confirmed. If the user will not be sharing this share with other users, type their name into the Group field and click Create Group. If, however, the share will be used by several users, instead type in a group name and check the Create Group box. In the example shown in Figure 9.4.4, user1 has been used for both the user and group name, meaning that this share will only be used by user1. When finished, click Return to return to the screen shown in Figure 9.4.3.
4. Click the Add button. If you forget to do this, the share will not be created. Clicking the Add button adds an entry to the Name frame with the name that was entered in Share name.

If you wish to configure multiple authenticated shares, repeat for each user, giving each user their own Share name and Ownership. When finished, click Next twice, then Confirm to create the shares. The Wizard automatically creates a dataset with the correct ownership for each share and starts the SMB service so the shares are available immediately. The new shares are also added to Sharing → Windows (SMB).

Fig. 9.4.3 Creating an Authenticated SMB Share

Fig. 9.4.4 Creating the User and Group

The authenticated share can now be tested from any SMB client. For example, to test an authenticated share from a Windows system, open Explorer and click on Network. For this configuration example, a system named FREENAS appears with a share named smb_user1. If you click on smb_user1, a Windows Security pop-up screen prompts for that user’s username and password. Enter the values that were configured for that share, in this case user user1. After authentication, the user can copy data to and from the SMB share.

To prevent Windows Explorer from hanging when accessing the share, map the share as a network drive. To do this, right-click the share and select Map network drive.... Choose a drive letter from the drop-down menu and click the Finish button.

Note that Windows systems cache a user’s credentials. This can cause issues when testing or accessing multiple authenticated shares as only one authentication is allowed at a time. If you are having problems authenticating to a share and are sure that you are entering the correct username and password, type cmd in the Search programs and files box and use the following command to see if you have already authenticated to a share. In this example, the user has already authenticated to the smb_user1 share:

net use
New connections will be remembered.

Status         Local   Remote                  Network
------------------------------------------------------------------------
OK                     \\FREENAS\smb_user1 Microsoft Windows Network
The command completed successfully.

To clear the cache:

net use * /DELETE
You have these remote connections:
               \\FREENAS\smb_user1
Continuing will cancel the connections.

Do you want to continue this operation? <Y/N> [N]: y

An additional warning is shown if the share is currently open in Explorer:

There are open files and/or incomplete directory searches pending on the connection
to \\FREENAS|smb_user1.

Is it OK to continue disconnecting and force them closed? <Y/N> [N]: y
The command completed successfully.

The next time a share is accessed with Explorer, you will be prompted to authenticate.

9.4.3. Configuring Shadow Copies¶

Shadow Copies, also known as the Volume Shadow Copy Service (VSS) or Previous Versions, is a Microsoft service for creating volume snapshots. Shadow copies allow you to easily restore previous versions of files from within Windows Explorer. Shadow Copy support is built into Vista and Windows 7. Windows XP or 2000 users need to install the Shadow Copy client.

When you create a periodic snapshot task on a ZFS volume that is configured as a SMB share in TrueNAS^®, it is automatically configured to support shadow copies.

Before using shadow copies with TrueNAS^®, be aware of the following caveats:

• If the Windows system is not fully patched to the latest service pack, Shadow Copies may not work. If you are unable to see any previous versions of files to restore, use Windows Update to make sure that the system is fully up-to-date.
• Shadow copy support only works for ZFS pools or datasets. This means that the SMB share must be configured on a volume or dataset, not on a directory.
• Datasets are filesystems and shadow copies cannot traverse filesystems. If you want to be able to see the shadow copies in your child datasets, create separate shares for them.
• Shadow copies will not work with a manual snapshot, you must create a periodic snapshot task for the pool or dataset being shared by SMB or a recursive task for a parent dataset.
• The periodic snapshot task should be created and at least one snapshot should exist before creating the SMB share. If the SMB share was created first, restart the SMB service in Services → Control Services.
• Appropriate permissions must be configured on the volume/dataset being shared by SMB.
• Users cannot delete shadow copies on the Windows system due to the way Samba works. Instead, the administrator can remove snapshots from the TrueNAS^® administrative GUI. The only way to disable shadow copies completely is to remove the periodic snapshot task and delete all snapshots associated with the SMB share.

To configure shadow copy support, use the instructions in Configuring Authenticated Access Without a Domain Controller to create the desired number of shares. In this configuration example, a Windows 7 computer has two users: user1 and user2. For this example, two authenticated shares are created so that each user account has their own share. The first share is named user1 and the second share is named user2. Then:

1. Use Storage → Periodic Snapshot Tasks → Add Periodic Snapshot to create at least one periodic snapshot task. You can either create a snapshot task for each user’s dataset, in this example the datasets /mnt/volume1/user1 and /mnt/volume1/user2, or you can create one periodic snapshot task for the entire volume, in this case /mnt/volume1. Before continuing to the next step, confirm that at least one snapshot for each defined task is displayed in the Storage → Snapshots tab. When creating the schedule for the periodic snapshot tasks, keep in mind how often your users need to access modified files and during which days and time of day they are likely to make changes.
2. Go to Sharing → Windows (SMB) Shares. Highlight a share and click Edit, then Advanced Mode. Click the Periodic Snapshot Task drop-down menu and select the periodic snapshot task to use for that share. Repeat for each share being configured as a shadow copy. For this example, the share named /mnt/volume1/user1 is configured to use a periodic snapshot task that was configured to take snapshots of the /mnt/volume1/user1 dataset and the share named /mnt/volume1/user2 is configured to use a periodic snapshot task that was configured to take snapshots of the /mnt/volume1/user2 dataset.
3. Verify that the SMB service is set to ON in Services → Control Services.

Figure 9.4.5 provides an example of using shadow copies while logged in as user1 on the Windows system. In this example, the user right-clicked modified file and selected Restore previous versions from the menu. This particular file has three versions: the current version, plus two previous versions stored on the TrueNAS^® system. The user can choose to open one of the previous versions, copy a previous version to the current folder, or restore one of the previous versions, overwriting the existing file on the Windows system.

Fig. 9.4.5 Viewing Previous Versions within Explorer

9.5.1. Target Global Configuration¶

Sharing → Block (iSCSI) → Target Global Configuration, shown in Figure 9.5.1, contains settings that apply to all iSCSI shares. Table 9.5.1 summarizes the settings that can be configured in the Target Global Configuration screen.

Some built-in values affect iSNS usage. Fetching of allowed initiators from iSNS is not implemented, so target ACLs must be configured manually. To make iSNS registration useful, iSCSI targets should have explicitly configured port IP addresses. This avoids initiators attempting to discover unconfigured target portal addresses like 0.0.0.0.

The iSNS registration period is 900 seconds. Registered Network Entities not updated during this period are unregistered. The timeout for iSNS requests is 5 seconds.

Fig. 9.5.1 iSCSI Target Global Configuration Variables

9.5.2. Portals¶

A portal specifies the IP address and port number to be used for iSCSI connections. Sharing → Block (iSCSI) → Portals → Add Portal brings up the screen shown in Figure 9.5.2.

Table 9.5.2 summarizes the settings that can be configured when adding a portal. If you need to assign additional IP addresses to the portal, click the link Add extra Portal IP.

Fig. 9.5.2 Adding an iSCSI Portal

TrueNAS^® systems with multiple IP addresses or interfaces can use a portal to provide services on different interfaces or subnets. This can be used to configure multi-path I/O (MPIO). MPIO is more efficient than a link aggregation.

If the TrueNAS^® system has multiple configured interfaces, portals can also be used to provide network access control. For example, consider a system with four interfaces configured with the following addresses:

192.168.1.1/24

192.168.2.1/24

192.168.3.1/24

192.168.4.1/24

You could create a portal containing the first two IP addresses (group ID 1) and a portal containing the remaining two IP addresses (group ID 2). You could then create a target named A with a Portal Group ID of 1 and a second target named B with a Portal Group ID of 2. In this scenario, the iSCSI service would listen on all four interfaces, but connections to target A would be limited to the first two networks and connections to target B would be limited to the last two networks.

Another scenario would be to create a portal which includes every IP address except for the one used by a management interface. This would prevent iSCSI connections to the management interface.

9.5.3. Initiators¶

The next step is to configure authorized initiators, or the systems which are allowed to connect to the iSCSI targets on the TrueNAS^® system. To configure which systems can connect, use Sharing → Block (iSCSI) → Initiators → Add Initiator, shown in Figure 9.5.3.

Fig. 9.5.3 Adding an iSCSI Initiator

Table 9.5.3 summarizes the settings that can be configured when adding an initiator.

In the example shown in Figure 9.5.4, two groups have been created. Group 1 allows connections from any initiator on any network. Group 2 allows connections from any initiator on the 10.10.1.0/24 network. Click an initiator’s entry to display its Edit and Delete buttons.

Fig. 9.5.4 Sample iSCSI Initiator Configuration

9.5.4. Authorized Accesses¶

If you will be using CHAP or mutual CHAP to provide authentication, you must create an authorized access in Sharing → Block (iSCSI) → Authorized Accesses → Add Authorized Access. This screen is shown in Figure 9.5.5.

Fig. 9.5.5 Adding an iSCSI Authorized Access

Table 9.5.4 summarizes the settings that can be configured when adding an authorized access:

As authorized accesses are added, they will be listed under View Authorized Accesses. In the example shown in Figure 9.5.6, three users (test1, test2, and test3) and two groups (1 and 2) have been created, with group 1 consisting of one CHAP user and group 2 consisting of one mutual CHAP user and one CHAP user. Click an authorized access entry to display its Edit and Delete buttons.

Fig. 9.5.6 Viewing Authorized Accesses

9.5.5. Targets¶

Next, create a Target using Sharing → Block (iSCSI) → Targets → Add Target, as shown in Figure 9.5.7. A target combines a portal ID, allowed initiator ID, and an authentication method. Table 9.5.5 summarizes the settings that can be configured when creating a Target.

Fig. 9.5.7 Adding an iSCSI Target

9.5.6. Extents¶

iSCSI targets provide virtual access to resources on the TrueNAS^® system. Extents are used to define resources to share with clients. There are two types of extents: device and file.

Device extents provide virtual storage access to zvols, zvol snapshots, or physical devices like a disk, an SSD, a hardware RAID volume, or a HAST device.

File extents provide virtual storage access to an individual file.

Virtualized zvols support all the TrueNAS^® VAAI primitives and are recommended for use with virtualization software as the iSCSI initiator.

The ATS, WRITE SAME, XCOPY and STUN, primitives are supported by both file and device extents. The UNMAP primitive is supported by zvols and raw SSDs. The threshold warnings primitive is fully supported by zvols and partially supported by file extents.

Virtualizing a raw device like a single disk or hardware RAID volume limits performance to the abilities of the device. Because this bypasses ZFS, such devices do not benefit from ZFS caching or provide features like block checksums or snapshots.

Virtualizing a zvol adds the benefits of ZFS, such as read and write cache. Even if the client formats a device extent with a different filesystem, the data still resides on a ZFS volume and benefits from ZFS features like block checksums and snapshots.

To add an extent, go to Sharing → Block (iSCSI) → Extents → Add Extent. In the example shown in Figure 9.5.8, the device extent is using the export zvol that was previously created from the /mnt/volume1 volume.

Table 9.5.6 summarizes the settings that can be configured when creating an extent. Note that file extent creation will fail if you do not append the name of the file to be created to the volume/dataset name.

Fig. 9.5.8 Adding an iSCSI Extent

9.5.7. Target/Extents¶

The last step is associating an extent to a target within Sharing → Block (iSCSI) → Associated Targets → Add Target/Extent. This screen is shown in Figure 9.5.9. Use the drop-down menus to select the existing target and extent. Click OK to add an entry for the LUN.

Fig. 9.5.9 Associating a Target With an Extent

Table 9.5.7 summarizes the settings that can be configured when associating targets and extents.

It is recommended to always associate extents to targets in a one-to-one manner, even though the GUI will allow multiple extents to be associated with the same target.

After iSCSI has been configured, remember to start it in Services → Control Services. Click the red OFF button next to iSCSI. After a second or so, it will change to a blue ON, indicating that the service has started.

9.5.8. Fibre Channel Ports¶

If the TrueNAS^® system has Fibre Channel ports, Sharing → Block (iSCSI) will appear as Sharing → Block (iSCSI/FC) and an extra Fibre Channel Ports tab is added. An example is shown in Figure 9.5.10.

Fig. 9.5.10 Block (iSCSI) Screen

Otherwise, the Target Global Configuration screen is the same as described in Target Global Configuration.

Since the Portals, Initiators, and Authorized Access screens only apply to iSCSI, they are marked as such and can be ignored when configuring Fibre Channel.

As seen in Figure 9.5.11, the Targets → Add Target screen has an extra Target Mode option for indicating whether the target to create is iSCSI, Fibre Channel, or both.

Fig. 9.5.11 Add Target Screen

If you select Fibre Channel, this screen will change so only the Target Name and Target Alias fields remain, as those are the only applicable fields for a Fibre Channel connection. An example is shown in Figure 9.5.12.

Fig. 9.5.12 Configuring a Fibre Channel Target

The screens for adding an extent and associating a target are the same as described in Extents and Target/Extents.

An example of the Fibre Channel Ports screen is shown in Figure 9.5.13.

Fig. 9.5.13 Configuring a Fibre Channel Port

This screen shows the status of each attached fibre channel port, where:

• Initiator: indicates that the port is acting as a client and has access to any physically attached storage.
• Target: indicates that clients are connecting to the specified target through this port.
• Disabled: indicates that this fibre channel port is not in use.

This example has also been configured for NPIV (N_Port ID Virtualization). Note that the physical interface isp0 has two virtual ports (isp0/1 and isp0/2) displayed in Figure 9.5.13:. NPIV allows the administrator to use switch zoning to configure each virtual port as if it was a physical port in order to provide access control. This is important in an environment with a mix of Windows systems and virtual machines in order to prevent automatic or accidental reformatting of targets containing unrecognized filesystems. It can also be used to segregate data; for example, to prevent the engineering department from accessing data from the human resources department. Refer to your switch documentation for details on how to configure zoning of virtual ports.

To create the virtual ports on the TrueNAS^® system, go to System → Tunables → Add Tunable and enter the following:

• Variable: input hint.isp.X.vports, replacing X with the number of the physical interface.
• Value: input the number of virtual ports to create. Note that there cannot be more then 125 SCSI target ports and that number includes all physical Fibre Channel ports, all virtual ports, and all configured combinations of iSCSI portals and targets.
• Type: make sure loader is selected.

In the example shown in Figure 9.5.14, two physical interfaces were each assigned 4 virtual ports. Note that two tunables were required, one for each physical interface. After the tunables are created, the configured number of virtual ports appears in the Fibre Channel Ports screen so they can be associated with targets. They will also be advertised to the switch so zoning can be configured on the switch. After a virtual port has been associated with a target, it is added to the Target tab of Reporting where its bandwidth usage can be viewed.

Fig. 9.5.14 Adding Virtual Ports

9.5.9. Connecting to iSCSI¶

To access the iSCSI target, clients must use iSCSI initiator software.

An iSCSI Initiator client is pre-installed with Windows 7. A detailed how-to for this client can be found here. A client for Windows 2000, XP, and 2003 can be found here. This how-to shows how to create an iSCSI target for a Windows 7 system.

Mac OS X does not include an initiator. globalSAN is a commercial, easy-to-use Mac initiator.

BSD systems provide command line initiators: iscontrol(8) comes with FreeBSD versions 9.x and lower, iscsictl(8) comes with FreeBSD versions 10.0 and higher, iscsi-initiator(8) comes with NetBSD, and iscsid(8) comes with OpenBSD.

Some Linux distros provide the command line utility iscsiadm from Open-iSCSI. Use a web search to see if a package exists for your distribution should the command not exist on your Linux system.

If a LUN is added while iscsiadm is already connected, it will not see the new LUN until rescanned with iscsiadm -m node -R. Alternately, use iscsiadm -m discovery -t st -p portal_IP to find the new LUN and iscsiadm -m node -T LUN_Name -l to log into the LUN.

Instructions for connecting from a VMware ESXi Server can be found at How to configure FreeNAS 8 for iSCSI and connect to ESX(i). Note that the requirements for booting vSphere 4.x off iSCSI differ between ESX and ESXi. ESX requires a hardware iSCSI adapter while ESXi requires specific iSCSI boot firmware support. The magic is on the booting host side, meaning that there is no difference to the TrueNAS^® configuration. See the iSCSI SAN Configuration Guide for details.

The VMware firewall only allows iSCSI connections on port 3260 by default. If a different port has been selected, outgoing connections to that port must be manually added to the firewall before those connections will work.

If the target can be seen but does not connect, check the Discovery Auth settings in Target Global Configuration.

If the LUN is not discovered by ESXi, make sure that promiscuous mode is set to Accept in the vSwitch.

9.5.10. Growing LUNs¶

The method used to grow the size of an existing iSCSI LUN depends on whether the LUN is backed by a file extent or a zvol. Both methods are described in this section.

Enlarging a LUN with one of the methods below gives it more unallocated space, but does not automatically resize filesystems or other data on the LUN. This is the same as binary-copying a smaller disk onto a larger one. More space is available on the new disk, but the partitions and filesystems on it must be expanded to use this new space. Resizing virtual disk images is usually done from virtual machine management software. Application software to resize filesystems is dependent on the type of filesystem and client, but is often run from within the virtual machine. For instance, consider a Windows VM with the last partition on the disk holding an NTFS filesystem. The LUN is expanded and the partition table edited to add the new space to the last partition. The Windows disk manager must still be used to resize the NTFS filesystem on that last partition to use the new space.

9.5.10.1. Zvol Based LUN¶

To grow a zvol based LUN, go to Storage → Volumes → View Volumes, highlight the zvol to be grown, and click Edit zvol. In the example shown in Figure 9.5.15, the current size of the zvol named zvol1 is 4GB.

Fig. 9.5.15 Editing an Existing Zvol

Enter the new size for the zvol in the Size field and click Edit ZFS Volume. This menu closes and the new size for the zvol is immediately shown in the Used column of the View Volumes screen.

Note

The GUI does not allow reducing (shrinking) the size of the zvol, as doing so could result in loss of data. It also does not allow increasing the size of the zvol past 80% of the volume size.

truncate -s +2g /mnt/volume1/data