Nasuni Connector

The latest information on Nasuni Connector configuration can be found at Nasuni_Access_Anywhere_Getting_Started.pdf.

last updated May, 2024

Nasuni replaces traditionally isolated, fixed, network-attached storage (NAS) and filesystems with a unified, infinitely scalable, cloud-based global file services platform. Users and applications access this globally shared data through Nasuni Edge appliances deployed in data centers and offices all around the world. The Edge appliances provide local SMB access to data, caching active files and metadata for fast access.

Nasuni Access Anywhere platform extends the Nasuni global file system, supporting remote, mobile, and offline workers.

The Nasuni connector has been purpose-built and optimized for the Nasuni global file system. It supports single-sign-on, real-time permission synchronization, identity propagation, and SMB encryption in addition to standard Access Anywhere features including real-time refresh and content search.

Overview

The Nasuni connector provides end-users with access to their data stored within the Nasuni platform via Nasuni Access Anywhere and its' multiple channels of access, including web, desktop, and mobile.

The connector binds Identity and Access Management from Nasuni Access Anywhere (integrated via Active Directory / LDAP integration) with the permissions of the underlying file shares to provide users with secure access to the Nasuni data, whilst ensuring that users only see and access data that they have permissions to from the underlying shares.

Administrators will continue to manage and maintain file share permissions directly from the Nasuni file shares. Furthermore, any changes made on the Nasuni file shares, whether file, folders, or permissions related are reflected immediately within Nasuni Access Anywhere.

Prerequisites

Nasuni Access Anywhere requirements:

  • Organization Administrator account (not a member with admin role)
  • Organization connected to your Active Directory via the LDAP Auth Connector.
  • AD Administrative account
  • Nasuni Edge Appliance

Adding the Nasuni Connector

To begin adding the Nasuni connector, it must first be enabled in your applicable Package from your appladmin account. In the Package options, ensure that the Nasuni connector is checked for it to be available to the organization.

Next, log into the Organization Admin account, visit the Dashboard and click the Add new provider button.

From the dropdown list, select Nasuni and then click Add provider.

On the next screen, you will be presented with the following fields:

  • Name — This will be the friendly name of the provider. Your users will see this inside of their accounts.
  • Username - The Nasuni provider will index the storage using a credential set that can access the entire storage estate, normally the Administrator user. This field accepts the Username, and should include the domain, for example, “AD\Administrator”.
  • Password - This is the password for the account used in the Username field.
  • Share Path - This is the UNC path to the Nasuni Edge Appliance. Enter a Unix-compatible path, for example:

    / /londonnasuni/sharename

  • Protocol version - This is used to control the SMB protocol version that is used. It is recommended to use SMB version 2.1 as the base SMB protocol for the Nasuni connector. If you are considering using SMB 3.0 please contact support
  • Use SMBClient for Listing - Using the smbclient can have performance benefits and is recommended.
  • Binding LDAP - A prerequisite noted for this connector is an already established Active Directory connection via LDAP. This should be the same AD domain that is integrated with your Nasuni Edge Appliance. You should select this Authentication System from the list.

Before proceeding with the next step, it is advisable to review the number of threads that will be used for the Synchronization. Increasing the thread count can improve the rate at which the storage is indexed. For details on increasing that, please see this guide.

Once completed, click Continue.

At this point, the NAA will connect to the Nasuni Edge Appliance, and perform a Provider Sync of the storage metadata.

During the phase of Provider Synchronization, the root directory of the provider will be made automatically into a Shared Team Folder, and permissions on this directory and its subdirectories will be set according to the permissions of your underlying Nasuni storage.

You can monitor the Provider Sync from the Provider Information screen.

Once the Synchronization has been completed, you should open the Provider Settings page from the Dashboard and set the provider's Cloud Refresh to Enabled.

If this option is not present on your Dashboard, then it may need to be enabled from the appladmin's account under Site Functionality.

The Nasuni connector automatically establishes itself as a Shared Team Folder. The permissions on its directories and subdirectories will be automatically managed by the NAA .

