Issue Backup failing to connect to remote FTP server

[Hezola]

Server operating system version

OS CentOS Linux 7.9.2009 (Core)

Plesk version and microupdate number

Product Plesk Obsidian Version 18.0.54 Update #4, last updated on Aug 25, 2023 03:37 AM

Hi

We have a customer with 2 servers - same specs:

OS CentOS Linux 7.9.2009 (Core)
Product Plesk Obsidian Version 18.0.54 Update #4, last updated on Aug 25, 2023 03:37 AM

They report: "For months/years we've been using the 'backup & restore' option on server1.xxxxx.co.uk to run monthly backups of some of the domains we host. The server sends the backup files to an FTP service we host in our office network. In the last few days this has stopped working and I can't work out why. The error within Plesk for a domain:

Error: Unable to access the storage: Transport error: unable to list directory: Curl error: (28) Timeout was reached: Last FTP request: LIST Last FTP response: 200 Switching to ASCII mode
Make sure you have entered the correct storage settings. You can check them independently with the command:
curl -v -P - -u username 'ftp://xxxxxxx/www/'

I can remotely connect to the FTP server myself (with FileZilla) and so I'm assuming our FTP server, internet connect, NAT, DynDNS etc are all still working correctly (?) and am wondering whether the problem may be within server1."

I have removed identifying URLs and FTP details

The Curl connection works fine from the server.

They have server2 - same specs - where this is not an issue. It just works, connects, and will back up remotely.

I have tried passive mode on/off FTPS on/off and all combinations thereof.

PPM/migration.log gives:
[2023-09-07 12:01:09.328| 5222] INFO: TransportError Transport error: unable to list directory: Curl error: (28) Timeout was reached: Last FTP request: LIST Last FTP response: 200 Switching to ASCII mode [common/plesk-utils/PMM/repository-transport/transport.cpp:TransportError]
virtual void plesk::tRepositoryFtp::ListDirEx(const std::string&, std::__cxx11::list<plesk::FileInfo>&)

The following appear to be correct on both servers:
PassivePorts 49152 65535
PassivePorts 50000 50500

and those ports are allowed in Plesk firewall.

I have also followed: https://support.plesk.com/hc/en-us/articles/12377107965975

but no change.

The latest recent test resulted in:
Error: Unable to upload the file to the storage: Stream error: /check1/test: Curl error: Unable to resume an interrupted upload: (28) Timeout was reached: Last FTP request: STOR test: Last FTP response: 200 Switching to Binary mode: Connection to the FTP server has lost
Check if you have permissions to upload files to the storage. You can check it independently with the commands:
echo 123 | curl -T - --ftp-create-dirs -v -P - -u

Any help or advice gratefully received.

 

[Peter Debik]

Check if you have permissions to upload files to the storage. You can check it independently with the commands:
echo 123 | curl -T - --ftp-create-dirs -v -P - -u

You did not mention it, but I assume you also tested this and it worked out correctly? So only when the backup software does the same it does not work?

 

[Hezola]

Hi.

Thanks for looking into - sure - I have run:
echo 123 | curl -T - --ftp-create-dirs -v -P - -

Results are:

Enter host password for user 'user':
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* About to connect() to backups.storm12.co.uk port 21 (#0)
* Trying 86.171.9.226...
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0* Connected to backups.storm12.co.uk (86.171.9.226) port 21 (#0)
< 220 (vsFTPd 3.0.2)
> USER
< 331 Please specify the password.
> PASS
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0< 230 Login successful.
> PWD
< 257 "/"
* Entry path is '/'
> CWD www
* ftp_perform ends with SECONDARY: 0
< 250 Directory successfully changed.
> CWD test-dir
< 550 Failed to change directory.
> MKD test-dir
< 257 "/www/test-dir" created
> CWD test-dir
< 250 Directory successfully changed.
> EPRT |1|213.246.109.33|60372|
< 200 EPRT command successful. Consider using EPSV.
* Connect data stream actively
> TYPE I
< 200 Switching to Binary mode.
> STOR test-file.txt
< 150 Ok to send data.
* Preparing for accepting server on data port
* Checking for server connect
* Ready to accept data connection from server
* Connection accepted from server
} [data not shown]
* Remembering we are in dir "www/test-dir/"
< 226 Transfer complete.


and the same test just after:

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* About to connect() to backups.storm12.co.uk port 21 (#0)
* Trying 86.171.9.226...
* Connected to backups.storm12.co.uk (86.171.9.226) port 21 (#0)
< 220 (vsFTPd 3.0.2)
> USER
< 331 Please specify the password.
> PASS
< 230 Login successful.
> PWD
< 257 "/"
* Entry path is '/'
> CWD www
* ftp_perform ends with SECONDARY: 0
< 250 Directory successfully changed.
> CWD test-dir
< 250 Directory successfully changed.
> EPRT |1|213.246.109.33|35228|
< 200 EPRT command successful. Consider using EPSV.
* Connect data stream actively
> TYPE I
< 200 Switching to Binary mode.
> STOR test-file.txt
0 0 0 0 0 0 0 0 --:--:-- 0:00:59 --:--:-- 0< 425 Failed to establish connection.
* Failed FTP upload: 425
* Remembering we are in dir "www/test-dir/"
0 0 0 0 0 0 0 0 --:--:-- 0:01:00 --:--:-- 0
* Connection #0 to host backups.storm12.co.uk left intact
curl: (25) Failed FTP upload: 425

It does not work as far as my testing goes using the Backup and Restore per domain

 

[Peter Debik]

If you are sure that you tried "passive mode" and that your passive ephemeral port range is open, then it could be an intermediary firewall that is filtering packets. Do both servers run on the same infrastructure?

 

[Hezola]

Unsure what you mean by infrastructure - they are both Centos7 servers. Server1: CPU Intel Xeon E3-1230 v3 3.3GHz 8GB RAM 2 x1000 SATA - thats the problem server while: server2: CPU Intel Xeon E-2224 16GB 2x 500 SSD - dont think there is any intermediary firewall between - certainly not through us. I have heard further from customer though:
"More confusion this morning. One of our subscriptions (domain1.com) backed up perfectly yesterday morning and one (domain2.com) failed this morning.

Remote storage settings in Plesk are identical.


Within Plesk I checked the remote storage settings for the two subscriptions. FTP server log for domain1.com:
Mon Sep 11 09:05:38 2023 [pid 20058] CONNECT: Client "ip address"
Mon Sep 11 09:05:38 2023 [pid 20057] [user] OK LOGIN: Client "ip address"
FTP server log for domain2:
Mon Sep 11 09:06:49 2023 [pid 20063] CONNECT: Client "same IP address"
Mon Sep 11 09:06:49 2023 [pid 20062] [user] OK LOGIN: Client "same ip address"

I don't understand how some subscriptions are working while others aren't."

I have changed the domains and IP addresses for privacy.

 

[Peter Debik]

The backup issue again points to a network issue. I cannot say more to this, it needs to be examined what happens with the network traffic, how far it gets to the destination, where it is blocked.