What Is Aspera Files?

Files (now called Aspera on Cloud or AoC) is Aspera’s on-demand SaaS offering for global content sharing. Files enables fast, easy, and secure exchange of files and folders of any size between end users, even across separate organizations, in both local and remote locations. Using Files, organizations can store and readily access files and folders in multiple cloud-based and on-premises storage systems.

Files uses Aspera’s FASP® protocol, which overcomes the limitations of other file-transfer technologies. Aspera Files moves large files data sets at maximum speed, reliability and security — regardless of network conditions, physical distance between sites, and file size, type, or number.

Aspera Files features include the following:

· Individual workspaces that allows users to work as they choose

· Domain security within the application

· Multiple permission or access levels for individual files and folders in the workspace, configurable per user or group

· Ability to send content to multiple recipients using an intuitive, email-like workflow

· Simple sharing of files and folders

· Configurable permissions to share with and send to outside users who do not have a Files account

· Comprehensive administrative capabilities

Aspera Files API

Aspera Files supports a RESTful platform API. The Files API allows developers to create web applications and automation tools for use with Aspera Files. It works closely with the Connect API and Node API to interworks between Files and the underlying Aspera transfer node.


This section contains the following:

Node API

Any transfer using Aspera Files also involves the Node API. Aspera’s Node API provides a RESTful interface for full control of the transfer server underlying Aspera on Cloud. Click here for Node API endpoint reference.

Note: The Node API requires a separate and different token than the Files API. You can use the Files API bearer token to create a Node API bearer token; a detailed procedure follows in this document.

A node is a server on which Aspera software is installed. The Node API allow you to do the following:

  • Manage user access to the node’s file system and transfer capabilities.
  • Create and delete files and folders.
  • Upload and download files and folders to and from the node using the FASP protocol or HTTP/HTTPS.
  • Query what files and directories are on the server.
  • Query what transfers have been made to and from the server.
  • Modify the attributes of a transfer while it is in progress.
  • Get transfer events that are occurring on the server.
  • Enable logging to syslog.
  • Create access keys for permissions.

Each operation of the Node API has a REST endpoint. The operations supported by the Node API are all synchronous processes that execute quickly enough to be handled synchronously within a web request/response cycle.

Firewall settings

Aspera transfers require access through specific ports. If you cannot establish the connection, review your local corporate firewall settings and remove the port restrictions accordingly.

HST Server

Configure your firewall to allow the following ports:

  • Inbound TCP/22 (or other TCP port set for SSH connections): The port for SSH connections.
    The firewall on the server side must allow the open TCP port to reach the Aspera server. No servers are listening on UDP ports. When a transfer is initiated by an Aspera client, the client opens an SSH session to the SSH server on the designated TCP port and negotiates the UDP port over which the data transfer will occur.
  • Inbound UDP/33001 (or a range, if required, see below): The port for FASP transfers, which use UDP/33001 by default, although the server may also choose to run FASP transfers on another port.
  • Local firewall: If you have a local firewall on your server (like ipfw), verify that it is not blocking your SSH and FASP transfer ports (such as TCP/UDP 33001). If you are using Vlinks, you will need to allow the Vlink UDP port (55001, by default) for multicast traffic. For additional information on setting up Vlinks, see Controlling Bandwidth Usage with Virtual Links (GUI).

When a range of UDP ports is required: For Aspera servers that have multiple concurrent clients utilizing two or more user accounts, Mac OS X does not allow the Aspera FASP protocol to reuse the same UDP port. Conversely, one UDP port can be opened if only one account is being used for transfers. Thus, if you have multiple concurrent clients and your Aspera server runs on Mac OS X, then you must allow inbound connections on a range of UDP ports, where the range of ports is equal to the maximum number of concurrent FASP transfers expected. These UDP ports should be opened incrementally from the base port, which is UDP/33001, by default. For example, to allow 10 concurrent FASP transfers, allow inbound traffic from UDP/33001 to UDP/33010.

Remote client machines

Typically, consumer and business firewalls allow direct outbound connections from client computers on TCP and UDP, and no configuration is required for Aspera transfers. In the special case of firewalls blocking direct outbound connections, usually with proxy servers for web browsing, the following ports must be allowed:

  • Outbound TCP/33001: Allow outbound connections from the Aspera client on the TCP port (TCP/33001 by default, when connecting to a Windows server, or on another non-default port for other server operating systems).
  • Outbound UDP/33001 (or a range, if required): Allow outbound connections from the Aspera client on the FASP UDP port (33001, by default).
  • Local firewall: If you have a local firewall on the client (such as ipfw), verify that it is not blocking your SSH and FASP transfer ports (such as TCP/UDP 33001).

Key concepts

This section contains the following:

· Transfers

· Sending

· Sharing

· Users

· Workspaces


A transfer moves content from one storage location to another. This move may be a copy and paste to the new location, leaving the source content intact in the original location. Or it may be a copy and delete, pasting the content to the new location while deleting the original content in the source location.

