Mounted Google Drive loads files slowly, even from VFS cache

Help and Support
1

What is the problem you are having with rclone?

Files read from a mounted Google Drive shared drive are occasionally loaded slowly (more than 30 seconds to open). There seems to be no sensible pattern as to which files are slow to load. I have had this issue before and I still have the fixes from that attempt in action. I'm not sure what has changed to reintroduce the problem, other than perhaps a much larger number of files in the mount.

The app which is reading the files times out after 30 seconds, and generally after this point a new read operation for the same file completes instantly.

I don't believe this is an issue with Google Drive being slow, because all the files being loaded are in the VFS cache (this does make for a large VFS cache of over 15,000 files, although only about 130GB data).

I noticed when running with -vv that the cache stale poll was being run every minute, and because of the size of the VFS cache, firing out 15,000 vfs cache RemoveNotInUse log lines every minute. I tried increasing --vfs-cache-poll-interval to see if the cache stale procedure was holding up file IO, but no difference.

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

rclone v1.75.0
- os/version: Microsoft Windows 11 Pro 25H2 25H2 (64 bit)
- os/kernel: 10.0.26200.9168 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.26.5
- go/linking: static
- go/tags: cmount

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

Google Drive (shared drive)

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

rclone mount music: M: --volname "Music" --network-mode --temp-dir D:\ --cache-dir D:\ --vfs-cache-mode full --vfs-cache-max-age 2y --dir-cache-time 2y --vfs-refresh --vfs-cache-min-free-space 10Gi --config "C:\config\rclone.conf"

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[music]
type = drive
client_id = XXX
client_secret = XXX
scope = drive
service_account_file = C:/config/service-account.json
team_drive = XXX
root_folder_id =

A log from the command that you were trying to run with the -vv flag

The log is quite busy with other stuff going on (e.g. a simultaneous ongoing file read), so here are the excerpts I think are relevant by matching the rclone logs to the logs of the app loading the files.

  1. At the time the app first tries to open a file, rclone logs:
    2026/09/01 19:50:19 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Getattr: fh=0xFFFFFFFFFFFFFFFF
  2. 30 seconds later, when the app says the file load has timed out:
    2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Getattr: errc=0
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Getattr: errc=0
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: OpenEx: flags=0x0
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: OpenFile: flags=O_RDONLY, perm=-rwxrwxrwx
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Open: flags=O_RDONLY
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: newRWFileHandle: 
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >newRWFileHandle: err=<nil>
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Open: fd=App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3 (rw), err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >OpenFile: fd=App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3 (rw), err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >OpenEx: errc=0, fh=0x5
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=0, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=4096, off=0
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): openPending: 
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: vfs cache: checking remote fingerprint "219598,2026-08-24 19:05:01.816 +0000 UTC,c437c4f7161f39c215e206a3fbab5fbc" against cached fingerprint "219598,2026-08-24 19:05:01.816 +0000 UTC,c437c4f7161f39c215e206a3fbab5fbc"
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: vfs cache: truncate to size=219598 (not needed as size correct)
2026/09/01 19:50:50 DEBUG : App AudioStore: Added virtual directory entry vAddFile: "c516ef3fe1d04f47b1565786a8389333.mp3"
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >openPending: err=<nil>
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:0 Size:4096} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=4096, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=4096
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=219455, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=4096, off=219455
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:219455 Size:143} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=143, err=EOF
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=143
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=0, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=4096, off=0
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:0 Size:4096} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=4096, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=4096
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=4096, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=11904, off=4096
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:4096 Size:11904} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=11904, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=11904
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=0, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32768, off=0
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:0 Size:32768} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=32768, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=32768
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=32768, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32084, off=32768
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:32768 Size:32084} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=32084, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=32084
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=64852, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32560, off=64852
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:64852 Size:32560} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=32560, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=32560
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=97412, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32449, off=97412
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:97412 Size:32449} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=32449, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=32449
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=129861, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32765, off=129861
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:129861 Size:32765} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=32765, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=32765
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=162626, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32437, off=162626
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:162626 Size:32437} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=32437, err=<nil>
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=32437
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=195063, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32537, off=195063
2026/09/01 19:50:50 DEBUG : vfs cache: looking for range={Pos:195063 Size:24535} in [{Pos:0 Size:219598}] - present true
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=24535, err=EOF
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=24535
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: Read: ofst=219598, fh=0x5
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): _readAt: size=32768, off=219598
2026/09/01 19:50:50 DEBUG : App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3(0x252bf3a4be00): >_readAt: n=0, err=EOF
2026/09/01 19:50:50 DEBUG : /App AudioStore/c516ef3fe1d04f47b1565786a8389333.mp3: >Read: n=0
2

