Problems copying .docx files to Sharepoint

Help and Support
1

STOP and READ USE THIS TEMPLATE NO EXCEPTIONS - By not using this, you waste your time, our time and really hate puppies.

I've run into an odd problem when copying Microsoft document files to sharepoint, the copy fails because the copied filesize doesn't match the source.
It seems to be related to the filename extension so .txt or .pdf files copy fine.  The problem only occures with .docx or .xlsx if I rename the destination file to .doc (or .xls) the copy works perfectly.  If I use --ignore-size --ignore-checksum the copy succeeds but the destination file is bigger than the source and analysing it using 7z to open the .docx shows that an extra folder has been added called [trash].  Not sure where to go with this...

What is the problem you are having with rclone?

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

rclone v1.74.3
- os/version: Microsoft Windows 11 Pro 24H2 24H2 (64 bit)
- os/kernel: 10.0.26100.8655 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.26.4
- go/linking: static
- go/tags: cmount

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

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

Microsoft Sharepoint 

rclone copyto "D:\sharepoint backup\test.docx" "Planetcs:test.docx"

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

[Planetcs]
type = onedrive
token = XXX
drive_id = XXX
drive_type = documentLibrary
[Shared]
type = onedrive
token = XXX
drive_id = XXX
drive_type = documentLibrary
### Double check the config for sensitive info before posting publicly

Paste config here

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

clone copyto "D:\sharepoint backup\test.xlsx" "Planetcs:test.xlsx" -vv

2026/06/13 16:51:46 ERROR : Attempt 1/3 failed with 1 errors and: corrupted on transfer: sizes differ src(Local file system at //?/D:/sharepoint backup) 8488 vs dst(OneDrive root '') 15508
2026/06/13 16:51:47 DEBUG : test.xlsx: Need to transfer - File not found at Destination
2026/06/13 16:51:47 DEBUG : test.xlsx: Starting multipart upload
2026/06/13 16:51:47 DEBUG : test.xlsx: Uploading segment 0/8488 size 8488
2026/06/13 16:51:48 DEBUG : test.xlsx: size = 8488 (Local file system at //?/D:/sharepoint backup)
2026/06/13 16:51:48 DEBUG : test.xlsx: size = 15511 (OneDrive root '')
2026/06/13 16:51:48 ERROR : test.xlsx: corrupted on transfer: sizes differ src(Local file system at //?/D:/sharepoint backup) 8488 vs dst(OneDrive root '') 15511
2026/06/13 16:51:48 INFO  : test.xlsx: Removing failed copy
2

welcome to the forum,

perhaps this is the issue?
https://rclone.org/onedrive/#unexpected-file-size-hash-differences-on-sharepoint

3

Many thanks for getting in touch, really appreciate that. That's all very useful information, I think the thing I find most odd is that it's all down to the filename extension, almost like graph is recognising an office document and mucking about with it. For example rclone copyto "D:\sharepoint backup\test.xlsx" "Planetcs:test.xlsx" fails but rclone copyto "D:\sharepoint backup\test.xlsx" "Planetcs:test.xls" works without error. Using --ignore-size --ignore-checksum does allow the copy to succeed but the files have been changed in the process which isn't good. Interestingly the .docx has to be a real Office file, If I create a .txt file and rename it to .docx the copy proceeds without error.

4

welcome

that is exactly the issue, thus the need for --ignore-size --ignore-checksum

5

For backup use I would be careful with --ignore-size/--ignore-checksum here. It makes the transfer finish, but it also hides exactly the case you noticed: SharePoint/Graph has changed the Office file after upload. If keeping the original bytes matters, I would either store those Office files inside a zip/crypt container, or upload with a neutral extension/name and only restore the real name after download if needed. A quick test is to copy one file up, copy it back to a new local folder, and compare the hashes with the original.

6

Yes, I totally agree, I'm not comfortable using --ignore-size/--ignore-checksum it does 'fix' the problem but could allow real corruption to go unchecked. Unpacking the .docx file I can see that the copied version has gained a [trash] folder containing a single 3k file called 0000.dat also the customXml folder gets slightly changed, it would be great if you could just turn this 'feature' off...

7

not sure your exact setup but looks like you have a onedrive account.

so, for backups, create another onedrive remote for that same account and use that.
onedrive will not muck up the file, so rclone can verify the file transfer using checksums and size.

rclone config redacted onedriveyoyo:
[onedriveyoyo]
type = onedrive
client_id = XXX
client_secret = XXX
token = XXX
drive_id = XXX
drive_type = personal

rclone copy d:\data\file.docx onedriveyoyo:backup -vv
DEBUG : rclone: Version "v1.74.2" starting with parameters ["rclone" "copy" "d:\\data\\file.docx" "onedriveyoyo:backup" "-vv"]
DEBUG : Creating backend with remote "d:\\data\\file.docx"
DEBUG : Using config file from "d:\\data\\rclone\\rclone.conf"
DEBUG : fs cache: renaming child cache item "d:\\data\\file.docx" to be canonical for parent "//?/d:/data"
DEBUG : Creating backend with remote "onedriveyoyo:backup"
DEBUG : file.docx: Need to transfer - File not found at Destination
DEBUG : file.docx: Starting multipart upload
DEBUG : file.docx: Uploading segment 0/13433 size 13433
DEBUG : file.docx: size = 13433 OK
DEBUG : file.docx: quickxor = 4b145d84ce71d57b0874b73f64c062ac58aaac30 OK
INFO  : file.docx: Copied (new)
8

Thanks for sharing this discussion. Problems copying DOCX files to SharePoint can be tricky because the issue isn't always the file itself. It could be related to SharePoint restrictions, filename or path length limits, permissions, or even how the transfer tool handles metadata during the upload. Verifying whether other file types upload successfully is often a good way to narrow down the root cause.

I have a question for anyone who has dealt with this before: Did the issue affect only specific DOCX files, or was it happening with every Word document? Also, were you able to resolve it by changing any SharePoint settings or rclone options, or did the files themselves require modification before they could be copied successfully?

9

welcome to the forum,

during upload, microsoft modifies office files. that would apply to every document.
that is why rclone cannot verify file transfers using size and checksum.

this is a known issue for many years in the forum, affecting many users.
if there is a solution, it would have been mentioned in the forum and the rclone documentation.

not sure about your setup and goals but one potential workaround, as i mentioned up above.

  • copy files to onedrive, not sharepoint
  • run something like rclone mount onedrive: x: pointing to onedrive
  • now you can open, edit, save, create new office documents and microsoft will not muck it up.