There are three basic transfer types in Files:

· Upload: Uploading content from your local machine or from a local or remote storage location into a Files workspace. This is typically a copy/paste operation, leaving the source content intact in the original location. Most Send operations are also uploads, copying the content to an interim location on a transfer server accessible to the recipient for download.

· Download: Downloading content from the Files workspace to your local machine, or to a local or remote storage location. This is also typically a copy/paste operation, leaving the source content in Files intact while duplicating it in the target location.

· Node to node: Moving content from one Aspera transfer server to another. This may be the case when moving files and folders from one location in a Files workspace to another location in a Files workspace. Relocating content within your home folder can be a copy or a move operation. Sending content to a dropbox may also initiate a node-to-node transfer.


You can send files and folders that are on your desktop, on a remote source, or in your Files environment.

When you use Files to send content, Files creates a copy of the source content, wherever that may reside, and delivers it to your recipients. Once you send content, you cannot modify the copy you sent. After you send the copy, changes you make to the source content do not affect the copy. Similarly, any change the recipient makes to content you’ve sent does not change the source content.

Sending content initiates a FASP transfer.

If your Files administrator has enabled this capability for your workspace, you can send content to Files users in other workspaces and to people without a Files account.


A package (also called a digital package) is a collection of digital assets (video, images, binaries, files, folders, etc.) that you create to send to one or more individuals or user groups, or to a Files dropbox.

Once you assemble the contents of the package, you can send it to one or more Files users or user groups, to all members of your Files workspace, or to a Files dropbox. If your administrator has enabled this capability for your workspace, you can send the package to users outside your own workspace, or to a non-Files user by entering the email address.

Once you have sent the package, you can no longer add, change, or remove the content in it.


A Files dropbox (called a shared inbox in Aspera on Cloud) is an optional workspace feature that allows users to send content directly and simultaneously to all members of the dropbox without having to address it to particular users or user groups.

A dropbox is created by the administrator or workspace manager, who designates members of the dropbox from among the workspace members, then assigns each member one or more permissions to the dropbox. An individual user in the workspace may have membership in one or more dropboxes, or in none; may have different permissions in each dropbox, and permissions may be different than the permissions of other dropbox members.

File requests

Use a file request to request someone to send a digital package to you as an individual or to a dropbox of which you are a member.

When you send this request, also called a submission link, the recipient receives an email message containing a link inviting them to submit a package to a shared inbox.

Note: You must have Invite permission to the dropbox and the administrator must enable this capability for your workspace.

You can send a submission link to the following:

· A person without an Aspera on Cloud account.

· An Aspera on Cloud user who is not a member of your workspace.

· An Aspera on Cloud user who is a member of your workspace.

For each submission link, you can configure an expiration date; the recipient of your invitation can send any number of packages to you or to the dropbox until the link expires or until you revoke the link.

Consider the following:

· You can send a link to a current member of the dropbox.
The submission link invites a current member with Send permission to submit to the dropbox. All packages sent by that user are tracked by the user’s name.

· You can send a link to someone who is NOT a member of the dropbox.
This recipient may or may not have an Aspera Files account. You can configure an expiration date for each submission link; the recipient of your invitation can send any number of packages to the dropbox as long as the link is valid. Note that if the person you invite forwards the link to another person, that second person can send as many packages as they want to the dropbox as long as the link is valid. Aspera on Cloud identifies the sender of such a package as “Anonymous Sender.”

· If the administrator has configured metadata fields for the dropbox, the recipient of the submission link will see those fields when they send a package; they must enter data in any required fields.


To share folders, the content must reside in your Files environment. Either upload the content into your Files environment from a local or remote source, or move it from a package.

Sharing content does not create a separate copy. Rather, when you share content with someone, you give them access to the exact same materials you have access to. If they make changes to content you’ve shared, that content is changed at the source.

If your Files administrator has enabled this capability for your workspace, you can share content with Files users in other workspaces and with people who do not have a Files account.

Note: You cannot share individual files. To share files, place them in a folder and share the folder.

Assigning permission to shared content

When you share content, you assign permissions to each user with whom you share. So, for example, you can share Folder A with User 1, giving User 1 ‘Edit’ permission to Folder A; you can also share Folder A with User 2, giving User 2 ‘View’ permission to Folder A.

You can grant, at most, only the permissions that you yourself have to the folder. You can share a folder and grant fewer permissions than you have to it.

When you send content, you do not assign permissions; each recipient you send to has full Edit permission to the content you send.

Content permissions

You have a specific permission or access level for each file or folder in your Files app.

There are two composite permissions and seven custom permissions for content in Aspera Files:

· Composite permissions:

o Edit (also called Can Edit)
This is the highest level of permission in Files and gives a user full control over the item; it contains all other permissions.

o View (also called Download Only)
Comprises Browse, Download, and Preview permissions.

· Custom permissions (content must reside on a transfer server with node software at version 3.7.4 or higher; see the “Package Information” section of the HST Server Release Notes for specific build numbers for your platform):

