rclone: [FTPS] transfer hangs

What is the problem you are having with rclone?

After upgrading rclone from v1.53.3 to 1.62.2, the FTP transfers from remote to local sometimes get stuck. By “stuck” I mean no additional data is transferred and process seems to continue running indefinitely. Usually killing the process/restarting the container works - subsequent try succeeds. Note so far I’ve only noticed this when transferring a directory containing multiple files, ie single file transfers have not reproduced the issue yet. To re-iterate, I never saw this issue prior to version upgrade in my year+ usage. After version bump the first reproduction happened within 24h. But service upgrade also updated Alpine from 3.14 to 3.18, so I can’t confidently say it’s 100% related to rclone alone.

What is your rclone version (output from rclone version)

rclone v1.62.2-DEV
- os/version: alpine 3.18.0 (64 bit)
- os/kernel: 5.19.17-Unraid (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.20.4
- go/linking: static
- go/tags: none

Which OS you are using and how many bits (e.g. Windows 7, 64 bit)

64 bit alpine 3.18 running in Docker container; rclone pkg installed from community repo

Which cloud storage system are you using? (e.g. Google Drive)

FTPS. cloud provider host is shared among multiple customers.

rclone.conf

[remote]
type = ftp
host = remote.server.com
user = laur89
port = 21
pass = redacted
tls = false
explicit_tls = true
no_check_certificate = true
disable_tls13 = true

The command you were trying to run (e.g. rclone copy /tmp remote:tmp)

Note we’re running rclone locally, ie we’re pulling data from remote.

"rclone" "copy" "--log-file" "/config/logs/rclone-copy.log" "-vv" "--dump" "bodies" "--config" "/config/rclone.conf"
    "--fast-list" "--bwlimit" "20M" "--use-mmap" "--transfers" "10" "-L"
    "--filter" "- **/{S,s}ample/**" "remote:files/complete" "/data/rclone-tmp"
    "--filter" "+ /Filename\\.S02E08\\.HDR\\.2160p\\.WEB\\.H265-SCENE/**" "--filter" "- *"

Transferred directory as seen on remote

$ ls -lAtr  Filename.S02E08.HDR.2160p.WEB.H265-SCENE/
total 5.5G
drwxr-xr-x 2 laur89 laur89 4.0K May 19 06:31 Sample
-rw-r--r-- 1 laur89 laur89  600 May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.sfv
-rw-r--r-- 1 laur89 laur89  621 May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.nfo
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r02
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r04
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r03
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r06
-rw-r--r-- 1 laur89 laur89 383M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r08
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.rar
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r05
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r01
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r07
-rw-r--r-- 1 laur89 laur89 573M May 19 06:31 filename.s02e08.hdr.2160p.web.h265-scene.r00

Transferred directory as seen locally (in /data/rclone-tmp) at the time of termination

$ ls -lAtr  Filename.S02E08.HDR.2160p.WEB.H265-SCENE/
total 4.9G
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r06
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r05
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r01
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r08
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r04
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r03
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r02
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r00
-rw-r--r-- 1 laur users   0 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.r07
-rw-r--r-- 1 laur users 621 May 22 12:20 filename.s02e08.hdr.2160p.web.h265-scene.nfo

A log from the command with the -vv flag (e.g. output from rclone -vv copy /tmp remote:tmp)

See gist

How to use GitHub

  • Please use the 👍 reaction to show that you are affected by the same issue.
  • Please don’t comment if you have no relevant information to add. It’s just extra noise for everyone subscribed to this issue.
  • Subscribe to receive notifications on status change and new comments.

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 1
  • Comments: 20 (9 by maintainers)

Commits related to this issue

Most upvoted comments

@ncw to be clear, I was only downloading, and only TLS.

I’ve since moved on to something that would work for me, but I’ll try to reproduce with both version binaries and capture logs for you.

Hi @ncw I believe I am seeing the same bug, and I’m keen to help you fix it. We run CrushFTP and have been relying on the mirror command of lftp to download trees of files but it turns out to be slow, buggy and unmaintained. Rclone seems a great alternative.

To help my testing I made a script that generates pathological test cases with many files and long path names - https://github.com/EdinburghGenomics/transfer_test_maker

This is not so far off some of the real data we need to transfer. I then run Rclone:

~/bin/rclone copy -vv --inplace edge:rRlOPnynQqmnHyJBjCaUlwyGpFU2IO42/download_speed_test/v1 demo_20231016 |& tee demo_20231016_copy_vv.log

Rclone is:

rclone v1.64.0
- os/version: redhat 8.7 (64 bit)
- os/kernel: 4.18.0-425.10.1.el8_7.x86_64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.21.1
- go/linking: static
- go/tags: none

Config is:

[edge]
type = ftp
user = anonymous
pass = yMvopO3l-HqFoKUIxDslODwz00RrZA
explicit_tls = true
host = REDACTED

Log shows that after 5 minutes it grinds to a halt. demo_20231016_copy_vv_redacted.log

I thought it might be a network switch issue but trying the same download via the loopback interface on the FTP server itself yields the same result - timeouts after around 5 minutes. I was then assuming it must be a CrushFTP problem or misconfiguration but having seen this bug report I think it must be this Rclone bug.

I’ve redacted our server details from this public bug report. However, the server is on the public internet and I can provide access to anyone debugging this issue if you DM me. You can also recreate my test dataset using the Python code linked above which fills up files with pseudo-random bytes. I used this config with my script:

many_small_files:
    size: '200'
    number: [1000, 10000, 50000]
    pathnamelen: 40
    pathdepth: 3
some_big_files:
    size: ['1G', '5G', '50G']

Happy to run further tests etc. at our end.

Will do my best.