hi,

if you are using service_account_file, then remove client_id and client_secret
if you are using client_id and client_secret, then remove service_account_file

3

Done that now, thank you. Does having both set affect performance or is this a change to meet best practice?

4

well, it is best practice. the service file contains the client_id

now, you have a simplified setup, one small setup closer to a solution.

i do try some random testing.
for example, remove --volname "Music" --network-mode

fwiw, i have a summary of the rclone's two vfs caches

5

I've removed your suggested flags and will monitor to see if it makes any difference, thank you.

I'm intentionally using both caches quite heavily - the dir-cache is high since I was previously told that Google Drive is a polling remote so it tells you about changes to the directory structure anyway. vfs cache is high to try and make access to all files as fast as possible. The cloud mount in this case is less about storage space and more about sync.

6

which app? what other apps have you tested that have the same exact problem?
if you watch a video, does the exact same problem occur?

imo. the flags used in your command are pretty standard usage for gdrive.

7

I've been running without the --network-mode and so far, and I don't think I've a file outright fail to load, although there have been a couple of slow opens (20-30 sec).

The app is PlayIt Live, which uses the BASS audio engine for opening and playing files. I'm not sure what other app would be good to try - this one tends to have at least four files open at a time and is continually changing with four those are, and I wonder if that stress is part of where the issue is coming in? If you've got a suggestion of an app with a similar usage pattern to test with I can give it a shot.

8

you have to determine if the app is the problem.
you have to test using different apps.

9

Try one clean split test:

rclone cat remote:path/file --stats 1s >/dev/null

Run it twice on a file that the app takes 30 seconds to open, then open the same file through the mount. If rclone cat is quick and the mount is slow, the app is doing extra stat/list calls. Test a small directory too.

For the mount, a useful baseline is --vfs-cache-mode full --dir-cache-time 1h --poll-interval 1h --vfs-cache-poll-interval 5m. The cache poll interval only controls stale-file checks. It won’t fix an app that keeps walking a 15,000-file directory. The rclone mount -vv output during one slow open should show whether the wait is a Drive request or local cache work.

10

Thanks for this - part of the issue I'm having is that it's inconsistent about which files open slowly. I've just tried rclone cat and on a random file and it seemed quite slow, although I can't work out how to get the stats to appear properly in PowerShell. Do the stats go to stdout or stderr? The docs don't specify.

What wording in a -vv log would indicate it's reading from the cache vs Google Drive? Is there any clue in the log at the top of this thread?

11

have you tried that yet?

12

I have written a script which opens files in a similar pattern to the software using ffplay, but haven’t had a chance yet to run it on the server. Will do so and report back.

13

nice!

i was thinking of a simple test.
upload a video using the mount, then watch the video and see what happens.
seek to different sections of the video and see how the mount behaves.
just make sure you can direct play the video, no transcoding.

can you post the updated remote config using rclone config redacted
i would suggest testing with client id+secret and not use a service file.

14

stats go to stderr for me. in powershell try:

rclone cat remote:path/file --stats 1s *> cat-stats.txt

or

rclone cat remote:path/file --stats 1s 2>&1 | Tee-Object -FilePath cat-stats.txt | Out-Null

then open cat-stats.txt. redirecting only stdout hides the numbers.

in mount -vv look for lines like:
-vfs cache: open (cache hit / already cached)
-Downloading / HTTP GET when it actually hits drive

if cat itself is slow on that file then the object isnt warm in vfs yet or drive is throttling it. mount is just sitting on the same path.

15

