Custom Query (8143 matches)

Since last week, one of my customer cannot connect to FileZilla server. Keep in mind that it was working before.

One of her colleague is able to connect to the server on the same network and I can connect with her account on another network.

In the window, it says:

AUTH TLS 502 - Auth command is not supported. 502 - Please contact your network administrtator to enable FTPS service

What cause this issue?

FileZilla Client

Version: 3.63.2.1

Build information:

Compiled for: x86_64-w64-mingw32 Compiled on: x86_64-pc-linux-gnu Build date: 2023-03-03 Compiled with: x86_64-w64-mingw32-gcc (GCC) 10-win32 20210110 Compiler flags: -O2 -g -Wall -Wextra -Wno-deprecated-copy -ffunction-sections -fdata-sections -Wno-cast-function-type

Linked against:

wxWidgets: 3.2.1 SQLite: 3.39.4 GnuTLS: 3.8.0

Operating system:

Name: Windows 11 (build 22621), 64-bit edition Version: 10.0 Platform: 64-bit system CPU features: sse sse2 sse3 ssse3 sse4.1 sse4.2 avx avx2 aes pclmulqdq rdrnd bmi bmi2 adx lm Settings dir: C:\Users\TR\AppData\Roaming\FileZilla\

Issue-This version of Filezilla is not handling illegal characters correctly. Previous versions have not had this specific trouble to replace illegal characters from the server while transferring to a Windows system.

The attached screenshot shows 3 files that failed transfer from server to Windows directory due to the illegal Windows character colon (:) present in the 3 files. The first transfer initiated using the filezilla preference of Automatic for FTP File Types resulted in the 3 files failing.

When I changed the Filezilla preference to Binary for FTP File Types and retried the folder download, the same 3 files failed.

This is not correct behavior and is also strange because in the Filezilla queue area the illegal character colon has been replaced with underscore. You can confirm that the illegal character exists on the server by reviewing the 2 highlighted files on the server side of Filezilla remote window.

Local Directory

"T:\pathfinder\199800 Fantastic Four 1_2 (Wizard).cbr" "T:\pathfinder\199800 Generation X 1_2 02 of 02 covers.cbz" "T:\pathfinder\199800 Spider-Man 1_2 (Wizard) 02 of 02 covers.cbz"

Remote Directory

"\199800 Fantastic Four 1:2 (Wizard).cbr" "\199800 Generation X 1:2 02 of 02 covers.cbz" "\199800 Spider-Man 1:2 (Wizard) 02 of 02 covers.cbz"

Note: When I initially tried to download multiple directories that contained illegal characters, filezilla basically crashed (no further input or output from filezilla window). Filezilla needed to be closed completely and restarted in order to resume normal operations.

By trial and error I was able to figure out that the illegal characters in the directories was what Filezilla took issue with. I decided to download the files individually from the server to see if it could complete successfully and they did. (See the 3 files outside of the directories in the screenshot). So, Filezilla can transfer files with illegal characters correctly individually, but from within a directory queue Filezilla is failing to transfer correctly.

I also confirmed that the files could be downloaded successfully with the illegal characters replaced by installing WinSCP and queuing the 5 directories I tried with Filezilla. All directories were successfully downloaded using the Automatic File Type preference and the illegal colon (:) characters were replaced with %3A.

I just updated my FileZilla client for the first time in a while (via the prompt on startup), and after that it started giving me an error message every time it started or closed the program. The error on starting was:

An error occurred loading the transfer queue from
"C:\Users\myusername\AppData\Roaming\FileZilla\queue.sqlite3".
Some queue items might not have been restored.

The error on closing was almost identical:

An error occurred saving the transfer queue to
"C:\Users\myusername\AppData\Roaming\FileZilla\queue.sqlite3".
Some queue items might not have been saved.

Additional information:

• The program is installed to a different drive than the folder it is trying to write to. It is located at "E:\Program Files\FileZilla FTP Client" and the folder it is trying to write to is on the C drive (listed above). Not sure if this is relevant or not, but you said to be verbose.

• The file did exist in the location the program was looking, and the previous version of the client could read and write to it just fine.

• The error messages stopped showing up when I deleted queue.sqlite3 and let the program regenerate the file, although I have kept the old queue.sqlite3 just in case. This means that the issue is solved for me, but I figured you might still want to know that this file isn't always compatible if you forget to update for a while and then go up by a couple versions at once.