mv: setting attribute 'system.wsl_case_sensitive' for 'system.wsl_case_sensitive': Permission denied

[clouds56]

• Your Windows build number: Microsoft Windows [Version 10.0.18865.1000]

• What you're doing and what's happening:
  run things like mv /mnt/d/test /data (both folder are ntfs volume)

$ mount
...
D:\Data on /data type drvfs (rw,noatime,uid=1000,gid=1000,umask=22,fmask=111,metadata,case=off)
D:\ on /mnt/d type drvfs (rw,noatime,uid=1000,gid=1000,umask=22,fmask=11,metadata,case=off)
...
$ cat /etc/fstab
D:\Data  /data   drvfs   rw,noatime,uid=1000,gid=1000,umask=22,fmask=111,metadata 0       0
$ cat /etc/wsl.conf
[automount]
options = "metadata,umask=22,fmask=11"

update: I've tried mounting /data add the option metadata, issue still exists

• What's wrong / what should be happening instead:
  my console shows lots of error message (seems per folder)

mv: setting attribute 'system.wsl_case_sensitive' for 'system.wsl_case_sensitive': Permission denied

• Strace of the failing command: full log here: strace-mv.log.

utimensat(4, NULL, [{tv_sec=1554905721, tv_nsec=435534100} /* 2019-04-10T22:15:21.435534100+0800 */, {tv_sec=1554905721, tv_nsec=435534100} /* 2019-04-10T22:15:21.435534100+0800 */], 0) = 0
flistxattr(3, NULL, 0)                  = 0
flistxattr(3, 0x7fffd200ce40, 0)        = 0
fgetxattr(3, "system.posix_acl_access", 0x7fffd200cd30, 132) = -1 EOPNOTSUPP (Operation not supported)
fsetxattr(4, "system.posix_acl_access", "\2\0\0\0\1\0\6\0\377\377\377\377\4\0\4\0\377\377\377\377 \0\4\0\377\377\377\377", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
fchmod(4, 0100644)                      = 0
close(4)                                = 0
close(3)                                = 0
munmap(0x7f6ef2350000, 139264)          = 0
utimensat(AT_FDCWD, "./test", [{tv_sec=1554905721, tv_nsec=435534100} /* 2019-04-10T22:15:21.435534100+0800 */, {tv_sec=1554905721, tv_nsec=435534100} /* 2019-04-10T22:15:21.435534100+0800 */], 0) = 0
lchown("./test", 1000, 1000)            = 0
llistxattr("/mnt/d/test", NULL, 0)      = 26
llistxattr("/mnt/d/test", "system.wsl_case_sensitive\0", 26) = 26
openat(AT_FDCWD, "/usr/etc/xattr.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
lgetxattr("/mnt/d/test", "system.wsl_case_sensitive", NULL, 0) = 1
lgetxattr("/mnt/d/test", "system.wsl_case_sensitive", "0", 1) = 1
lsetxattr("./test", "system.wsl_case_sensitive", "0", 1, 0) = -1 EACCES (Permission denied)
write(2, "mv: ", 4mv: )                     = 4
write(2, "setting attribute 'system.wsl_ca"..., 77setting attribute 'system.wsl_case_sensitive' for 'system.wsl_case_sensitive') = 77
write(2, ": Permission denied", 19: Permission denied)     = 19
write(2, "\n", 1
)                       = 1

[therealkenc]

mv /mnt/d/test /data

Likely you've cursed your /mnt/d/test at some point by mounting it with case=dir, and now it is unfortunately cursed permanently even though it is now mounted with case=off. SOP is to delete /mnt/d/test and start over with case=off. Work around if you value the contents of ./temp might be cp -r ./test /data, which is really what you are doing with that mv. cp --preserve=all ./temp /data will fail for the same reason.

[clouds56]

No, I'm creating /mnt/d/test just a few seconds before mv in WSL.

$ cd /mnt/d
$ mkdir test
$ echo hello > test/world
$ cd /data
$ mv /mnt/d/test .

The 2 volume are both mounted with case=off during the whole operation (as shown in mount)

[clouds56]

Thanks for kind help!

The repro steps is exactly described in #3967 (comment).
I'm not mount volumes myself, instead /etc/wsl.conf and /etc/fstab do auto mount for me. (the parameter of mount could be see in original post)

[therealkenc]

Apologies - I deleted previous post because I'm trying to ascertain how to reproduce your setup. [...time passes...] Nah can't do it. D:\Data (for me, C:\Data) isn't making sense as a mount source. If you have some CLI reproduction steps that can be cut and paste (they'll have one or more sudo mount(8) and a sudo mkdir /data) I'll give it a go.

But either way, the net out is almost certainly going to be "use cp -r" as a work-around. Whatever the repro, mv(1) is trying to set extended attributes on a path that doesn't (and n.b. shouldn't) have case=dir on. That's a bug as far as it goes; I just can't reproduce it. [ed... got a repro give me a sec...]