Some updates from your advice above…

  • The config file is the same as original, minus the client_id and client_secret lines. I should also say I'm running a couple of different mounts with different remotes, but have tried cutting it back to just the one mount in the config and running to check as a minimal example and see the same issue.
  • I'm struggling to get rclone cat to print the stats usefully, every version of the command I've tried seems to get the stats data lost in the audio file also being printed to the console. Need to experiment a bit more.
  • I'm able to semi-reliably reproduce this issue by stopping the mount, starting it, and then trying to open a file.
  • Windows Explorer is really slow to list the contents of the directory. Once it has listed it though, it's pretty quick to open a file.
  • I went into VLC and used "Open Network Stream…" with a file path specified like file://[mount path]/[file] to try and open something without invoking Windows Explorer, which would happen with the "Open File…" option. This resulted in similar behaviour as described in the original post, with a ~15 second hang before the file opens and starts playing.

The rclone log output from the VLC test looks similar to the original above. As soon as I open the file I get this:

2026/10/04 20:22:29 DEBUG : /: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:29 DEBUG : /: >Getattr: errc=0
2026/10/04 20:22:29 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:29 DEBUG : /: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:29 DEBUG : /: >Getattr: errc=0
2026/10/04 20:22:29 DEBUG : /: Opendir:
2026/10/04 20:22:29 DEBUG : /: OpenFile: flags=O_RDONLY, perm=-rwxrwxrwx
2026/10/04 20:22:29 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFFF

Then nothing for 14 seconds, VLC hangs. Then the file appears in VLC and the rclone log says:

2026/10/04 20:22:43 DEBUG : /: >OpenFile: fd=/ (r), err=<nil>
2026/10/04 20:22:43 DEBUG : /: >Opendir: errc=0, fh=0x0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /autorun.inf: >Getattr: errc=-2
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /autorun.inf: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: OpenEx: flags=0x0
2026/10/04 20:22:43 DEBUG : /: Releasedir: fh=0x0
2026/10/04 20:22:43 DEBUG : /: >Releasedir: errc=0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: OpenFile: flags=O_RDONLY, perm=-rwxrwxrwx
2026/10/04 20:22:43 DEBUG : /autorun.inf: >Getattr: errc=-2
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: Open: flags=O_RDONLY
2026/10/04 20:22:43 DEBUG : /autorun.inf: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /Folder.jpg: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: newRWFileHandle:
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: >newRWFileHandle: err=<nil>
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: >Open: fd=01 5, 6, 7, 8.m4a (rw), err=<nil>
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >OpenFile: fd=01 5, 6, 7, 8.m4a (rw), err=<nil>
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >OpenEx: errc=0, fh=0x0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Read: ofst=0, fh=0x0
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c3e1c100): _readAt: size=65536, off=0
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c3e1c100): openPending:
2026/10/04 20:22:43 DEBUG : /autorun.inf: >Getattr: errc=-2
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: vfs cache: checking remote fingerprint "7206943,2023-02-06 22:16:53.834 +0000 UTC,00542a2b808795582e2e34e709fd25e9" against cached fingerprint "7206943,2023-02-06 22:16:53.834 +0000 UTC,00542a2b808795582e2e34e709fd25e9"
2026/10/04 20:22:43 DEBUG : /autorun.inf: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: vfs cache: truncate to size=7206943 (not needed as size correct)
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /Folder.jpg: >Getattr: errc=-2
2026/10/04 20:22:43 DEBUG : /: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /: Opendir:
2026/10/04 20:22:43 DEBUG : /: OpenFile: flags=O_RDONLY, perm=-rwxrwxrwx
2026/10/04 20:22:43 DEBUG : /: >OpenFile: fd=/ (r), err=<nil>
2026/10/04 20:22:43 DEBUG : /: >Opendir: errc=0, fh=0x1
2026/10/04 20:22:43 DEBUG : Added virtual directory entry vAddFile: "01 5, 6, 7, 8.m4a"
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c3e1c100): >openPending: err=<nil>
2026/10/04 20:22:43 DEBUG : vfs cache: looking for range={Pos:0 Size:65536} in [{Pos:0 Size:7206943}] - present true
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /autorun.inf: >Getattr: errc=-2
2026/10/04 20:22:43 DEBUG : /Folder.jpg: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c3e1c100): >_readAt: n=65536, err=<nil>
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Read: n=65536
2026/10/04 20:22:43 DEBUG : /autorun.inf: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Read: ofst=7143424, fh=0x0
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c3e1c100): _readAt: size=65536, off=7143424
2026/10/04 20:22:43 DEBUG : vfs cache: looking for range={Pos:7143424 Size:63519} in [{Pos:0 Size:7206943}] - present true
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c3e1c100): >_readAt: n=63519, err=EOF
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Read: n=63519
2026/10/04 20:22:43 DEBUG : /Folder.jpg: >Getattr: errc=-2
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Getattr: errc=0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: OpenEx: flags=0x0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: OpenFile: flags=O_RDONLY, perm=-rwxrwxrwx
2026/10/04 20:22:43 DEBUG : /: Releasedir: fh=0x1
2026/10/04 20:22:43 DEBUG : /: >Releasedir: errc=0
2026/10/04 20:22:43 DEBUG : /Folder.png: Getattr: fh=0xFFFFFFFFFFFFFFFF
2026/10/04 20:22:43 DEBUG : /autorun.inf: >Getattr: errc=-2
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: Open: flags=O_RDONLY
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: newRWFileHandle:
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: >newRWFileHandle: err=<nil>
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a: >Open: fd=01 5, 6, 7, 8.m4a (rw), err=<nil>
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >OpenFile: fd=01 5, 6, 7, 8.m4a (rw), err=<nil>
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >OpenEx: errc=0, fh=0x1
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Flush: fh=0x1
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c5804b00): RWFileHandle.Flush
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Flush: errc=0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Release: fh=0x1
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c5804b00): RWFileHandle.Release
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c5804b00): close:
2026/10/04 20:22:43 DEBUG : 01 5, 6, 7, 8.m4a(0x1e03c5804b00): >close: err=<nil>
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: >Release: errc=0
2026/10/04 20:22:43 DEBUG : /01 5, 6, 7, 8.m4a: Getattr: fh=0xFFFFFFFFFFFFFFF

