The latest information on Nasuni Connector configuration can be found at Nasuni_Access_Anywhere_Getting_Started.pdf.
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.
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.
Nasuni Access Anywhere requirements:
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:
/ /londonnasuni/sharename
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.
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.
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
.ffconfig set cifs_passwd 1
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 .
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.
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.
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]
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.
A window like the following will appear:
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.
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.