Hi I have an automated upload process that was running great for a long time and now is failing after they moved the servers to a new Data Center. The Upload process fails with the following Error: Exception calling "GetRequestStream" with "0" argument(s): "The remote server returned an error: (550) File unavailable (e.g., file not found, no access)." Exception: MethodInvocationException Target site: PipelineBase.Invoke Stack trace: at System.Management.Automation.ExceptionHandlingOps.ConvertToMethodInvocationException(Exception exception, Type typeToThrow, String methodName, Int32 numArgs, MemberInfo memberInfo) at CallSite.Target(Closure , CallSite , Object ) at System.Dynamic.UpdateDelegates.UpdateAndExecute1[T0,TRet](CallSite site, T0 arg0) at System.Management.Automation.Interpreter.DynamicInstruction`2.Run(InterpretedFrame frame) at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame) I was wondering if anyone can give me some guidance on this error. I can't really find anything out on Google that helps. I can open FileZilla from the automation server and connect and even upload files and it works fine. So I am kind of at loss. Any ideas? Thanks in advance. Jeff
From your logs and description it looks like your automated process is using ftp protocol to upload a file to some FTPDir. Now it depends also what else operations the process is doing on that file and with previously uploaded files in the FTPDir. Since the LF v3.2 has been added a protection in the FTPDirs, which does not allow to rewrite previously uploaded files with same filenames, but FTPDir adds a timestamp suffix to the newly uploaded file. So if the process is trying to perform some operation with a file like abcd.doc, but there was available only abcd.doc.20180523 the it could end up with the error 550 - not found. Maybe this information could help you in the next troubleshooting.
Hi David, Thanks for your response. The files that are uploaded have unique names and are only there for 10 or 15 minutes before they are grabbed by a vendor and then deleted. We recently had to change the connection string to NormalWithExplicitTlsSsl31Authentication from Normal because of an LF update. So the operation is fairly simple. So as to not piss off the Engineers here, I have uploaded the files manually with FileZilla to the LF server (same credentials) without issues. Just my automation is broken (Orchestrator process).
Here is some more info, the FileZilla connection log: Status: Resolving address of fta.shapetechnologies.com Status: Connecting to 65.122.178.150:21... Status: Connection established, waiting for welcome message... Status: Initializing TLS... Status: Verifying certificate... Status: TLS connection established. Status: Logged in Status: Retrieving directory listing... Status: Server sent passive reply with unroutable address. Using server address instead. Status: Directory listing of "/" successful
Some more Info if this helps: FTP connection settings in Orchestrator - Connection Type: NormalWithExplicitTlsSsl31Authentication Transfer Type (FTP): Passive Server: fta.shapetechnologies.com Port: 21 Username:Yes, used the same with FileZilla Password:Yes, used the same with FileZilla Upload File IP Activity Properties - SourcePath: C:\Temp\Test\ DestServer: fta.shapetechnologies.com DestPath: Filename: File.txt Username: username Password: password Secure: False AutoAcceptKey: True UsePassive: True UseBinary: True I am really stuck here. Any help is appreciated.
Have you tried the test upload via the FileZilla client from the same network where the Orchestrator is running? Note: If some FTP Masquerade IP address (Admin > System > Network) has been set in the LF server then for the Orchestrator is important to be able access the LF's FTP service via that IP address, to be able perform directory listing.
Hi David, Yes, I have been uploading the files to the LF server with FileZilla from the Orchestrator server each day so our engineers can keep working with the vendor the files go to.
Ok, then from the same machine booht should normally work. What about TLS support. Filezilla usually use automatically the highest available protocol which is TLS1.2 on LF servers, but can you check if that Orchestrator supports: TLS1.2 or TLS1.1 or at least TLS1.0 protocol which is the weakest one that this LF server allows to negotiate connection?
Hi David, The connection type is NormalWithExplicitTlsSsl31Authentication. This is the connection that worked before the datacenter move.
This issue has been resolved. The issue was a network one, not config of FTP process. Thanks for your help.
Apparently the "Network Issues" was, reboot the Liquid Files server. Wish I had thought to do that, but didn't think there was an issue with the Liquid files server since FileZilla worked. Learn something everyday.