FileZilla Forums

I am working with another party to transfer a csv file to my server that resides behind a network managed by others. I have worked with the network management team to ensure all ports are open and available for file transfer. The network team is seeing data transfer from the other party and we can see the file on our server, but it comes through with a size of zero as opposed to the 6.7k that the network team sees in their logs. I am able to transfer files internal to the network using a different account that has similar rights and is using the same folder. Below is the log:
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> Connected on port 990, sending welcome message...
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> 220-FileZilla Server 0.9.60 beta
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> 220-written by Tim Kosse (tim.kosse@filezilla-project.org)
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> 220 Please visit https://filezilla-project.org/
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> TLS connection established
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> USER "account"
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> 331 Password required for "account"
(003534) 4/9/2019 7:00:50 AM - (not logged in) (IP)> PASS **********
(003534) 4/9/2019 7:00:50 AM - "account"(IP)> 230 Logged on
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> SYST
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 215 UNIX emulated by FileZilla
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> PWD
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 257 "/" is current directory.
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> TYPE I
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 200 Type set to I
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> SIZE file.csv
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 213 0
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> MDTM file.csv
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 213 20190327165457
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> PBSZ 0
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 200 PBSZ=0
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> PROT P
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 200 Protection level set to P
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> PORT 192,168,100,83,199,101
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 200 Port command successful
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> REST 0
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 350 Rest supported. Restarting at 0
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> STOR file.csv
(003534) 4/9/2019 7:00:51 AM - "account"(IP)> 550 Permission denied
(003534) 4/9/2019 7:01:21 AM - "account"(IP)> QUIT
(003534) 4/9/2019 7:01:21 AM - "account"(IP)> 221 Goodbye
(003534) 4/9/2019 7:01:21 AM - "account"(IP)> disconnected.

Any thoughts would be greatly appreciated.

The account has not been granted the permissions necessary to overwrite an existing file. Both write (to upload) and delete (as the old file no longer exists afterwards) are needed.

Well I'm no longer getting the 550 Permission Denied error, but the file is still arriving with zero size.

(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> Connected on port 990, sending welcome message...
(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> 220-FileZilla Server 0.9.60 beta
(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> 220-written by Tim Kosse (tim.kosse@filezilla-project.org)
(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> 220 Please visit https://filezilla-project.org/
(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> TLS connection established
(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> USER "account"
(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> 331 Password required for "account"
(003556)4/11/2019 7:00:49 AM - (not logged in) (IP)> PASS **********
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 230 Logged on
(003556)4/11/2019 7:00:49 AM - "account"(IP)> SYST
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 215 UNIX emulated by FileZilla
(003556)4/11/2019 7:00:49 AM - "account"(IP)> PWD
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 257 "/" is current directory.
(003556)4/11/2019 7:00:49 AM - "account"(IP)> TYPE I
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 200 Type set to I
(003556)4/11/2019 7:00:49 AM - "account"(IP)> SIZE ToledoOverride_st_pierre.csv
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 213 0
(003556)4/11/2019 7:00:49 AM - "account"(IP)> MDTM ToledoOverride_st_pierre.csv
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 213 20190327165457
(003556)4/11/2019 7:00:49 AM - "account"(IP)> PBSZ 0
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 200 PBSZ=0
(003556)4/11/2019 7:00:49 AM - "account"(IP)> PROT P
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 200 Protection level set to P
(003556)4/11/2019 7:00:49 AM - "account"(IP)> PORT 192,168,100,83,220,254
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 200 Port command successful
(003556)4/11/2019 7:00:49 AM - "account"(IP)> REST 0
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 350 Rest supported. Restarting at 0
(003556)4/11/2019 7:00:49 AM - "account"(IP)> STOR ToledoOverride_st_pierre.csv
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 150 Opening data channel for file upload to server of "/ToledoOverride_st_pierre.csv"
(003556)4/11/2019 7:00:49 AM - "account"(IP)> 450 TLS session of data connection has not resumed or the session does not match the control connection
(003556)4/11/2019 7:01:20 AM - "account"(IP)> QUIT
(003556)4/11/2019 7:01:20 AM - "account"(IP)> 221 Goodbye
(003556)4/11/2019 7:01:20 AM - "account"(IP)> disconnected.

What client software is in use? Looks like the client (or anything malicious in between) does not support TLS session resumption.

Session resumption on the data connection is an important security feature, it's the only safe way to prevent data connection stealing attacks.

The client being used is Globablscape CuteFTP.

Tried turning off Antivirus (Security Essentials) and reviewed the Windows Logs, but still not seeing where the data is being stripped from the file. Currently waiting to see if a different file type gives us the same results.

Any other ideas?

The problem is the used client, it does not use session resumption on the data connection. You need to update to a modern, secure client that uses session resumption.