Aspera

I'm running Aspera Enterprise Server 4.4.3 on Rocky 9 and ran into an issue when using the SOAP API call to transfer a file.  The issue is the file cannot be read or get a "stat", according to the log file, to be transferred.  The directories and file are not readable by everyone for permissions.  If I run the ascp command manually from the CLI as root, it works.  I know I can just change the UMASK and the permissions on all directories and files to be readable by everyone, but would rather not due to security.  Does anyone know which user the ascp is executed by when the server receives a SOAP API call?  The log also shows a userid = 0, which is root, but if that was the case, this would work.  If I knew the user, I could add it to the group that owns the files/directories and it should work.

On an older version of Aspera, 3.9.6, it works with the same file/directory permissions.  Both the servers are connected to the same NAS.

Hi Jeremy,

I think the SOAP calls are executed by the daemon named : asperacentral

Since 4.x it is run under user: asperadaemon

Note that the SOAP API is deprecated and it is recommended to use the REST API instead.

(The REST API has a mechanism ensuring that a transfer is executed as the right user in /ops/transfers)

You can check relatively easily on the HSTS which user runs ascp yourself if you have access to the HSTS (I do that from time to time for some verifications):

• method 1: in a terminal run: while :;do ps -ef|grep ascp|grep -v grep;done : this will display the ascp command and the user running it as soon as it is executed.
• method 2:

cd /opt/aspera/bin

mv ascp ascp.bin

cat<<EOF>ascp

#!/usr/bin/bash

env >> /tmp/ascp.info

id >> /tmp/ascp.info

exec $0.bin "${@}"

EOF

chmod a+x ascp

This replaces the ascp executable with a script that will eventually run it, but in the meantime you have the possibility to extract the information you want.

Of course after testing, replace the original ascp.

Just for curiosity: is there a specific reason why you want to the legacy SOAP API instead of the newer REST API ?

I'm running Aspera Enterprise Server 4.4.3 on Rocky 9 and ran into an issue when using the SOAP API call to transfer a file.  The issue is the file cannot be read or get a "stat", according to the log file, to be transferred.  The directories and file are not readable by everyone for permissions.  If I run the ascp command manually from the CLI as root, it works.  I know I can just change the UMASK and the permissions on all directories and files to be readable by everyone, but would rather not due to security.  Does anyone know which user the ascp is executed by when the server receives a SOAP API call?  The log also shows a userid = 0, which is root, but if that was the case, this would work.  If I knew the user, I could add it to the group that owns the files/directories and it should work.

On an older version of Aspera, 3.9.6, it works with the same file/directory permissions.  Both the servers are connected to the same NAS.

Hi Jeremy,

I think the SOAP calls are executed by the daemon named : asperacentral

Since 4.x it is run under user: asperadaemon

Note that the SOAP API is deprecated and it is recommended to use the REST API instead.

(The REST API has a mechanism ensuring that a transfer is executed as the right user in /ops/transfers)

You can check relatively easily on the HSTS which user runs ascp yourself if you have access to the HSTS (I do that from time to time for some verifications):

• method 1: in a terminal run: while :;do ps -ef|grep ascp|grep -v grep;done : this will display the ascp command and the user running it as soon as it is executed.
• method 2:

cd /opt/aspera/bin

mv ascp ascp.bin

cat<<EOF>ascp

#!/usr/bin/bash

env >> /tmp/ascp.info

id >> /tmp/ascp.info

exec $0.bin "${@}"

EOF

chmod a+x ascp

This replaces the ascp executable with a script that will eventually run it, but in the meantime you have the possibility to extract the information you want.

Of course after testing, replace the original ascp.

Just for curiosity: is there a specific reason why you want to the legacy SOAP API instead of the newer REST API ?

I'm running Aspera Enterprise Server 4.4.3 on Rocky 9 and ran into an issue when using the SOAP API call to transfer a file.  The issue is the file cannot be read or get a "stat", according to the log file, to be transferred.  The directories and file are not readable by everyone for permissions.  If I run the ascp command manually from the CLI as root, it works.  I know I can just change the UMASK and the permissions on all directories and files to be readable by everyone, but would rather not due to security.  Does anyone know which user the ascp is executed by when the server receives a SOAP API call?  The log also shows a userid = 0, which is root, but if that was the case, this would work.  If I knew the user, I could add it to the group that owns the files/directories and it should work.

On an older version of Aspera, 3.9.6, it works with the same file/directory permissions.  Both the servers are connected to the same NAS.

I'm running Aspera Enterprise Server 4.4.3 on Rocky 9 and ran into an issue when using the SOAP API call to transfer a file.  The issue is the file cannot be read or get a "stat", according to the log file, to be transferred.  The directories and file are not readable by everyone for permissions.  If I run the ascp command manually from the CLI as root, it works.  I know I can just change the UMASK and the permissions on all directories and files to be readable by everyone, but would rather not due to security.  Does anyone know which user the ascp is executed by when the server receives a SOAP API call?  The log also shows a userid = 0, which is root, but if that was the case, this would work.  If I knew the user, I could add it to the group that owns the files/directories and it should work.

On an older version of Aspera, 3.9.6, it works with the same file/directory permissions.  Both the servers are connected to the same NAS.