1

I'm new to WSL and trying to use rsync for snapshot backups. Everything seems to be working as intended... except that rsync refuses to copy some files, citing a permission error with send_files.

So I tried to change globally the permissions for all files and folders, to make them all readable. Again, failure with certain files. I then went to look at these specific directories and found this, for example:

m17awl@M17A:/mnt/d/My Documents/software projects/operative/LuceneIndexer_3/3.0.12/lib$ ls -lsa
total 48332
   0 drwxrwxrwx 1 m17awl m17awl     512 Jan 21  2020 .
   0 drwxrwxrwx 1 m17awl m17awl     512 Jan 21  2020 ..
  52 ---------- 1 m17awl m17awl   51141 Jan 23  2020 LuceneIndexer_3-3.0.12.jar
   4 ---------- 1 m17awl m17awl    3482 Jan 23  2020 animal-sniffer-annotations-1.14.jar
2020 ---------- 1 m17awl m17awl 2067867 Jan 23  2020 ant-1.9.13.jar

hmmm... no permissions. OK, I try to change these, seemingly successfully:

m17awl@M17A:/mnt/d/My Documents/software projects/operative/LuceneIndexer_3/3.0.12/lib$ sudo chmod -R +r .
[sudo] password for m17awl:
m17awl@M17A:/mnt/d/My Documents/software projects/operative/LuceneIndexer_3/3.0.12/lib$ ls -lsa
total 48332
   0 drwxrwxrwx 1 m17awl m17awl     512 Jan 21  2020 .
   0 drwxrwxrwx 1 m17awl m17awl     512 Jan 21  2020 ..
  52 -r-xr-xr-x 1 m17awl m17awl   51141 Jan 23  2020 LuceneIndexer_3-3.0.12.jar
   4 -r-xr-xr-x 1 m17awl m17awl    3482 Jan 23  2020 animal-sniffer-annotations-1.14.jar
2020 -r-xr-xr-x 1 m17awl m17awl 2067867 Jan 23  2020 ant-1.9.13.jar

I run rsync again... and get the same permission failures, including with these files in this particular directory:

m17awl@M17A:/mnt/d/My Documents$ rsync --progress --update --recursive --times --link-dest=/mnt/f/Backups/rsync/My\ Documents/snapshot2021-02-21T203900/ /mnt/d/My\ Documents/ /mnt/f/Backups/rsync/My\ Documents/snapshot2021-02-22T071700/
sending incremental file list
...
rsync: send_files failed to open "/mnt/d/My Documents/software projects/operative/LuceneIndexer_3/3.0.12/bin/LuceneIndexer_3": Permission denied (13)
rsync: send_files failed to open "/mnt/d/My Documents/software projects/operative/LuceneIndexer_3/3.0.12/lib/LuceneIndexer_3-3.0.12.jar": Permission denied (13)
rsync: send_files failed to open "/mnt/d/My Documents/software projects/operative/LuceneIndexer_3/3.0.12/lib/animal-sniffer-annotations-1.14.jar": Permission denied (13)
rsync: send_files failed to open "/mnt/d/My Documents/software projects/operative/LuceneIndexer_3/3.0.12/lib/ant-1.9.13.jar": Permission denied (13)

... and when I go back and look at the directory again I find the permissions on these files have been "destroyed" (i.e. again set to ----------).

Anyone got any idea what's going here... any solutions?

Incidentally, the source medium, where the problem seems to be happening, is an internal SSD, 250 GB, formatted NTFS. The destination medium (/mnt/f) is an external hard drive, spinning plates type, 750 GB, formatted NTFS.

mike rodent
  • 774

2 Answers2

1

While it's good to hear that you resolved the issue for this use case, I'd still recommend a slightly different solution.

In your /etc/wsl.conf, add the following:

[automount]
options  = "metadata,umask=22,fmask=11,uid=1000,gid=1000"

Of course, set the uid and gid to your user. Technically, the metadata, fmask, and umask options aren't even necessary with the uid/gid set. At least not for the rsync use-case. They are still nice-to-have in place, though.

See this Github issue/comment for more details. Summary is that "metadata" will allow WSL to store permissions for files created by WSL on the drvfs drive, but files created by Windows would still be assigned to root. As a result, if rsync includes these files, there would still be permissions issues. uid/gid, on the other hand, will assign WSL ownership of files to your user regardless of whether they are created in WSL or Windows.

The enabled and root options from your answer are already set to those values by default by WSL, so they really shouldn't be necessary at all.

NotTheDr01ds
  • 28,025
0

Thanks to Kamil Maciorowski's comment and link I did some experiments, which appear to have led to success:

1 - as per this answer, create (or modify if exists) a file /etc/wsl.conf:

[automount]
enabled  = true
root     = /mnt/
options  = "metadata,umask=22,fmask=11"

2 - reboot machine

3 - set your permissions as required, in my case read permissions for the source location

4 - rsync

NB some other answers with the above linked answer suggest that no /mnt/... locations (i.e. Windows 10 partitions) under WSL can be trusted to keep their permissions. SO FAR, in my case, this seems to be false. As mentioned, my source location is an internal SSD drive formatted NTFS, and it appears so far to be working OK.

mike rodent
  • 774