mounts with differing fmask,uid,etc on same NTFS volume not respected with DrvFS

[therealkenc]

This is pulled out of #3267.

• Your Windows build number: (Type ver at a Windows Command Prompt)
• What you're doing and what's happening:

Repro:

$ cat /proc/version
Linux version 4.4.0-18865-Microsoft ([email protected]) (gcc version 5.4.0 (GCC) ) #1000-Microsoft Fri Mar 22 15:03:00 PST 2019
$ lsb_release -d
Description:    Ubuntu 18.04.2 LTS
$ cd / && sudo mkdir -p /tmp/mnt111 && sudo mkdir -p /tmp/mnt222
$ sudo umount /mnt/c   # assuming automount is enabled
$ sudo mount -t drvfs C:\\ /tmp/mnt111 -o "metadata,fmask=111"
$ sudo mount -t drvfs C:\\ /tmp/mnt222 -o "metadata,fmask=222"
$ mount | grep /tmp/mnt
C:\ on /tmp/mnt111 type drvfs (rw,relatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
C:\ on /tmp/mnt222 type drvfs (rw,relatime,uid=1000,gid=1000,fmask=111,metadata,case=off)
$ sudo umount /tmp/mnt111 && sudo umount /tmp/mnt222
$ sudo mount -t drvfs C:\\ /tmp/mnt222 -o "metadata,fmask=222"
$ mount | grep /tmp/mnt
C:\ on /tmp/mnt222 type drvfs (rw,relatime,fmask=222,metadata,case=off)

Experimentally, only the first fmask takes and users are stuck with the first fmask used (which is usually the automounted /mnt/c).

• Strace of the failing command

There are no fails on mount(2) in the strace(1) log natch, because the commands succeed.

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

Ideally both fmask=111 and fmask=222 would be respected. Or, at least that is a reasonable interpretation.

In the alternative, if this is an unsupported scenario, I suppose mount(2) could return EINVAL. Simply dropping the fmask requested on the floor and succeeding silently is problematic, because the user won't have asked for a different fmask for their health. They get no indication their requested fmask failed to take.

In the alternative to the alternative of returning EINVAL, the documentation probably deserves clarification regarding the expected behavior.

[therealkenc]

Formalizing #4954, the OP behavior above is not limited to fmask. Ditto uid,gid. Near certainly the same underlying cause.

Pretty safe to assume this goes for the other options (metadata, ro, noexec, nodev, nosuid, yadda) as well (without actually having tried).

The uid use case is more notable than fmask (which is admittedly a somewhat questionable thing to do). It is the basis on which automounted /media/username/label works on Real Linux ref #267 #560.

[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!