EldoS | Feel safer!

Software components for data protection, secure storage and transfer

Transfer failed possibly due to access restrictions

Posted: 09/03/2010 01:26:25
by  Matt Atawneh
Hi there i'm trying to upload a file to an sFTP client, authentication types are set to 22, i'm opening a connection with no problems at all, then uploading the file, its takes quite some time, i looked at the sFTP site via a client i use and the file is indeed upload successfully, however after waiting a fair period, it throws an exception "Transfer failed possibly due to access restrictions" how can this be if the file is going successfully, why am i getting this error back? any help would be greatly appreciated
Posted: 09/03/2010 01:49:45
by Eugene Mayevski (Team)

This can happen if the server first writes the file to the temporary location, then move it to the final destination, and this move operation fails.

1) Do you succeed in file uploading with other software?
2) Do you have the same problem with the sample application?

Sincerely yours
Eugene Mayevski
Posted: 09/03/2010 02:04:05
by  Matt Atawneh
The server renames the files once they have been upload by assigning them a timestamp suffix.

Using other software the files are being uploaded without any issues at all.
Using the sample application it uploads without problems.

I'm trying to find an angle that may explain what is happeneing, like if they appear on the server, why do we get this lag and then the error?
Posted: 09/03/2010 02:34:00
by Ken Ivanov (Team)

There is a bunch of possible reasons for this problem. The easiest way would be to compare your code with the code of the sample and find the differences.

Special attention should be paid to the values of the following properties:
- AutoAdjustTransferBlock,
- PipelineLength,
- UploadBlockSize,
- AdjustFileTimes,
- UseTruncateFlagOnUpload.

Please check whether the values of above properties are the same within the sample and your application.
Posted: 09/05/2010 20:03:59
by  Matt Atawneh
Thanks for the feedback,
went through all the properties you mentioned and they are exactly identical, the values are below

AutoAdjustTransferBlock Demo=true, my code=true
PipelineLength Demo=32, my code=32
UploadBlockSize Demo=32768, my code=32768
UploadBlockSize Demo=false, my code=false
UseTruncateFlagOnUpload Demo=false, my code=false

sadly the issue still stands out.
Posted: 09/05/2010 23:05:01
by Ken Ivanov (Team)

Thank you for checking.

Another reason I can assume is that a wrong remote path is specified. Please note that SFTP accepts all paths in absolute ("/dir1/dir2/dir3") or relative ("./dir2/dir3") forms. It is highly recommended to use either absolute paths or relative paths starting from user's home directory (beginning with "." character). Relative paths without a "." character at the beginning are handled differently by different servers and should not be used.

If you are sure that the path is correct, could you please put a breakpoint in the catch() block that handles the exception and get a call stack for us?
Posted: 09/07/2010 02:49:05
by  Matt Atawneh
I ran through some test cycles with the bank where we are uploading the files, the case is as follows:
1. We generate a file.
2. Encrypt and Sign the file using PGP.
3. Submit the file via sFTP.

Because of the issue we had with the error above we tried to submit the file manually, which they could not verify or decrypt and were constantly getting a message stating "For your eyes only", after altering the PGPWrtier settings, we managed to overcome this, and the exception no longer appeared.

Can you please explain how a setting on a PGP file would cause an error on sFTP, all i know is that after we submit the file, the name is timestamped and put on a queue, once it reaches its processing time, is decrypted and verified, then sent for processing.

Thanks in advance
Posted: 09/07/2010 06:41:13
by Ken Ivanov (Team)

Do I understand you right that with the TElPGPWriter.Filename property set the upload issue does not appear anymore?

It is possible that the server performs some pre-processing right after the file is uploaded (in particular, it may try to extract the filename from it). If the file is protected in for-your-eyes-only mode, the server might, say, try to create a file with empty name and fail. Just as an assumption.
Posted: 07/29/2011 10:57:23
by Joseph Lewis (Priority Standard support level)
Joined: 07/26/2011
Posts: 1

I stumbled upon this thread while trying to solve the "Transfer failed possibly due to access restrictions" problem and wanted to provide additional details on the solution since the information here helped us a lot.

We have a similar three step process where one program creates a file, a second program creates a signed PGP encrypted file using 'PgpWriter' method EncryptAndSign() after which a third program transmits the file to a bank(JP Morgan Chase) using the ElSimpleSftpClient. The "Transfer failed ..." exception would be generated in the UploadFile() method at the end of the SFTP file transfer. Looking at the destination directory after the exception we could see that the file was actually transferred and present on the destination server.

Thanks to the above thread we focused on the 'PgpWriter' settings instead of the transfer itself. After changing the 'PgpWriter' logic we encrypted a new file the SFTP transfer was successful and did not get the exception. As we discovered our customer's test private key had multiple signers in it and the bank only wanted one signer.

As Innokentiy Ivanov correctly stated above, servers may perform some type of pre-processing as part of the transfer processing and a problem with the contents of the file may result in an exception which at first blush may look like a transmission problem when in fact the problem was with the file contents. The "Transfer failed possibly due to access restrictions" exception was very misleading in our case.

Hope this helps!
Posted: 08/01/2011 02:06:13
by Vsevolod Ievgiienko (Team)


Thank you for your investigation and its description. This information can be really helpfull for other users.



Topic viewed 5311 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS business operates as a division of /n software, inc. For more information, please read the announcement.

Got it!