Rclone mount random slow speeds

What is the problem you are having with rclone?

Starting about a month or two ago, randomly my mount speeds will drop to around 300KB/s and cause buffering. After restarting the mount once or twice, it returns back to normal. I am using mergerfs to combine two mounts and serve to a plex server running on an nvidia shield using smb. Has been working fine for the past year. I am running this on a Raspberry pi 4 (4GB) on ubuntu

I have another mount with the same config, just different remote and it has the same problems as well. This can happen a couple times a day and I need to restart the mounts.

Hopefully I have provided all the required info. Appreciate your help

Run the command 'rclone version' and share the full output of the command.

rclone v1.58.1

  • os/version: ubuntu 20.04 (64 bit)
  • os/kernel: 5.4.0-1065-raspi (aarch64)
  • os/type: linux
  • os/arch: arm64
  • go/version: go1.17.9
  • go/linking: static
  • go/tags: none

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)

Here is my rclone mount service file

Description=RClone Service

ExecStart=/usr/bin/rclone mount src096:m4dbackup/rinzry/Plex /mnt/external/Plex \
# This is for allowing users other than the user running rclone access to the mount
--allow-other \
# Google Drive is a polling remote so this value can be set very high and any changes are detected via polling.
--dir-cache-time 5000h \
# The log level output
--log-level DEBUG \
# Location of the log file
--log-file /mnt/external/rclone.log \
# I reduce the poll interval down to 10 seconds as this makes changes appear fast the API quotas per day are huge
--poll-interval 10s \
# This is setting the file permission on the mount to user and group have the same access and other can read
--umask 002 \
# Please set this to your own value below
--user-agent someappname101 \
# This sets up the remote control daemon so you can issue rc commands locally
--rc \
# This is the default port it runs on
--rc-addr :5574 \
# no-auth is used as no one else uses my server and it is not a shared seedbox
--rc-no-auth \
# The local disk used for caching
--cache-dir=/mnt/external/cache \
# My quota per user / per 100 seconds is 20,000 requests. This can be found in your quota section.
# This changes the sleep calls to something much lower to take advantage of the API boost.
# change the min sleep from 100ms
--drive-pacer-min-sleep 10ms \
# Changing to have the ability to burst higher
--drive-pacer-burst 200 \
# This is used for caching files to local disk for streaming
--vfs-cache-mode full \
# This limits the cache size to the value below
--vfs-cache-max-size 100G \
# This limits the age in the cache if the size is reached and it removes the oldest files first
--vfs-cache-max-age 5000h \
# The polling interval for increased based on there is enough buffer space
--vfs-cache-poll-interval 5m
# This sets a per file bandwidth control and I limit this to a little bigger than my largest bitrate I'd want to play
#--bwlimit-file 3.75M
ExecStop=/usr/bin/fusermount -uz /mnt/external/Plex
ExecStartPost=/usr/bin/rclone rc vfs/refresh recursive=true --rc-addr _async=true


The rclone config contents with secrets removed.

type = drive
scope = drive
service_account_file = /home/ubuntu/AutoRclone2/accounts/63b82cb8ab4ef4b90b6f966b65a9b7c17b7362ce.json
team_drive = 0AIr0EnuzN****9PVA

A log from the command with the -vv flag

Please see the pastebin. It was too long to include in here


1 Like

hello and welcome to the forum,

not an expert at rclone mount debug logs, but i did not see any issues.

when the issue occurs
--- need to see the debug log.
--- what is the result of a speedtest?
--- what is the result of a rclone copy src096: /path/to/local?
--- all other apps on the server, have no issues with the internet connection?

The current debug log is from when the issue occurred. It looks the same from the other times.

I'll test again when it happens, but generally speedtest is fine, LAN is fine, seems to be just the mount. I have tested using rclone md5sum directly on the mount and get the same result as the plex server smb mount.

I will try with a copy and see what happens

So LAN and internet is fine. Speedtest shows 38 mbps (with rclone mount running in the background) and rclone is still downloading at 300-500KB/s

Rclone copy seems to work fine

but mount is stuck at 300-400KB/s

Speed test runs fine with mount running in background

I have no idea what is going on. I thought at first it might be google api limits but then the rclone copy with the same remote would be slow as well?

If I stop the md5sum and then start it again a couple seconds later, somtimes speeds jump back up to normal and sometimes it stays the same?

Here is logs from around the time where it was throttled: https://rentry.co/6gqsi

