Release Notes: IBM Aspera Enterprise Server 3.7.4 for Linux on z Systems

Product Release: September 1, 2017  
Release Notes Updated: September 13, 2017

This release of IBM Aspera Enterprise Server for Linux on z Systems provides the new features, fixes, and other changes listed below. In particular, the Breaking Changes section provides important information about modifications to the product that may require you to adjust your workflow, configuration, or usage. Additional sections cover system requirements and known problems.

NEW FEATURES

General

  • Enhanced FASP protocol performance. Compared to prior releases, unencrypted CPU-bound transfers can see an increase of up to 100% in overall throughput; and encrypted CPU-bound transfers can see an increase in overall throughput of up to 20%.
  • When using a local URI docroot or destination (such as file:////data), for example when server-side encryption-at-rest is enabled, temporary partial files can now be created during ascp transfers by configuring <partial_file_suffix> in aspera.conf. (CIM-85)
  • FASP transfers are more secure with upgraded OpenSSL (from 1.0.2i to 1.0.2j).
  • Special file permissions (setuid and setgid) are now supported in ascp and the Node API when the permissions are configured in aspera.conf. (CIM-201)
  • A man page is now available for asconfigurator.
  • File checksums SHA-256, SHA-384, and SHA-512 can now be set in aspera.conf. (CIM-269)
  • Improved detection of potential Distributed Denial of Service attempts involving missing or slow SSL negotiation requests. The HTTP fallback daemon now automatically times out (after 20 seconds) connections that do not send a request or are too slow.
  • Transfers with Microsoft Azure Files are now supported, including using Azure Files access keys.
  • Increased server security with upgrades to the OpenSSH SSHD service. (CIM-600)

ascp

  • A new transfer scheme, faux://, enables testing a transfer without reading from disk and/or writing to disk, eliminating the need to generate large test sets.
  • Users can now specify multiple SSH private keys (both DSA and RSA keys) in the same ascp command.
  • SSH private key strings can now be used to authenticate ascp transfers by setting a new environment variable, ASPERA_SCP_KEY.
  • Two new ascp options extend support for base64 encoding: --dest64 can be used to indicate that the destination path is base64 encoded, and --source-prefix64=source_prefix can be used to indicate that the specified source prefix is base64 encoded.
  • Resume mode checks in ascp now use a SHA-2-based MD5 checksum algorithm by default; to configure alternative algorithms, there is a new aspera.confoption.
  • Ascp now features new complete include and exclude filter options to support glob and regular expression matching, equivalent to include/exclude options ofasync.
  • A new FASP Manager API feature can be used to send an event when individual arguments, such as directories in persistent sessions, are completed.
  • Ascp now includes a new asynchronous “in transfer” post-processing engine with Lua scripts. (This is the first version of this feature, and somewhat experimental.) A Lua interpreter engine is packaged with Enterprise Server, allowing for post-processing, validation, and authorization functions through embedded Lua scripts. Scripts execute asynchronously, and their progress is reported through a new validating state in the transfer session, without delaying completion of the file transfer or slowing the transfer pipeline.
  • Parallel (multi-session) transfers initiated from the command line can now use a URI for the filepath.
  • The <file_create_mode> configuration in aspera.conf is now respected when the docroot is a file URI.
  • Asperacentral has a new raw options capability that allows users to authorize the use of raw format ascp options in raw format by configuring aspera.conf.
  • Persistent ascp sessions (run with the --keepalive option) can now accept management control messages sent from a server to the remote machine.
  • The ascp management fields "User" and "ClientUser" now reflect the authorization and authentication methods.

A4

  • A4 is now supported on Linux on z Systems. Aspera A4 is an optimized transfer engine based on FASP technology and is designed for sending extremely large sets of individual files efficiently. The executable, ascp4, is similar to ascp and shares many of the same options and capabilities, as well as options that enable multi-threaded FASP transfer, TCP and UDP stream I/O, memory usage control, and filtering by when a file was last modified.

Node API

  • A new Node API call returns usage data (bytes transferred in, transferred out, and total) listed by usage_id.
  • The Node API now returns events for the creation, rename, and deletion of files using the Node API, in addition to file transfer events. (CIM-52)
  • A new Node API call returns verbatim the content of a file within the file size restriction set in aspera.conf.
  • The access key and token secret of a Node API user are now passed on to Aspera Central, such that ascp is run with the environment variables associated with that user.
  • SSH private key strings are now are now supported in the Node API through a new JSON element, ssh_private_key.
  • A new case-insensitive filter can return filename matches regardless of case to Aspera Files.
  • The /ops/transfers API has been improved, including new support for setting transfer rates, bandwidth priorities, and pausing/resuming/canceling active transfers.
  • Asperanoded includes improvements in the /info and / API response, such as support for content protection settings.
  • /ops token authorization now uses SHA-2 as the default checksum, rather than SHA-1.
  • The status of files and transfers can now be reported by iteration token from the Node API. For example, if the user specifies an iteration token tohttps://node:9092/ops/transfers?iteration_token=1234, files and transfers from iteration_token=1234 to the present are displayed.
  • File modification events, including delete and rename, are now logged to redis/scalekv.
  • Transfer and bandwidth statistics are self-cleaning for large numbers of sessions.
  • Default and allowed SSL ciphers have been updated to eliminate support for 3DES and to align the defaults with hardened versions.
  • Users can now run asnodeadmin --db-update to migrate data from Enterprise Server 3.5.6 and earlier versions.
  • RESTful /files calls now return full filepaths for admin users.
  • Specific events can now be requested by ID by using the new /events/{event_id} call.
  • The Node API now supports file locking. ascp transfers respect the lock status while the file is checked out. File locking can be enabled on the server by setting the <files_filelock_enabled> option in the <server> section of aspera.conf to true.
  • The Node API now supports access keys for IBM Bluemix S3 storage and Google Cloud Storage.
  • A new Node API call returns usage data (bytes transferred in, transferred out, and total) listed by access key.
  • The files/{id}/preview call now supports "Accept:" headers containing MIME types as completely literal (literal1/literal2) or literal and wildcard (literal/*). For example, 'Accept: image/*' returns image/png. This preview feature applies only to Linux machines deployed as Files nodes.
  • The Node API /ops/transfers now supports ascp4 transfers. Specify that a transfer should use ascp4 rather than ascp by adding the following line to a JSON request:
    "use_ascp4" : true
  • The Node API can now pass instructions on how FASP transfers handle symbolic links. If no method is specified, the default policy is now follow.
  • The logging thread to the kvstore database now times out after the FASP transfer session ends. The timeout period can be configured with a new setting,<activity_log_queue_timeout>, in aspera.conf.
  • Partial files reported by a /files/browse call can now be identified with the new "partial_file" : true attribute, allowing them to be processed separately from complete files. To enable this, the <partial_file_suffix> must be set in aspera.conf. Files with the resume suffix are still filtered out from the dictionary.

Watchfolder and Aspera Watch Service

  • Watchfolder uses two new APIs:

    • asperarund: to start, stop, and manage asperawatchfolderd and asperawatchd under various user accounts.
    • access_control: to configure user access to specific instances of asperawatchfolderd and asperawatchd regardless of their system user account. See Breaking Changes for more information on this feature.
  • This release features many enhancements to the robustness of asperawatchfolderd:
    • The system ensures that a custom watchfolder aspera.conf is passed to ascp.
    • A valid and consistent docroot is verified upon startup.
    • --scan-period is now respected in creation.
    • aswatchadmin no longer hangs on removal of a watchpoint with a large number of files.
    • Archive directories are now respected.
    • Statistical counters persist after reboot.
    • asperawatchfolderd includes improved health status reporting.
    • Session cookie and tag fields are accepted and reported through management.
    • Timestamps are preserved when so configured.
  • Watchfolders can now use token authentication for transfers.
  • Users can now authorize the use of raw format ascp options by Watchfolder transfers by enabling the new <raw_options> setting in the <watchfolderd> section of aspera.conf.
  • The API call getWatchFolderState now returns the state of asperawatchfolderd in addition to the state of the transport and state of the watch.
  • Users can now select an existing asperawatchfolderd service when creating a watchfolder.
  • asperawatchfolderd now supports force-send-after configuration for growing files.
  • The configuration of asperawatchfolderd can be updated without re-sending the remote host password.
  • Watchfolder can now retry failed drops.
  • Encryption-at-rest is now supported.
  • asperawatchfolderd now initiates transfers with a destination root, allowing Watchfolder transfers to work using the Aspera upload option for Akamai storage (requires a minimum server software version on the Akamai side).
  • Users can now update the password of a service without deleting and re-creating the service.
  • Improved behavior of Watchfolders when a transfer session fails to start within a specified timeout.
  • Improved error messages when watchd encounters invalid paths or is blocked by permission settings.
  • When a watchd service is deleted, the Aspera Rund service now deletes all data in the Redis database unless the user specifies that Redis should not be cleaned in the deletion request.
  • Faster directory scanning by the Aspera Watch Service, particulary of directories that contain many (10,000s) subdirectories.
  • Watchfolders now supports IPv6 addresses. (CIM-531)
  • Watchfolder can delete files from the source as soon as the file is successfully transferred, rather than waiting for the session to complete, by editing the Watchfolder configuration JSON file or by enabling it in Console (In the Console GUI, go to File Handling > Source deletion and select Automatically delete a source file after transfer of this file). (CIM-493)

Sync

  • The Sync guide in now included in the Enterprise Server guide. It includes new instructions for composing an async command and an expanded troubleshooting section.
  • Access keys and storage roots are now supported, allowing async to run on Aspera Files and for other Node v4 applications.
  • The new recursive mtime option enables the exclusion of directories and files older than a configured timestamp.
  • A new asyncadmin option prints file attributes (mtime, recursive mtime for directories, and checksum).
  • Pending file bytes are now reported correctly in Aspera Console during an async pull (fixed in Enterprise Server 3.6.2).
  • The new --delete-delay option allows the delete operations in a unidirectional sync to be delayed until the end of the synchronization.
  • Sync now has a two-minute timeout, enabling it to exit gracefully in the rare cases when under high network impairment conditions Sync does not receive a proper shutdown sequence.
  • The asyncadmin tool can now output file and session status when Sync is using a database with LMS (<async_db_spec> is set to sqlite::lms). When reporting data on a specific source-destination pair by name (using the -N pair_name option), if Sync is running then the output reflects the final state of the last async run and does not reflect any changes in the active sync.
  • Sync run in bidirectional mode with modification times preserved no longer reports conflicts due to directory modification times. However, when the source and destination directory times are both modified between sync sessions, directory modification times might not be preserved.
  • On machines with Unix-based operating systems, a new value, inode, is available for the --dedup option. In this mode, when two or more source files have matching inodes, a hardlink is created between them on the target and the target files have matching inodes.
  • Faster Sync database loading on subsequent syncs when many (100s) of filters are specified.
  • Sync with S3 is now fully supported and documented.
  • Improved Sync shutdown process when a Sync session is stopped.
  • Bidirectional syncs between S3 buckets are now supported.
  • A new option, --cooloff-max=time, can be specified so that a one-time Sync waits for a file to stop changing within the cooloff interval before it synchronizes the file. With this option, the file is skipped after the cooloff-max time.
  • Sync sessions can now be filtered by setting the <filter> configuration in aspera.conf. Command-line filters are applied after aspera.conf settings. If filtering is not always wanted, then configure filters for one user. Sync sessions that are run by that user are filtered while sync sessions run by other users are not.
  • Improved handling of changing files by continuous Sync sessions when checksum is set to none; files that return a sharing violation error are now retried per --sharing-retry-max.
  • Access key authentication is now supported by using "Basic: token_string" as an argument for the -W option.
  • The --dedup option can now be used in async commands even if it is not specified in the first run; however, --dedup is rejected if the first run does not use -k(calculate file checksums). The dedup index is created if it does not already exist, and if the database is large then this process can take some time.

Other Changes

  • The pre/post variable TOKEN is no longer valid.
  • Activity bandwidth logging is no longer enabled by default.
  • The Aspera Watch Service is now automatically enabled and the <watchd> parameter has been removed from aspera.conf.

BREAKING CHANGES

If you are upgrading from a previous release, the following changes for this release may require you to adjust your workflow, configuration, or usage.

  • Activity event reporting can now be configured with a new aspera.conf setting, activity_event_logging. Prior to 3.7.4, activity event reporting was always enabled. As of 3.7.4, activity event reporting is disabled by default to improve server performance, and it must be enabled in order to query the Node API /events endpoint. Nodes that are added to Aspera Files must have activity event reporting enabled. To enable it, run the following command:
    asconfigurator -x "set_server_data;activity_event_logging,true"
  • With the implementation of new inline validation options, existing users with inline validation enabled must set the validation provider to uri or lua_script. The command is the same regardless of platform, but for Linux you must preface the command with its path: /opt/aspera/sbin/asconfigurator.
    > asconfigurator -x "set_node_data;validation_threshold,uri"
  • When upgrading to version 3.7+, if asperawatchd or asperawatchfolderd services are being run by users other than root on Linux or svcAspera on Windows, the services must be stopped prior to upgrade and restarted manually following the upgrade. Services run by root and svcAspera are migrated automatically during installation.

    Run the following commands for each user and service, as required. The commands are the same regardless of platform, but for Linux, preface the command with its path, for example: /opt/aspera/sbin/asperawatchd.

    > asperawatchd --user username
    > asperawatchfolderd --user username
  • In Watchfolders, the Node API transfer account must have access control set to admin in order to create watchfolders. To update an existing Node API transfer account, run the following command. The command is the same regardless of platform, but for Linux, preface the command with its path, for example:/opt/aspera/bin/asnodeadmin.
    > asnodeadmin -mu username --acl-set "admin,impersonation"

    To create a new Node API transfer account with the correct access control, run the following command:

    > asnodeadmin -a -u username -p passwd -x transfer_user --acl-set "admin,impersonation"
  • The way asperawatchfolderd uses docroots has changed in two ways:
    1. If no docroot and no restrictions are specified in aspera.confasperawatchfolderd will reject the creation of a watchfolder and return an error message similar to the following:
      ERR [Watch_folderd] Handle_create(): [err=28672, message=No docroot]

      Workaround: Specify a docroot or restrictions for the watchfolder.

    2. If the docroot of an existing instance of watchfolderd changes and asperawatchfolderd later restarts and tries to reload the watchfolderd, an error message similar to the following is returned:
      ERR [Watch_folder_pool] Synchronize(): [err=22, message=Change in docroot detected: /home/user/test/s != /home/user/home/user/test/s]

      The watchfolder must be recreated following a change in docroot.

  • Recursive counts are now disabled by default, but must be enabled in order for Aspera Files to use this feature. Workaround: Edit the <server> section in aspera.conf such that <files_recursive_counts_workers> is set to 5:
    <server>
        <files_recursive_counts_workers>5</files_recursive_counts_workers>
    </server>
  • Multi-session (parallel) transfers from 3.5 clients are no longer compatible with 3.6 and newer servers. This is due to a change in how files are split and how the splitting of individual files is configured on both versions. Workaround: Upgrade the client side to 3.6 or newer.

  • With the implementation of new inline validation options, existing users with inline validation enabled must set the validation provider to uri or lua_scripturireplaced external and lua_script replaced lua. To set the validation provider, run:
    asconfigurator -x "set_node_data;validation_threshold,uri"
  • For RESTful operations (such as the Node API /files call and ascp run with file IDs), file events as returned by the Node API /events call, no longer show file paths. Instead, they return values for parent_file_idfile_id, and the file name. File events for RPC-style calls to /files and non-file-ID ascp transfers remain unchanged (reporting file_id and file path).

ISSUES FIXED IN THIS RELEASE

Note: This release contains tickets created from different issue-tracking systems. For this reason, the list below uses two different formats for issue numbers.

ATT-95 (#23246) - Error messages are not generated for skipped files when using a source base setting (--src-base).

WAT-286 (#30365) - In the Sync Job Detail page for pull operations, the size for pending files is reported as 0 Bytes. (Transfer sizes are reported correctly after the transfer completes.)

#32080 - An error message spams the log file used by asperanoded each time Console to check the node for the status. A second error can occur when the end user fills in a docroot but doesn't have a valid system user; this results in an error that also spams the log file used by asperanoded.

#25042 - In the server-side aspera.conf, the none option for file checksum reporting is no longer supported; only md5 and sha1 are supported. The any option means allow the checksum format to be whichever format the client requests. On the client side, the none option is still available, as a command-line option. A setting of any on the client side results in an error with the message ascp: unknown file checksum type any.

#24549 - [Linux] Drag-and-drop transfers in the desktop client are not supported.

SYSTEM REQUIREMENTS

Linux on z Systems s390, 64-bit: Red Hat Enterprise Linux Server (RHEL) 6-7.3, SUSE Linux Enterprise Server (SLES) 11-12

PACKAGE INFORMATION

zlinux s390: aspera-entsrv-3.7.4.147490-linux-g2.5-s390.rpm

md5: fc7a2cb1547bbd78dce1542d2dd6c824
sha1: b679a39f67d368d6fc4f02b21eff49fe5b1fdbba

KNOWN ISSUES

Note: This release contains tickets that were created from different issue-tracking systems. For this reason, the list below uses two different formats for issue numbers.

General

ATT-245 (#22726) - Successful transfers might log the error, Failure Event: -34 - libssh2_channel_wait_closed() invoked when channel is not in EOF state, particularly downloads in FIPS mode. The error can be safely ignored. (CIM-329)

ATT-98 - If inline validation is configured on the server side, the server does not honor a session timeout if a transfer includes a skipped file.

ES-409 - Permissions assigned to IBM Aspera Shares users are not inherited by the Enterprise Server that hosts the share. For example, if a user is created in Shares and does not have delete permissions to a share, if the Shares user runs an ascp download directly from the server and uses --remove-after-transfer in the command line, the files are deleted from the source. (CIM-788)

ES-323 - When doing a dry run of an asdelete (by using the -d option), the log shows all the files that were scanned, not the files that would be deleted by the asdelete command. (CIM-558)

ES-249 - The aggressiveness setting is being applied to Vlinks, rather than only the network rate controller. (CIM-399)

ES-216 - If the Aspera Connect Plug-in is unable to connect to the server by SSH, a misleading error message, "Failed to authenticate," is reported rather than indicating that it is a connection problem. (CIM-72)

ES-215 - If the Aspera Connect Plug-in is unable to connect to the server by SSH, no fallback is attempted. (CIM-320)

ES-188 - Transfers through Aspera Forward Proxy are rejected if the node user password contains an @ symbol. (CIM-290)

ES-42 - When you retrieve the entitlement status by using alee-admin status, confusing error messages are returned even if the entitlement was registered successfully.

#35952 - asunprotect cannot decrypt a reprotected file.

#34811 - You are unable to download encrypted files with an incorrect decryption passphrase when you are using HTTP fallback.

#32934 - If the Internet accountability software Covenant Eyes is installed, some HTTP fallback transfers appear to complete but then lose connection with the server and then attempt to retransfer. Covenant Eyes captures the entire HTTP transmission before forwarding it to the server. If the file is so large that this process takes longer than about 20 seconds, the server times out and cancels the session. Workaround: Reduce the probability of timeout by increasing the server timeout length. Set Session Activity Timeout in aspera.conf by running the following command:
$> asconfigurator -x "http_server;session_activity_timeout,time_in_seconds"

#32517 - Retransfer requests are unencrypted when transfers are encrypted. This change in encryption can cause transfer failures in some scenarios, such as when a network device drops the retransfer request because it detects a bit sequence it considers malicious.

#31791 - Files with the file extension .aspx are not transferred. Workaround: Edit the resume_suffix setting in aspera.conf on the client.

#30690 - ascp fails with an inaccurate message—Error: failed to authenticate—when the server is configured to accept only unsupported ciphers.

#28679 - In some cases, the fallback server cannot accept additional connections, possibly due to too many 'incomplete' requests.

#27056 - ascmd does not respect server-side symlink configuration.

#23246 - Warnings are not generated about files skipped due to the source base setting.

#23070 - If a transfer of several files is interrupted, the retries generate a no such file error for files that transferred.

#22998 - If the overwrite setting in the server's aspera.conf is deny, a destination file on S3 with the same name as the transfer file is still overwritten.

ascp

ATT-405 - When monitoring an ascp transfer, the FASP2 Management Protocol reports inconsistent WrittenBytes, FileBytes, and TransferredBytes.

ATT-395 - When running a persistent ascp session, a FaspManager FILEERROR message truncates a filename that is longer than 128 characters to only the first 128 characters.

ATT-361 - ascp transfers to S3 fail when the --symbolic-link=copy or --symbolic-link=copy+force option is used.

ATT-360 - Directory timestamps are not always preserved on the destination during an ascp transfer that uses -p.

ATT-226 - If the docroot is a URL path, ascp reports incorrect bytes for the sessions that are involved in a multi-session transfer.

ATT-205 - ascp transfer fails with an internal memory error if <network_rc><module> is set to air in the <bandwidth> section of aspera.conf.

ATT-189 - In rare cases, ascp keeps running after it encounters a disk read error. (CIM-233)

ATT-185 - ascp does not reconnect to Redis database when asperanoded is restarted.

ES-349 - When ascp is run with resume enabled (-k {1|2|3}), --preserve-file-owner-uid and --preserve-file-owner-gid are ignored.

ES-267 - Under rare conditions, ascp transfers to cloud object storage may be reported as successful even though Trapd reports an error and the content is not in the storage. (CIM-475)

ES-177 - The range_low value of a -@ argument is not respected.

#35010 - If the source path in an ascp transfer is a file that is named \ (which is not supported by Aspera), the file is not transferred and an error is generated, but the folder then contains the file and all other files in that folder are transferred.

#33094 - The ascp option delete-before-transfer is not supported for URI storage.

#32890 - During an ascp transfer that uses the --preserve-xattrs= metafile --remote-preserve-xattrs=metafile options, the metafile is not transferred.

#32680 - The option to create a directory (ascp -d) may create a directory at a destination before an expected session failure.

#32553 - When the FASP Session log source file list exceeds 500 bytes and contains multibyte UTF-8 characters, the output is truncated in a manner that creates an invalid UTF-8 sequence.

#31423 - It is possible for an ascp transfer of a file on a full disk to be reported as successful by both the sender and the receiver.

#30324 - During an ascp upload to cloud storage, if a mid-file read failure occurs on the sending computer (which is rare) it can cause the server-side ascp to crash and possibly fail to report transfer completion. This read failure can be caused when a source file is truncated during transfer, a drive or file system fails, or a transfer is canceled with Ctrl+C or other means.

#29255 - Download from SoftLayer of a file larger than 62 GB is unsuccessful. Workaround: Do not use time-stamp preservation with SoftLayer.

#28939 - If command line ascp neglects to specify a destination host, then the failed transfer (error: "no remote host specified") gets recorded in SQLite with client_node_id NULL, instead of being populated with the uuid of the node. This database error causes an issue with Console.

#26281 - If you run approximately 100 (or a similarly high number) concurrent uploads to S3, intermittent transfer session failures can occur.

#26185 - During an upload to S3 storage, an error may result if ascp reports a successful file transfer before the transfer to S3 completes.

#25865 - Allowing symbolic links to be copied also allows access to locations outside the docroot.

#23503 - Uploads of zero-byte files to Akamai appear to be successful, but no file is present at the destination.

#22905 - When you copy a file in S3 storage with ascp, if a slash is appended to the destination -- for example, /path/ -- the file is renamed path/. Because of the trailing slash, it appears to be a directory, but is actually a file.

A4

ATT-438 - A4 downloads from object storage fail if the source filename contains special Unicode characters, such as Japanese font.

ATT-426 - To use SSH key authentication in A4, the full path to the private key must be specified as the argument for -i because A4 does not automatically look in the transfer user's home folder. This prevents Aspera Console from being able to use SSH keys if it is configured to use A4 instead of ascp because the full path cannot be specified in the Console UI.

ATT-366 - An ascp4 transfer to object storage does not fail immediately if chunk size is configured incorrectly. Workaround: On the client command line, set the chunk size equal to the size of the shared memory buffers used by Trapd with the --chunk-size option. By default, shared memory buffers are 1 MB, in which case --chunk-size=1048576 should be used.

ATT-338 - Parallel uploads of several large (>1 GB) files to object or HDFS storage may fail with the error "Peer aborted session" if the number of threads that are specified in the ascp4 command exceeds the number of jobs that are allowed to run by Trapd. Workaround: Open /opt/aspera/etc/trapd/trap.properties and set the value for aspera.session.upload.max-jobs to one larger than the number of ascp4 threads. For example,
# Number of jobs allowed to run in parallel for uploads.
# Default is 15
aspera.session.upload.max-jobs=50

ATT-321 - To use ascp4 to transfer with object storage, you must set the chunk size on the server to 64 kb for transfers that include primarily small files, and set it to 1 Mb for transfers that include primarily large files. If the chunk size is not set on the server, then the transfer fails.

ATT-44 - The timestamp of a parent directory that is transferred with ascp -p is not preserved, while the timestamps of the child files and directories are preserved.

ATT-39 - When ascp4 is run with the --no-write option, a 0-byte file and an .aspx (partial) file are created at the destination.

ATT-30 and ATT-46 - ascp4 transfer is slow when you upload many small files (for example, 1 million 4-byte files) to S3 storage.

ATT-27 - Direct-to-cloud ascp4 transfers are skipped unless the full destination path is specified.

ATT-2 (#32295) - The default minimum transfer rate is not picked up from aspera.conf.

ES-416 - A4 transfers with object storage can hang if the Aspera Trapd service loses connection or otherwise errors.

ES-247 - Console-initiated ascp4 transfers fail if the docroot on the source is a UNC path (for example, \\localhost\SHARE), returning the error ERR Source base/path is not a valid directory/file (doesn't match any source path). (CIM-397)

ES-151 - ascp4 does not recognize the UNC-path docroot of a Console transfer user. (CIM-197)

Node API

ES-248 - While a transfer of many files is in process, Node API reports skipped files as complete. The counters are correct once the transfer is complete. (CIM-398)

NODE-437 - Transfers with object storage, particularly with buckets that contain a lot of data, become slow when <files_filelock_enabled> in aspera.conf is set to true (in order to enable the filelock feature in the Node API /files endpoint). The default setting is false.

NODE-405 - The max_rate_kbps in the output of a /events call is incorrectly reported as zero.

NODE-345 - A RESTful Node API POST to /ops/transfers can trigger two transfer sessions for the same file and result in a corrupted file at the destination and a slower final transfer rate.

NODE-257 - Reports sometimes fail if the Node API temporarily reports an impossibly large value for bytes_transferred.

NODE-236 - Transfers with a status of "waiting" cannot be canceled.

NODE-139 - The --token-key-length option in asnodeadmin allows invalid token key lengths.

NODE-137 - A Node API /ops/transfers call reports the incorrect values for files_completed and files_failed.

#33374 - Symbolic link capability is only available on local storage but an unimplemented function error does not appear when the user attempts to create a symbolic link to a file on cloud storage (S3) from the Node API.

#33229 - Users cannot browse a file on cloud storage by using a /files/browse API request.

#33206 - /ops/transfers erroneously shows some queued transfers (which are farther down in the queue) as failed before they complete.

#32669 - When a directory is linked from a subdirectory, it does not appear in the search result for a /files/search request in the Node API.

#32627 - When a file name is just a dot and an extension, (for example, .pdf), then it is reported as a file with "content_type"=>"application/pdf" or a hidden file named PDF; for example:
{"id"=>"27", "name"=>".pdf", "size"=>12, "content_type"=>"application/pdf", "type"=>"file", "modified_time"=>"2015-09-10T15:24:01Z", "access_level"=>"edit", "permission_count"=>0}

#31712 - For both S3 on AWS and SoftLayer Swift storage, /files returns modified_time for files but not for folders.

#30542 -/files PUT (file rename) should be fixed to involve only one PVCL operation but still return the proper 409 code when there is a destination conflict, and PVCL needs to return proper error codes stating that the move operation failed because of a destination conflict.

#29848 - When <write_allowed><read_allowed>, and <dir_allowed> are all set to false in aspera.conf, Node API calls to URLs such as /files/browse are returning response code 500 Internal Server Error: instead of another code that better indicates that access to the resource is denied.

#29787 - When the docroot is not configured, the HTTP error code 500 ("Internal Server Error") is returned.

#29187 - For content in cloud storage, the Node API does not display all the files in the docroot directory. Workaround: Use the /files/info request to browse the docroot directory when content is in cloud-based storage.

#29138 - For files in S3 storage, the Node API does not return the correct file modification time.

#29078 - When an access key is created with the standard node user authorization, the access key inherits that node user and its associated system user. Afterward, asnodeadmin can be used to associate a new system user to the node user, but the new system user is not updated for the access key.

#25127 - HTTP fallback temporary files (*.haspx) are not excluded by the Node API.

#23434 - Files that start with "._" are not returned by the Node API browse action.

#22619 - In the Node API, /files/search follows symbolic links.

#20002 - The Node API is inconsistent in how it handles ymbolic links. /files/browse doesn't follow the links and reports links and their target (final type and next name), while /files/info reports symbolic links as files or directories.

#18659 - Searches with very long path names (over 520 characters) report an "insufficient buffer space" error.

#18368 - Files with a backslash in the file name are not displayed in the list when the user browses the remote source on the new package page.

Watchfolder and Aspera Watch Service

WAT-567 - A Watch Folder configured for growing files reports a "Healthy" state and shows bytes are written at the destination despite having an invalid password and no transfer occurring.

WAT-559 - Watchd allows users to create a watch on the root folder, which can overload the Redis database and cause Watchd to coredump. (CIM-662)

WAT-501 - Some ascp sessions started by a Watchfolder may not stop running after synchronization is complete when many (50) large (1000 files of 2 KB to 1 MB) Watchfolders are started at the same time.

WAT-314 - asperawatchfolderd must be running in order to delete a Watchfolder.

WAT-200 - Recently finished Watchfolder drops are not stored and are lost if asrund is restarted.

WAT-174 - Watchfolder uses excessive memory when it watches 10 million files.

WAT-169 - If top_level_dirs drop detection is used with x top-level directories in Watchfolder, 7(x)+ drops are created. The drop count continually increases.

WAT-159 - If one file in a Watchfolder transfer fails or a drop is aborted, the other files in the package are reported as aborted but ascp is not stopped and the transfer continues.

#33877 - Aspera Enterprise licenses that are watchfolder-enabled don't display watchfolders as an enabled component.

Sync

ES-92 - Sync reports incorrect counts for 'deleted_paths', 'deleted_bytes', and 'cumulative_deleted_bytes'.

WAT-594 - During a Sync session, if ascp fails to transfer a file, Sync keeps the file as pending rather than as errored and the session does not stop. (CIM-814)

WAT-589 (#13645) - When a directory is renamed during transfer, Sync continues running and never completes.

WAT-571 - Sync deletes files from the destination if the files become inaccessible on the source, such as when permissions change. (CIM-729)

WAT-557 - A continuous Sync push that is run with the --scan-dir-rename option does not synchronize files if the directory is created and then renamed after the Sync session has started.

WAT-550 (#29686) - A continuous Sync push to S3 storage does not update the object in S3 when the source file is renamed or deleted while it is transferred.

WAT-523 - Meta-attributes are not preserved in sync sessions that use the --dedup=copy option.

WAT-465 - Sync hangs following a TCP impairment that produces a libssh2 timeout or error.

WAT-362 (#24812) - If a file's size decreases during a continuous Sync push, the file remains pending and is never synced.

WAT-288 (#27311) - An --apply-local-docroot pull copies the local docroot path into the same path. For example, /home/user1/sync is copied into /home/user1/sync.

WAT-287 (#32064,#32883) - When syncing a directory in continuous bidi mode, Sync keeps running with one pending file rather than complete and go idle.

WAT-9 - When the scan-file-rename option is used with asperawatchd, moved files should be detected and renamed at the destination, not deleted and replaced by a transferred, renamed file.

#29038 - Using overwrite=always when you sync with cloud storage does not overwrite the file. The default checksum behavior with S3 (as with any cloud storage) is "none". An existing file on S3 is considered identical to the local file when their sizes are equal. Therefore, the file on S3 is not overwritten even when the content of S3 differs from the content of the local file.

#28817 - The Sync log entry for SYNCERROR_DELAY does not include information that describes the file name and path.

#27621 - Hidden, temporary, or transient files, such as temporary files created by Microsoft Office products, can cause Sync to report conflicts.

#24805 - ACL data are preserved at the destination for all files and subdirectories in the source folder, but ACL data for the source folder itself are preserved at the destination.

#23954 - When the --preserve-acls or --preserve-xattrs option is used, async does not preserve the acl or xattr when either file acl or xattr is modified and (a) file content is unmodified or (b) file content is unmodified and the file is renamed.

#23004 - Aspera Console does not draw a line between the involved nodes for an async transfer. This issue occurs when two managed nodes are used with two interfaces on two different networks.

#22633 - Sync does not support large xattr/ResourceForks.

#22044 - asyncadmin reports all sessions are locked after the last actual running session.

#21014 - When creating a file with vi during a sync, the swap file is in conflict.

#20906 - async cannot create a watch on an unreadable directory; therefore, it does not get notified when permissions change. In addition, async treats an unreadable directory as "skip" rather than reporting an error or conflict.

#20767 - If you use the -R log dir from Linux to Windows and there are spaces in the directory path, the path is truncated at the first space in the path.

#20347 - Async reports errors and conflicts for deep directory depth when the sync is from Linux to Windows.

#19945 - asyncadmin creates SHM and WAL files for read-only operations. Once asyncadmin is run as the root, async run by the user does not have permission to access the existing SHM and WAL files and thus async fails. This issue is due to a bug in SQLite.

#16911 - Characters in the async session option that are not preceded by a "-" or "--" are ignored and no error message is reported. Any session options that are specified (such as -l or -a) after the string of characters that are not preceded by a "-" or "--" are also ignored. The session runs using the default values, and does not notify you that the command line settings were ignored.

#13761 - If file names contain "\" or new line, async transfer fails, causing the internal transfer queue to become full and the synchronization to stall.

Object Storage Support

TRAP-83 - Using the default configuration of the Java Heap size, Trapd might be unable to recover enough memory after a full garbage collection, resulting in an out-of-memory error. Workaround: Edit the configuration by opening /opt/aspera/etc/init.d/asperatrapd_init.sh and locating the following section:
trap_init_start()
{
...
    cdf_get_total_memory
    PROPS="$PROPS -Dsystem.total.memory="$TOTAL_MEMORY""
 
    MAX_JAVA_MEM=2000
    MIN_JAVA_MEM=512
    if [ $TOTAL_MEMORY -lt 2147483648 ]; then
...
Change the value of MAX_JAVA_MEM from 2000 to 6000.
TRAP-71 - Multi-session transfers to object storage can stall if the number of files open for write in multi-session mode exceeds the default number of starting threads (64). Workaround: Open /opt/aspera/etc/trapd/trap.properties and set aspera.session.max-starter-threads to a larger value. If this setting is not in the file, add the following line with an appropriate value:
aspera.session.max-start-threads=1280

TRAP-59 - If an incorrect DNS nameserver is set in /etc/resolve.conf and then corrected, TrapD must be restarted for the correct nameserver to be used by TrapD. If TrapD is not restarted, TrapD fails to connect and retries indefinitely. (CIM-469)

TRAP-57 - If a very large file (several TB) upload to AWS S3 is interrupted after more than 1 TB is transferred, resuming the transfer may take hours and the session may close before any data is transferred. (CIM-476)

TRAP-28 - When downloading from cloud or object storage, ascp always takes the equivalent of 1 GB of buffers from Trapd. This can lock buffers in ascp queues for hours and may prevent other ascp transfers from transferring normally.

TRAP-27 - In some cases, stopping Trapd while an ascp transfer is still running may cause a restart of Trapd to fail.

TRAP-26 - Sometimes when Trapd is being heavily loaded by many ascp transfers, Trap may return a 'No such file or directory' error.

#36067 - Deleting folders from a Limelight directory is slow.

#33214 - Transfers to and from cloud storage using authorization tokens with URIs that do not have a docroot specified are not supported.

#25636 - To use a larger chunk size to transfer large files to AWS S3 storage, some users modify the memory settings in the Trapd initialization script,asperatrapd_init.sh. If you do so, be sure to preserve the script manually during upgrades to prevent it from being overwritten.

PRODUCT SUPPORT

For on-line support resources for Aspera products, including raising new support tickets, please visit the Aspera Support Portal. You may have an existing account if you contacted the Aspera support team in the past. Before creating a new account, first try setting a password for the email that you use to interact with us. You may also call one of our regional support centers.

 

Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk