Files missing when moving folders inside rclone mount on Windows

Hi everyone,

I’m facing a strange and reproducible issue with rclone mount on Windows when moving folders inside a mounted remote (OneDrive Bussiness).

When I move a folder, not all files inside it are actually moved
rclone move works perfectly; the issue is only with the Windows mount.

What happens

Example:

  • I downloaded a TV series with 26 episodes.

  • When I move the folder containing those 26 files to another directory inside the same rclone mount, only 13 files are moved.

rclone mount:

rclone.exe mount ^
--cache-dir C:\rclone\Cache ^
--vfs-cache-mode full ^
--bind 0.0.0.0 ^
--buffer-size 32M ^
--checkers 3 ^
--tpslimit 3 ^
--transfers 3 ^
--bwlimit-file 40M:40M ^
--low-level-retries 1 ^
--onedrive-no-versions ^
--onedrive-hash-type none ^
--onedrive-chunk-size 250M ^
--onedrive-delta ^
--onedrive-hard-delete ^
--dir-cache-time 9999h ^
--vfs-cache-max-age 9999h ^
--vfs-read-chunk-size 256M ^
--poll-interval 1m ^
--user-agent "ISV|rclone.org|rclone/v1.73.0" ^
--vfs-cache-min-free-space 40G ^
--vfs-cache-max-size 100G ^
--log-level INFO --log-file="C:\rclone\rcloneplexlog.txt" ^
--no-console ^
--network-mode ^
--rc ^
--volname "Medias" "Medias:" M:

rclone config

[Union]
type = union
upstreams = OneDrive01: OneDrive02: OneDrive03: OneDrive04: OneDrive05:
action_policy = mfs
create_policy = mfs

[Medias]
type = crypt
remote = Union:
password = *********
filename_encoding = base32768

[OneDrive01]
type = onedrive
tenant = ****
drive_type = business
server_side_across_configs = true
no_versions = true
hard_delete = true
av_override = true
delta = true
token = ***
drive_id = ***

I’ve had this same issue before, and at that time changing the VFS cache mode from full to writes solved it.
However, now the problem happens regardless of the cache mode — I see the same behavior with both full and writes.

Still missing a log file to actually debug the problem.

https://gist.githubusercontent.com/pertile153/2cc80e79cc744a2fd8350a3d5a1c2ebb/raw/7e70f08b0bc65141bc0a2f916a98c000e631c86e/rclone.debug

My mount config:

rclone.exe mount ^
--cache-dir C:\rclone\Cache ^
--vfs-cache-mode full ^
--bind 0.0.0.0 ^
--buffer-size 32M ^
--checkers 2 ^
--tpslimit 2 ^
--transfers 2 ^
--tpslimit-burst 2 ^
--bwlimit-file 40M:40M ^
--low-level-retries 1 ^
--onedrive-no-versions ^
--onedrive-hash-type none ^
--onedrive-chunk-size 250M ^
--onedrive-delta ^
--onedrive-hard-delete ^
--vfs-read-chunk-size 256M ^
--vfs-cache-max-age 24h ^
--vfs-read-ahead 128M ^
--vfs-fast-fingerprint ^
--poll-interval 1m ^
--user-agent "ISV|rclone.org|rclone/v1.73.0" ^
--vfs-cache-min-free-space 40G ^
--vfs-cache-max-size 100G ^
--log-level DEBUG --log-file="C:\rclone\rcloneplexlog.txt" ^
--no-console ^
--network-mode ^
--rc ^
--volname "Medias" "Medias:" M:

What I did was use Windows Explorer to cut (Ctrl+X) the folder /Downloads/Series/Steal and paste it one level up, resulting in /Downloads/Steal.
With this, the Steal folder was moved, the Season 01 subfolder inside it was also moved, but only 4 out of the 6 files inside the Season 01 folder were transferred.

In Windows Explorer, the folder /Downloads/Series/Steal disappears and does not show up again unless I unmount and mount OneDrive again.
However, using the rclone ls / rclone lsd commands, I can still see the folder in the original location with the files that were not moved.

Even when using a very simple mount configuration (tested with both --vfs-cache-mode full and --vfs-cache-mode writes):

rclone.exe mount ^
--cache-dir C:\rclone\Cache ^
--vfs-cache-mode writes ^
--user-agent "ISV|rclone.org|rclone/v1.73.0" ^
--log-level INFO --log-file="C:\rclone\rcloneplexlog.txt" ^
--no-console ^
--network-mode ^
--rc ^
--volname "Medias" "Medias:" M:

