No way to override uid mount setting?

[rhaglennydd]

Please use the following bug reporting template to help produce issues which are actionable and reproducible, including all command-line steps necessary to induce the failure condition. Please fill out all the fields! Issues with missing or incomplete issue templates will be closed.

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

Important: Do not open GitHub issues for Windows crashes (BSODs) or security issues. Please direct all Windows crashes and security issues to [email protected]. Ideally, please configure your machine to capture minidumps, repro the issue, and send the minidump from "C:\Windows\minidump".\

See our contributing instructions for assistance.

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)
  10.0.18363.693

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)
  sudo mount -t drvfs C: /mnt/c -o metadata,uid=1000
cd /mnt/c
sudo touch test.txt
stat -c '%u' test.txt
  Output:
  1000

• What's wrong / what should be happening instead:
  Output should be:
  0 (root)

• 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).

• For WSL launch issues, please collect detailed logs.

I admit I'm not sure whether this is a bug or if this is how it's supposed to be, but it just seems wrong that not even the root can override the mount settings for uid. This creates problems for processes in WSL not owned by user 1000 that access the Windows file system, e.g., a web server process running as another user with a virtual host located on the C: drive can't create files that are owned by itself, they're always owned by user 1000. If this is how mounting with a specified uid is supposed to work, then why do it in the first place? Might as well go back to how it was before the feature was added. Unless, of course, there's some setting or option I'm just not aware of that can allow exceptions?

[therealkenc]

Can't repro here.

[Full disclosure this was on more recent 19569 and WSL1, but that won't matter.]

[therealkenc]

I think I know what might (?) be happening here. I get nonobvious behavior if I don't umount(1) /mnt/c first. I think that might be variation my dead crickets #3963. Here is a more complete sequence showing both root and ken in the same directory.

In other words, if you do your OP mount(1) over an existing /mnt/c you'll probably get unexpected (non-obvious) behavior, depending on how it was first mounted. Either unmount /mnt/c, or don't mount it in the first place. Most folks use the wsl.conf [automount] feature and never see the non-obvious behavior.

[rhaglennydd]

I forgot I already had automount settings in wsl.conf. I unmounted C: and rebooted my computer, but that didn't fix things. The settings in wsl.conf included case=dir. On a hunch, I unmounted C: again and remounted it without the case option. That fixed things. I edited wsl.conf so it's case=off. Do you know why having case=dir would cause this?

UPDATE: Never mind, I rebooted again (after unmounting C: again) and the problem is back. Here are the contents of /etc/wsl.conf:

[automount]
options = case=off,umask=22,fmask=11,uid=1000,gid=1000

So what's the real culprit? umask, fmask?

[therealkenc]

You don't have metadata in the options. The default is no metadata.

[rhaglennydd]

D'oh! Updated wsl.conf, will unmount and reboot later, let you know how it goes.

[therealkenc]

[n.b. You're on your own with case=dir.]

[rhaglennydd]

Can confirm that it's fixed now. Thanks!