I'm using rclone in combination with gsuite running on a RPi3 (Raspbian Buster) and an Odroid N2 (Debian Buster). The Odroid I use on a daily basis whereas the RPi3 was only used for testing purposes.
The rclone remotes are shared in my network to a windows pc using smb.
What I am experiencing is the following:
-When I am using rsync to sync files from a harddrive which is connected to the Odroid N2 I get the full and constant speed of my internet connection (100/40mbit).
-When I am using rsync to sync files from a remote to a connected harddrive I also get full speed.
-When I try to copy data from a remote which is served via smb to my windows pc, the speed isn't constant at all and differs between 0 to 10mbit. So transferring files like that takes like forever.
Using rclone for windows I can transfer files at full speed. So I was wondering, what might cause this issue, as both devices (Odroid/RPi3) are capable of serving the remotes at full speed of the internet connection.
I am using these mount parameters:
The first thing I would do is confirm that you can download to the Pi locally with the same remote and get the right speed (test on larger files if possible). If we can eliminate that portion of the system then it cuts the problem in half at least.
I'd also take a glance at your system resources while you do this just to sure we can eliminate any issues of limited hardware. Rclone runs pretty light, but it does need some CPU of course, especially if decrypting on the fly. I don't have a lot of hands on experience with the Pi to have a good estimate of how it fares in this context.
Just came to the forum to post exactly the same issue.
When using SMB in Windows to mount a OneDrive encrypted remote on a RPi4, downloading even small files (<60MB) takes forever. It's unusable. Uploads using the SMB mount do work fine.
Downloading files directly on the RPi4 works fine, even streaming 4K movies. I have 200/100mbps fiber, GbE network.
I'm using only the following mount options:
--buffer-size 128M \
Hmm, it does initially sound like there may be some issue between SMB and rclone then - but if so I am sure this will be a known one considering how popular SMB is.
Unfortunately I haven't had much need to use SMB shares for rclone yet, so I'm not up to speed on the spesific issues you might face. Thankfully there are lots of Linux users here, so I expect someone has an idea on what where the problem might lie. @Animosity022 do you know something about this?
What clone version you both using?
(run rclone version to check)
Many Linux repositories are notorious for having ancient rclone versions on them, so very many problems on Linux come down to people using very old versions. (latest stable is 1.5.1)
On my odroid, I am running rclone 1.51.0.
Wasn't sure of it was really the latest but rclone version said me that it is.
As I wrote, downloading files from an encrypted remote on a harddrive directly connected to the odroid and using rsync, I get full speeds.
Should I also try that without using rsync but "cp" and writing to the eMMC instead of the connected harddrive?
This evening after work (no home office for me) I can take a look at the ressouces while transfering a file via "top".
While transferring a file from a remote to my windows machine via smb, "top" shows me, that rclone is at an average of 10-15% cpu usage. sometimes it gets up to 20% and tops at about 30% for short moments. Memory usage is at about 10-13%.
So it seems like rclone is not too demanding on the odroid.
But that would have been a surprise for me, as downloading files to a locally attached harddrive runs even at full speed and constant.
Also on v1.51.0
htop reports about 20% cpu usage. I tried NFSv3 (because why not), and it's exactly the same.
Here's a debug log: rclone.log (289.9 KB) I started an encrypted gdrive remote, tried to copy a file called Documentos.rar using SMB in Windows, got ~350KB/s and cancelled the file transfer.
There are quite a few in-sequence read errors in the log which makes me think it might be a problem we've already identified
Can you try the latest beta
First try it with the
If that is OK then try it with
---vfs-read-wait 50ms instead and see how that is
I'm still deciding on what patch I should be applying so more data would be very helpful!
So the latest beta would be 220.127.116.11?
Will give that a try later.
Unfortunely, it still behaves the same way, no improvement at all...
rclone v1.51.0-129-gd9c8c47e-beta - log: rclone_async-read.log (479.8 KB)
Three tries to copy the same file: with default mount options, with --async-read=false and with both --async-read=false & --vfs-read-wait 50ms.)
There aren't any problems I can see in the log.
I guess this must be caused by the FUSE file system which has to loop in and out of the kernel to satisfy requests....
It might be worth trying to tweak the buffer size parameters on the cifs/samba mount
rsize I think.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.