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
)
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
- check for stalled (rclone) processes - in case locking fails we now check for condition where DEST_INITIAL size has not grown for X seconds. if so, previoys sync.sh process tree gets killed. this... — committed to laur89/docker-seedbox-rclone-fetch-extract by laur89 a year ago
- check for stalled (rclone) processes - in case locking fails we now check for condition where DEST_INITIAL size has not grown for X seconds. if so, previoys sync.sh process tree gets killed. this... — committed to laur89/docker-seedbox-rclone-fetch-extract by laur89 a year ago
@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:
Rclone is:
Config is:
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:
Happy to run further tests etc. at our end.
Will do my best.