| Aspera Sync |
265
Causes:
Possible causes include the following:
•
async
binary doesn't exist (or is not in the path and sshd cannot find/execute it).
•
async
binary cannot be run.
•
async
binary cannot initialize properly (such as when the system is out of memory or socket resources).
•
async
binary cannot create its log files, if specified with
-R
(bad path, bad permissions).
Solutions:
• Confirm that the
async
binary is present. Look in the following location:
/opt/aspera/bin/
• Confirm that the Aspera license shows that Aspera Sync is enabled. Run the following command and look for
sync2
in the list of enabled settings:
# ascp -A
• If the system is under-resourced, increase the timeout allowed between the start of an
async
session and the
FASP transfers associated with it by running the following command. In this example, the timeout is increased to
10 minutes (600 seconds):
# /opt/aspera/bin/asconfigurator -x
"set_node_data;async_connection_timeout_sec,600"
• Confirm that the path in the argument for
-R
is valid and that the Aspera Sync user has write permissions to the
directory.
Never-ending bidirectional session, with one file stuck in "pending" state
Causes:
This can happen if a file is not in error for Aspera Sync but is in error for the underlying
ascp
process. For
example, when
async
is run with
--checksum=none
and access to the file is denied,
async
does not open the
file to calculate a checksum so it does not recognize that the file is unavailable, but
ascp
cannot open the file and
reports an error. This can also happen if a file is truncated during the initial synchronization; the server
ascp
reports
an error but the client
ascp
does not.
How to recover:
Stop the Aspera Sync session by running the following command:
# asyncadmin -d
path
-N
name
-T
Check file permissions on the source and destination, and confirm that files are no longer being modified. Rerun your
Sync session. You do not need to use
-x
.
Async fails with no specific reason
Causes:
This can happen if the
async
user does not have permission to the files. This problem often arises when
scripts are used to write files to one of the endpoints and the system permissions are overridden. Check the user's
permissions to the files.
How to recover:
Stop the
async
session by running the following command:
# asyncadmin -d
path
-N
name
-T
Edit the script to write files with the correct permissions, and rerun the
async
session.
Error returned when you try a synchronization from Linux to Windows.
When you try to synchronize from Linux to Windows, you receive the following error:
Failed. Peer error: Symlink policy copy not supported on Windows peer.