o Create/Upload folders
Create or upload an empty folder; to upload folders containing files, enable this permission along with Upload files.

o Rename
Rename files and folders.

o Upload files
Upload files and folders; to upload folders containing files, enable this permission along with Create/Upload folders permission. See Delete below for uploading a file with the same name as an existing file (overwrite or replace).

o Download
Download the folder or file in the folder.

o Preview
Preview movie files in the folder. Thumbnail previews of image tiles are always available.

o Browse
Browse folder content; if this setting is not enabled, you can see the folder but cannot view folder contents.

o Delete
Delete or overwrite files and folders in the folder.

The permission you have to a given file or folder depends upon how you gained access to it.

· For items you upload to the root level of your Files tab, and for items you move from a package to the root level of your Files tab, you have full Edit permission (unless your administrator has designated your Files tab as read only).

· For items you upload or move into a folder, you have the permission of the folder.

· For folders shared with you, you have the permission granted to you by the person who shared. (The permissions they can grant to you is determined by the permission they have to the given item.)

The permission you can grant to a folder you share depends on the permissions you have to that folder. You can grant any or all of the permissions that you yourself have to that item; you cannot grant a permission that you do not have.

Sharing with a public link

Use a Files public link to share items that are in your Files environment with an outside user (an outside user may be a Files user outside your workspace, or may be someone without a Files account). The recipient of the public link can access the content you shared without having to log in to Files.

When you create a public link, you can configure the duration that the link is active; once the link expires, the outside user can no longer access the content you shared. You can also configure the outside user’s permission level to the content, depending on your own permission level to the content. You can send link in an email to the outside user, or deliver it to the recipient by another means.

When the outside user clicks the link, they get access to the files and folders you shared. The user can act on that content according to the permission level you configured when you sent the link.

Note: This link is truly public, in that the user you give the link to can in turn give the link to another person, who can then access the content you shared. Use the public link with trusted colleagues.



Using an admin token from the API, administrators fulfill all typical admin functions, including:

  • Configuring the transfer nodes that support the app, host the cloud-based files and folders being used by users of the app.
  • Configuring users and groups, including permissions, memberships
  • Configuring workspaces, dropboxes, shared folders, additional storage, etc.
  • Administering the organization, authentication methods, security settings, and visible branding
  • Monitoring storage usage, transfer usage, and other activities

Workspace managers

Using a workspace manager token from the API, workspace managers fulfill specific admin functions for the specific workspaces they manage:

  • Configuring collaboration settings, package expiration
  • Configuring dropboxes
  • Configuring groups
  • Add and remove workspace members


  • Send content to anyone in their workspace.
  • Share content with anyone in their workspace.
  • If collaboration settings (configured by administrator or workspace manager) permit:
    • Send packages to users outside the workspace and to colleagues without a Files account.
    • Share files and folders with users outside the workspace and with colleagues without a Files account.
    • Invite outside users to submit content, and invite outside users to join the workspace.
  • If dropbox privileges permit, invite outside users to join a dropbox with ‘Can Submit’ permissions. Such invited users do not become workspace members (see “Limited User” below).
  • If workspace permissions permit:
    • Upload to their own home folder.
    • Create new folders in their home folder.
  • Download from their own home folder.
  • Subscribe to email notifications.


One or more per organization. If your implementation requires only one workspace, the workspace element is in effect transparent, though it persists in the background to hold users, groups, permissions, policies, etc.

The workspace is a collection of Aspera Files users working together — on a given project, for example, or perhaps in a department or division. Users in a given workspace can freely collaborate with other members of the same workspace. However, they need specific permissions, configured by the organization administrator or workspace manager, to collaborate with users outside the workspace. The packages, files, and folders in one workspace are completely separate from those in another workspace. Depending on your responsibilities in the organization, the Files administrator may make you a member of more than one workspace; you may have different permissions and access in one workspace compared to another.


Diagram of the architecture of Aspera Files, showing the Aspera node, the Files application platform, and the Aspera client

As shown in the drawing above, there are 3 main architectural components:

  1. Application Servers, which consist of the Files front-end and back-end servers. The Files web application is retrieved from the Files front-end servers.
  2. Node Servers, (sometimes called “Nodes”) handle files, folders, access to files, file listings, file transfers… everything about files. There may be multiple clusters of Node Servers
  3. Clients are everything that uses the APIs in the other servers. The Files web application is a client, Aspera Drive is a client, etc.


Application Servers are in charge of Users, Groups, and Messaging. Nodes are in charge of Files, Permissions, and Metadata. When a Client wants to log in a user then list the contents of the home folder: the first request is to the Application Server to get information about the user’s home folder (requiring authentication if not logged in), then the second request is to the Node to retrieve the file.

  1. Application Server: GET /self to get information about the current user. This will return information about the user’s home folder if logged in and will redirect to the login page if not.
  2. Node: GET /files/{home_folder_id}/files to list the contents of the home folder.