rsync error with Windows 1803

[Mornon]

This bug-tracker is monitored by developers and other technical types. We like detail! So please use this form and tell us, concisely but precisely, what's up. Please fill out ALL THE FIELDS!

If you have a feature request, please post to the UserVoice.

If this is a console issue (a problem with layout, rendering, colors, etc.), please post to the console issue tracker.

Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues. Instead, send dumps/traces to [email protected], referencing the GitHub bug number. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".

• Your Windows build number: (Type ver at a Windows Command Prompt) Microsoft Windows [Version 10.0.16299.431]

• What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

When I use rsync with a USB drive, I get errors:

rsync: chgrp "/mnt/f/Gamification/TechLand/TPS/Illuminotecnica/Immagini/03/A/Stanza.dwg" failed: Operation not permitted (1)
rsync: mkstemp "/mnt/f/Gamification/TechLand/TPS/Illuminotecnica/Immagini/03/A/.Stanza.dwg.vU7MSj" failed: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]

This started happening after upgrading from 1709 16299.431 to 1803 17134.48, and fixed itself after a rollback. This is the code, which worked in 1709:

cd /mnt/d/Mauro/Documenti/Insegnamento/
rsync -Rauv --del --chown Mauro --chmod=ugo=rwX \
  'Gamification' \
  /mnt/f/ \
  >/mnt/c/Users/Mauro/Desktop/lista.txt \
  2>/mnt/c/Users/Mauro/Desktop/errori.txt

It still works syncing from internal hard drive to internal hard drive, and from internal to external hard drive. I tried formatting the USB drive, reformatting it as NTFS, recreating permissions, formatting again as FAT32; I also tried to remove entirely the folders and run the script again, to no avail.

• What's wrong / what should be happening instead:

The folders should sync.

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here)

See our contributing instructions for assistance.

[WSLUser]

I'm going to cite #2770 for this one.

[Mornon]

Just to be sure I understood, I'm just beginning to learn this stuff: I should try mounting the drive with this, after unmounting it?

sudo mount -t drvfs F: /mnt/f -o metadata

(Will try as soon as I reupgrade my PC.)

[Mornon]

By the way, I also tried with

--no-owner --no-group

but got this error:

failed to set times on "/mnt/f/2017-2018": Operation not permitted (1)

(Not sure if the sync went through, will check as soon as possible.)

[WSLUser]

Yes you should do that. Or you can just use wsl.conf to set the metadata option. In your case, you may also want to use fstab to mount your drives vice the auto drvfs. I would try either way and see if it helps. Also try running an elevated and non-elevated session to ensure Windows permissions aren't also a blocker. Oh and I should say that it will require you to upgrade to build 17134. The fix I'm describing doesn't exist in 16299.

Edit: Also possibly related: #1869

[Mornon]

Will try that as soon as I will reupgrade do 17134, thanks. Just not sure what do you mean by "to mount your drives vice the auto drvfs"?

[WSLUser]

WSL automounts your drives such as /mnt/c via DrvFS. The difference with fstab is that it's explicitly configured to mount via fstab, you're still using DrvFS for interop. I suggest reading up on fstab as it's how Linux mounts various types of drives.

[benhillis]

@DarthSpock - The benefit of adding your mounts to /etc/fstab is you can specify the specific drives you want to mount. Automount is performed after processing /etc/fstab and will skip drives that are already mounted.

[WSLUser]

Yes but he mentioned he's new to Linux so just recommending he does some research so he can understand more about Linux.

[Mornon]

I tried mounting with

sudo mount -t drvfs F: /mnt/f -o metadata

but I still got the same errors, almost a thousand chgrp and one mkstemp.

[Mornon]

Now I'm on 1803 17134.1, and I still got the same errors, also using --no-owner and -o metadata.

rsync: mkstemp "/mnt/f/2017-2018/.5A.xlsx.hOeFu7" failed: Operation not permitted (1)

[Mornon]

I was able to solve using this option: #3187 (comment)

[Mornon]

Any idea about how to add uid=1000,gid=1000 as default using wsl.conf? I tried editing it and adding

[automount] options = "uid01000,gid=1000"

but it doesn't work; using mount -l I can't see the external drive listed, so maybe it's that?

[KnuX]

Hi all,

Using the windows insider build 2004 (19033.1), I still have errors using rsync to an external USB drive used for backups.

$ rsync -vrltxz --rsync-path="wsl rsync" --delete --no-p --progress /mnt/d/filename [email protected]:/mnt/e/
...
rsync: failed to set times on "/mnt/e/filename.0APmfD": Operation not permitted (1)

mount confirms that my device is mounted with uid=1000,gid=1000 as suggested in this issue:

$ mount
...
D:\ on /mnt/d type 9p (rw,noatime,dirsync,aname=drvfs;path=D:;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=8,wfd=8)
e: on /mnt/e type 9p (rw,relatime,dirsync,aname=drvfs;path=e:;uid=1000;gid=1000;symlinkroot=/mnt/,mmap,access=client,msize=65536,trans=fd,rfd=3,wfd=3)

It occurs only with newer files uploaded by rsync. Each time I run rsync the same files will be uploaded this the timestamp isn't the same as the source file...

My E: drive is bitlocked, I manually mount it after having unlocked it. I have not this issue with my D: fixed drive. I tried naively to remount E: with the "noatime" option such as D: but the issue is still here (I don't know what are rfd/wdf options, their values don't change with remount).

[therealkenc]

I was able to solve using this option: #3187 (comment)

/dupe #3187 ➡️ #2770

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists in this repository. This specific instance is being closed in favor of tracking the concern over on the referenced thread.

Thanks for your report!