When users next login to the NAA , they will observe a team shared folder at the root of their view, with access to the data stored on Nasuni.

If you need to add multiple Nasuni Edge Appliances, this can be done by repeating the above steps.

Guidelines and Notices

Users who authenticate with SAML can use Nasuni providers. See this page for more information.

Because this connector imports and applies access permissions in a way that prevents direct control in Access Anywhere, some of Access Anywhere's behaviours may differ from the behavior with other connector types.

  • By design, this connector cannot be added by individual org members to create personal providers as it involves creating a Shared Team Folder for the organization's users.
  • For each Nasuni provider that you add, you will find a shared team folder created in the root of the Organization account. Access Anywhere reads the permissions for the file shares, whether you are mounting the root of a file share, or if you are mounting a sub-path of the share. Where DFS is fronting the shares, all users will have access to the DFS root, and the shares within the DFS server will have permissions applied accordingly.
  • Generally, Trash and Versioning can be disabled, as the Nasuni file system will handle these capabilities natively.
  • The top level of a Nasuni share is a Shared Team Folder. Access Anywhere does not allow files in Shared Team Folders (including their descendants) to be made public.
  • To prevent overloading your LDAP server with repeat requests, caching of user groups and SIDs is done within the NAA . The default cache expiration time for groups is 300 seconds. This can be changed using cifsldapcachetime: ffconfig set cifsldapcachetime 300. The mapping of SIDs to group names is cached by default for 1 week. This can be changed with ffconfig set cifsgroupsidcachetime 604800.
  • The NAA will automatically manage specific mount points on the NAA host machine. Operations performed by users, such as opening, editing and sharing are performed on the individual user's mounts. This underpins the security of the connector.
  • It is recommended to have the following configuration option enabled: ffconfig set cifs_passwd 1
  • If a user receives the message “Password not found for user. Please re-login”, they are advised to log-out and re-login again. This occurs when Nasuni shares are added after users have begun authenticating.
  • If the password of a user who is using Access Anywhere's desktop tools to access storage via this connector changes, she must log in via the web to cause the password to be refreshed, preventing mount errors. As of appliance 2106, end-users will be automatically logged out when passwords on Active Directory if the configuration option on the Authentication System is enabled to check for password changes.
  • You must add this connector using the Organization Administrator account, not a 'delegated admin' account.
  • The baseDN that you specify for LDAP searches must be high enough in the tree to encompass both all of your users and all of your shares. Use the domain name as the baseDN or, if you are using another entry at the baseDN, ensure that all groups for your shares are within the baseDN that you select.
  • If the password of a user who is using Access Anywhere's desktop tools to access storage via this connector changes, she must log in via the web to cause the password to be refreshed, preventing mount errors.
  • Share names configured in Access Anywhere must match the corresponding names on the storage exactly, including case. If the cases differ then you will experience errors when adding the provider.
  • When a folder is being configured as the root of a share, the full folder path configured in Access Anywhere must match the path on the storage exactly, including case. If there are differences in case then Access Anywhere will not be able to fetch and use the storage's access control information.
  • When a user's permissions to access a folder are changed on the storage, that change will not be reflected in Access Anywhere's metadata until Access Anywhere has refreshed its view of the folder. This may lead, for example, to brief periods when a user appears to continue to have access to a folder's contents although the user's access permission has been removed from the storage. The storage's permissions will apply, however, if the user attempts to access the contents of the folder during this brief period.

After you upgrade your Filer you should either drop all of the mounts on the Filer that are used by Access Anywhere or run Access Anywhere's flush_mounts.sh script as described here.

See also Nasuni and Multi-User SMB Connectors Troubleshooting Guide .

Hide files in a Mixed Security Folder

The Nasuni connector maps Nasuni storage folder and file permissions to Access Anywhere folder permissions. Nasuni folder permissions are generally mapped to the equivalent Access Anywhere folder permissions of “No Access”, “Read”, “Read/Write” or “List Folders”. The exception is when an item within a folder should not be visible. In this case the entire folder is marked as “No Access”. This means the user won’t see that file but has the downside of hiding files they do have access to.