I still experience the same issue.

It’s also worth mentioning that I have already tried reinstalling WinFsp, disabling --network-mode, and changing the drive letter, but none of these made any difference.

In that log file, I’m not seeing any files written or touched.

You’d normally see something like this if you are moving files:

2026/02/05 07:28:16 DEBUG : 1/Testfile.txt: >Attr: a=valid=1s ino=0 size=20 mode=-rw-r--r--, err=
2026/02/05 07:28:16 DEBUG : /: Lookup: name="2"
2026/02/05 07:28:16 DEBUG : /: >Lookup: node=2/, err=
2026/02/05 07:28:16 DEBUG : 2/: Attr:
2026/02/05 07:28:16 DEBUG : 2/: >Attr: attr=valid=1s ino=0 size=0 mode=drwxr-xr-x, err=
2026/02/05 07:28:16 DEBUG : 2/: Lookup: name="Testfile.txt"
2026/02/05 07:28:16 DEBUG : 2/: >Lookup: node=, err=no such file or directory
2026/02/05 07:28:16 DEBUG : 2/: Lookup: name="Testfile.txt"
2026/02/05 07:28:16 DEBUG : 2/: >Lookup: node=, err=no such file or directory
2026/02/05 07:28:16 DEBUG : 2/: Lookup: name="Testfile.txt"
2026/02/05 07:28:16 DEBUG : 2/: >Lookup: node=, err=no such file or directory
2026/02/05 07:28:16 DEBUG : 1/: Rename: oldName="Testfile.txt", newName="Testfile.txt", newDir=2/
2026/02/05 07:28:18 INFO : 1/Testfile.txt: Moved (server-side) to: 2/Testfile.txt
2026/02/05 07:28:18 DEBUG : 2/Testfile.txt: Updating file with 2/Testfile.txt 0xc000ad8840
2026/02/05 07:28:18 DEBUG : 1: Added virtual directory entry vDel: "Testfile.txt"
2026/02/05 07:28:18 DEBUG : 2: Added virtual directory entry vAddFile: "Testfile.txt"
2026/02/05 07:28:18 DEBUG : 1/: >Rename: err=
2026/02/05 07:28:18 DEBUG : 2/: Invalidating "Testfile.txt"

I did some more testing and noticed that when I move the folder that contains the files, the log never mentions the files themselves, only the directories — even though part of the files are actually moved.

I’m thinking about this and I’m not entirely sure, but it could be that instead of moving all the files, it is only changing the directory “link” so it doesn’t have to move every file. Since the structure is the same, it just places the folder in a different location.

One test I did (unfortunately I don’t have the log right now) was the following: if I move a folder to another location where that same folder already exists — even if it contains only a single file — it then does move the files one by one.

This made me think that when a folder is moved to a new location, files may not be moved individually. And since I’m using a union with 5 OneDrive remotes, I noticed that the parts that get moved are always the same. For example, if a series has 6 episodes and I move it, it either moves episodes 1–2 or episodes 3–6, but it never interleaves or mixes them — it’s always one group or the other.

Could this be because the files are split across different upstreams, and when the directory is renamed, it only renames the directory on one drive, where only part of the files exist?

Any items should be in the logs as even if you have a union, it would be logging files moving around.

Perhaps try it without the union and see the logs for that.

I tested on a single onedrive remote.

I was able to confirm that part of the files that get moved are located on one OneDrive, while the files that remain behind are located on another OneDrive.
So there is definitely an issue related to this behavior. When all the files are located on the same OneDrive, the move works normally.

This confirms that the problem is related to my union remote. If the files share the same folder structure but are spread across different upstreams (even under the same tenant), when I move the folder through Windows Explorer it only reorganizes the files from a single drive.

After unmounting and mounting the remote again (or checking via terminal with rclone ls, rclone move, etc.), the files that were moved and the files that remained both become visible again, and then I can move the remaining files.

Is there any solution for this scenario — where a folder contains files across multiple upstreams and I want to move all of them using Windows Explorer?

Another question: is there a way to prevent files from being placed across different upstreams?
This is my current union configuration:

[Union]
type = union
upstreams = OneDrive01: OneDrive02: OneDrive03: OneDrive04: OneDrive05:
action_policy = mfs
create_policy = mfs

Any advice would be greatly appreciated.