I've put the next 1400 log lines in a gist as it reads more of the audio file til I stop playback. It looks like it was a vfs cache hit?

After that, it prints a Reset virtual modtime line for every file in the same directory (6378 lines).

Could it be that there's just too many files in each folder for rclone/Windows to work with efficiently?

16

imho, your original remote was not setup correctly.
so now, you are using service_account_file or what?

mulitple apps have the same issue. i am wondering if it is an issue specifc to your machine.
i have been running, rclone mount for 8+ years, on windows, linux, termux, etc.
never experienced your issue.

:might try the following:

  • remove --temp-dir, not sure the point of that?
  • test rclone serve webdav and play a video using kodi.
  • test another provider besides gdrive.
  • test without using no vfs file cache, --vfs-cache-mode=off

what version of winfsp is being used?

fwiw. i always mount to a folder, never to a drive letter
rclone mount remote: b:\rclone\mount\remote

17

Have just tested using rclone mount music: M: --vfs-cache-mode off --config [path to config] -vv and see the same behaviour: about 15 seconds of hanging, but now VLC shows a loading state after that before beginning playback (I guess to allow for the download to happen since there's no cache). Same behaviour adding --network-mode, and mounting to a path instead of a drive letter.

I don't have Kodi installed right now, I can try with it soon. I should say as well, this is all audio files, no video. As an immediate test I just tried rclone serve http. When visiting the listing in the web browser for the first time, there was the same approx 15 second delay in the first page load of the directory listing. There were no logs printed between the HTTP server starting and INFO: Serving directory.

WinFsp 2025 appears to be v2.1.25156, which seems to be the latest non-beta.

I've seen this issue across two different PCs, as I recently replaced this computer and have seen this on both the old and new one. Admittedly both of them have been running the same software (albeit possibly slightly different versions) in the same configuration.

I don't see this issue with other Google Drive mounts on this PC, although they have (many) fewer files per directory.

I will try to test with another remote, will need to find another where I have enough capacity to upload the files and make a fair comparison.

Config section for this remote is:

[music]
type = drive
scope = drive
service_account_file = C:/config/service-account.json
team_drive = XXX
root_folder_id =

So yes, now only using service account.

18

I have just tried with client_id and client_secret instead of a service account, and it shows the same behaviour.

I have also tried using the client_id and client_secret on macOS, using rclone mount music: [path] --vfs-cache-mode off -vv and opening a file as a network stream in VLC, and it seems to work better and start loading the file quicker without hanging. I've tested a lot more on Windows though.