[therealkenc]

$ cat /proc/version
Linux version 4.4.0-18875-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #2582 Microsoft Fri Apr 05 15:18:00 PST 2019
$ lsb_release -d
Description:    Ubuntu 18.04.2 LTS
$ mv --version | grep mv
mv (GNU coreutils) 8.28
$ sudo umount /mnt/c
$ sudo mount -t drvfs C:\\ /mnt/c -o metadata
$ sudo mkdir -p /tmp/mnt && sudo mount -t drvfs C:\\ /tmp/mnt -o metadata
$ cd /tmp/mnt/Data
$ mkdir ./foo && mkdir ./bar
$ mv ./foo /mnt/c/Data/bar
mv: setting attribute 'system.wsl_case_sensitive' for 'system.wsl_case_sensitive': Permission denied

For me, at least at first glance, ./foo did indeed move into /mnt/c/Data/bar despite the error. That's a bug but it appears to be of soft variety. cp -r as work-around.

[clouds56]

Sorry for confusing D:\data, it is a separate HDD (different from D:).
never mind, mv /mnt/d/test /mnt/c could repro the issue.

Yes I know it works as the files actually moved to another mount point, I'm just concerning about why it is trying to set the attribute, would it break something?

Correctly if I'm wrong:
Does every path in wsl have an attribute system.wsl_case_sensitive (no matter if case=dir|on|off)? And when mv cross mount points, it would trying to apply the attributes to the new place, but since the dest driver have case=off (not dir) so the attr system.wsl_case_sensitive set failed and shows the error?

If so, I think I could blame neither mv nor wsl, they both behaves as intended, while the bug exists.
(What would happen if I mount a case=dir driver to case=off? especially when there's name conflict when case is off? And what would happened when it mount back with case=dir, would the per dir system.wsl_case_sensitive all becomes off?

[therealkenc]

I'm just concerning about why it is trying to set the attribute, would it break something?

Probably not. Mostly just my heart.

Does every path in wsl have an attribute system.wsl_case_sensitive (no matter if case=dir|on|off)?

llistxattr says yes. lsetxattr begs to differ. That is the problem.

There are three states at play and WSL is only taking into account two of them in your scenario. (1) system.wsl_case_sensitive=0, (2) system.wsl_case_sensitive=1, (3) lack of a system.wsl_case_sensitive attribute.

If so, I think I could blame neither mv nor wsl

mv(1) is doing fine, insofar as maintaining xattrs when moving (really, copying) between different mounts is the intended behavior.

[edit] Occurs to me late what Real Linux might do if one tried to mv(1) from ext4 to fat32 and the directory had xattrs. WSL is spitting out EACCES. Might be as simple as WSL returning ENOTSUP instead. [If it were up to me, mv(1) would just bail on different mounts like ye olden tymes.]

What would happen if I mount a case=dir drive

Then the standard the operating procedure would be to delete any directory you created while it was on, and start over with case=off.

[clouds56]

Then the standard the operating procedure would be to delete any directory you created while it was on, and start over with case=off.

this worries me, I'll keep away from trying so.

Thanks for explanation.

[marxangels]

sudo mkdir -p /d
sudo mount --bind /mnt/d /d
sudo mount --bind /mnt/d/srv /srv

mv /d/JavaScript/mymodule /srv/app/
mv: setting attribute 'system.wsl_case_sensitive' for 'system.wsl_case_sensitive': Permission denied

I have encountered such an error, but the following usage is fine.

mv /mnt/d/JavaScript/mymodule /mnt/d/srv/app

[pebojote]

Any patches? I encountered this one today

[pebojote]

Running sudo cp [path from] [path to] seems working fine for me. I think there's a problem when you run sudo mv. While reading the Remote WSL documentation from VS Code, it seems clear to me that I really need to create separate copy from Windows to WSL.

[younes-io]

I still encounter the same issue when I run sudo mv

[0xabu]

I bumped into what looks like the same underlying issue in a python3 build_wheel invocation:

598   listxattr("build/bdist.linux-x86_64/wheel/pdfminer.six-20211012-py3.8.egg-info", "system.wsl_case_sensitive\0", 256) = 26
598   getxattr("build/bdist.linux-x86_64/wheel/pdfminer.six-20211012-py3.8.egg-info", "system.wsl_case_sensitive", "0", 128) = 1
598   setxattr("build/bdist.linux-x86_64/wheel/pdfminer.six-20211012.dist-info", "system.wsl_case_sensitive", "0", 1, 0) = -1 EACCES (Permission denied)

Python seems to be attempting to propagate extended attributes from a xyz.egg-info directory (that it recently created) to a sibling xyz.dist-info directory (that it also just created), and is unsurprisingly upset that it gets EACCES from an attempt to set system.wsl_case_sensitive to "0".

The filesystem in this case is drvfs mounted with case=off.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!