Bug report for build .282

What is the problem you are having with rclone?

With the latest beta .282, there is something wrong with the RC command. After I start my usual mount, I run "rclone rc vfs/refresh recursive=true --fast-list -v" to prime the content. It now comes back with the following:

"Failed to rc: connection failed: Post "http://localhost:5572/vfs/refresh": net/http: timeout awaiting response headers"

The normal response is:

"result": {
"": "OK"

Tried three times in a row to make sure it wasn't a one-off. Went back to .281, and everything is OK.

Didn't have time to get a debug log. Might be able to later, if necessary.

What is your rclone version (output from rclone version)


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

Windows Server 2016 64-bit

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

rclone mount --attr-timeout 1000h --dir-cache-time 1000h --poll-interval 0 --rc --read-only -v
rclone rc vfs/refresh recursive=true --fast-list -v

The rclone config contents with secrets removed.

type = drive
client_id =
client_secret =
token =
root_folder_id =

type = crypt
remote = Google_Drive:crypt
filename_encryption = standard
directory_name_encryption = true
password =
password2 =

A log from the command with the -vv flag


1 Like

Since there was only one commit in between, it has to have something to do with this:

accounting: fix deadlock in stats printing

1 Like

I am using the same build on Linux and haven't faced this issue.

I suspect that your query is just on the edge of timing out - I think the timeout is 1 minute - how long does it normally take?

You can increase the timeout with --timeout 10m to see if that helps.

You can also run

rclone rc vfs/refresh recursive=true _async=true -v

Then rclone will run the query in the background without waiting for the reply

1 Like

Thanks Nick! Running with "_async=true" did the trick, but I will also try with "--timeout 10m" instead, because I like to actually see when it's done. One thing I noticed is that with async, the whole process seems to complete quite a bit faster. Could be placebo, though, since I didn't measure it.

To answer your question, priming usually takes between a minute and a half to two minutes. One thing that's always bugged me a bit is that I can't see the progress, even though I use -v. Would adding another v show what it's doing? Also, is --fastlist used by default, so it's not necessary to use the flag?

1 Like

That makes sense.

Neither -v or --fast-list have any effect when using the rc command. There isn't a way of getting progress out of the rc at the moment.

1 Like

Just tried it with "--timeout 10m", and it also works great. Thanks again!

(this is with .285, btw)


This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.