This behaviour can be modified by disabling the setting “Hide files in a mixed security folder“. Disabling this setting means that users will be able to see the names of files they don’t have access to if they have access to the folder they are in. They will not be able to preview, download or update these files.

Showing Hidden Files In Mixed Security Folders

In the appliances ApplAdmin account, navigate to Site Functionality > Storage Connectors, and look for the Nasuni Connector Security section.

Disabling the option will affect all Nasuni connectors in use across the appliance.

Example Hidden Files Permission Scenario

Consider there's two users James and Maksym who exists in AD, and the following folder and permissions:

Engineering/              [All Users Read/Write]
├─ AA/                    [All Users Read/Write]
│  ├─ Team/               [All Users Read/Write]
│  ├─ Projects/           [All Users Read/Write]
│  ├─ TestPlans.xlsx      [Maksym Read/Write Only]
│  ├─ Contacts.xlsx       [All Users Read/Write]
│  ├─ JIRA.xlsx           [All Users Read/Write]

When NAA is operating in its default mode (hiding files in mixed security folders on), NAA will present the following view to the users.

James' View:

Engineering/              [effective: read/write]
├─ AA/                    [effective: list-only]
│  ├─ Team/               [effective: read/write]
│  ├─ Projects/           [effective: read/write]

Note: Observe how all files are hidden because one of the files is marked as hidden to James

Maksym’s View:

Engineering/              [effective: read/write]
├─ AA/                    [effective: read/write]
│  ├─ Team/               [effective: read/write]
│  ├─ Projects/           [effective: read/write]
│  ├─ TestPlans.xlsx      [effective: read/write]
│  ├─ Contacts.xlsx       [effective: read/write]
│  ├─ JIRA.xlsx           [effective: read/write]
 

When NAA is operating with the default mode disabled (not hiding files in mixed security folders), NAA will present the following view to the users:

James' View:

Engineering/              [effective: read/write]
├─ AA/                    [effective: read/write]
│  ├─ Team/               [effective: read/write]
│  ├─ Projects/           [effective: read/write]
│  ├─ TestPlans.xlsx      [effective: read/write but file i/o prevented by NEA]
│  ├─ Contacts.xlsx       [effective: read/write]
│  ├─ JIRA.xlsx           [effective: read/write]

Note: Observe how all files are shown.

Maksym’s View:

Engineering/              [effective: read/write]
├─ AA/                    [effective: read/write]
│  ├─ Team/               [effective: read/write]
│  ├─ Projects/           [effective: read/write]
│  ├─ TestPlans.xlsx      [effective: read/write]
│  ├─ Contacts.xlsx       [effective: read/write]
│  ├─ JIRA.xlsx           [effective: read/write]

Changing the Share Path

You should only be changing the share path if the location of the share has changed.

To update the share path, navigate to the Provider Settings.

Under Account access info, next to SMB Share Path press the “Change path” cog icon.

SMB Share Path

A window like the following will appear:

Comparison of folders

Under New Path enter the new UNC Path that you wish to reconfigure the connector to use.

When you have entered a new path, press the Load button that appears. The interface will validate connecting to the new path, and will show you a folder listing.

It is important at this point to verify that the folder listing on the new path mirrors that of the existing path, on the left side.

If the system detects that the new path does not mirror in the root folder, it will present a warning.

Once you have configured the new path, you will need to accept the checkbox I acknowledge that the new path is correct and any misconfiguration may lead to metadata-loss.

Finally, click Update Path.

Your provider will now use the new UNC path.

Usage Precautions

The intention for this is to swap ‘like-for-like’. This is not intended to swap one part of the file system with another.

When the platform validates connectivity and access, it does not go beyond the root folder. You should ensure that the new path is configured correctly beyond the root folder.

If the new path contents do not mirror the current path contents, NAA will remove metadata of the current file system, such as Shared Links.