I've been wrestling with the same (or very similar) problem for a few weeks now. Files will play through jellyfin or plex fine most of the time, but occasionally will only transfer the file at around 300k/s like OP which causes them to pause a few seconds into the episode. Stopping and starting the episode once or twice typically resolves the issue (and checking bw monitor indicates it's transferring at a normal rate) but it's frustrating and I'm all out of ideas. I've tried numerous rclone mount settings with no change. Debug logs show nothing helpful.

Exact same thing is happening to me. Experimented with lots of different settings for the mount. Seems to only affect a single file at a time seemingly at random.

My setup is a little different. VPS with rclone mounted with VFS.

I will add that restarting the mount has no effect, the only solution is to try again later and that same file is now suddenly super quick. Or wait out the slow file and the next file my server moves onto is fine.

Yeah, I'm finding that restarting doesn't really do anything as well. Sometimes it works but I guess it's more waiting it out or restarting the file transfer. And it seems to affect one file like you said.

Hopefully there's a solution soon

Also experiencing the same issue, Even happens with "rclone copy" commands. Stopping and restarting the copy process all of a sudden it goes from ~300kb/s to 90mb/s

I understand there was a change with Google API recently that had to be ported into rclone, but ive also tested with version 1.55.1 which as i understand it was prior to this change occurring.. Not sure if we are being limited by Google themselves or if this is an issue with rclone itself?

I've enabled debug logging on the mount point and can't see anything erroring out, just slow

I've seen this too. I think some google endpoints are slow and some are fast and it is luck as to whether you get a slow one.

Wow, this is worrisome. What do you mean by “endpoints”?
Is this something completely out of our control? It started all of a sudden for me too… some weeks ago. Since I could not find any error in the logs I did not even know how to ask help for this.

I tried describing this here: Difference between mounting and serving through WebDAV - #3 by ashlar

Assuming its a endpoint thing, is there anyway to force trying another endpoint that you can think of. If nothing else than to test the theory.

If that does end up being the problem I wonder if it would be possible to detect that somehow and trigger a endpoint change.

if i remember correctly,
there have been posts about changing dns servers and how that can affect gdrive performance.

I've updated my server's nameservers to google's, and am monitoring. Will report back

Sadly setting google's DNS servers don't appear to change anything for me :frowning:
I also tried mapping the google drive windows client to my server and while it was more performant when it worked than rclone, I would still get randomly capped at 300ishk/s for no clear reason. Has anyone contacted google support over this?

Not wrong, still occuring for me too.

Interesting that it still happens with GoogleDrive app, at least that rules out Rclone

Well technically rclone was still in the mix because I'm using a crypt remote - just pointing at a different location, but that seems exceedingly unlikely to be causing the issue.

This "endpoint" choice happens for every single request made by rclone? Because I saw it happen in the middle of watching a movie, streamed from Drive.

Rclone makes a request for a host.

The local OS decides where that goes by issuing a DNS name lookup.

Depending on the OS and how it's setup, it make get a new IP, same IP or use a cached value it already has or depending on what router / DNS you are set to, that can also return different things.

It's an OS/local setup flow and nothing directly related to rclone per se.

In my setup, I got one IP for the drive API:

felix@gemini:~$ host api.google.com
api.google.com is an alias for api.l.google.com.
api.l.google.com has address

Dropbox gives me one too.

felix@gemini:~$ host api.dropbox.com
api.dropbox.com is an alias for api-env.dropbox-dns.com.
api-env.dropbox-dns.com has address
api-env.dropbox-dns.com has IPv6 address 2620:100:6019:19::a27d:413

Using different DNS servers, you get different results "generally".

felix@gemini:~$ nslookup
> api.google.com

Non-authoritative answer:
api.google.com	canonical name = api.l.google.com.
Name:	api.l.google.com
> server
Default server:
> api.google.com

Non-authoritative answer:
api.google.com	canonical name = api.l.google.com.
Name:	api.l.google.com
> server
Default server:
> api.google.com

Non-authoritative answer:
api.google.com	canonical name = api.l.google.com.
Name:	api.l.google.com

Depending on your provider, you may or may not have good or bad peering to that IP and depending on load, it could also get worse. For bad peering, there isn't much to do other than trying to find an IP that works best for you.

But here is there a way to "lock" to a good peering? Because, as I stated previously, it happened to me randomly during a movie. So rclone was already active and downloading stuff from Drive. And all of a sudden it got capped to 18Mbps. Then after a bit of stopping, skpping ahead, skipping backward... it started back using my full bandwidth.

Not really as it's all dependent on your ISP and the route.

Sometimes, you can't fix it at all unfortunately as you can only determine the path so much. Some folks use VPNs to get better peering.

Check out:

What Is ISP Peering? Why Your High-Speed Internet Is Slow (makeuseof.com)

That seems to give a decent description.

1 Like