Permission issue with read-only files in DrvFs-mounted network drives

[socram8888]

Windows Version

Microsoft Windows [Versión 10.0.19044.4894]

WSL Version

0.0.0.0

Are you using WSL 1 or WSL 2?

• [ ] WSL 2
• [X] WSL 1

Kernel Version

Linux version 4.4.0-19041-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #4355-Microsoft Thu Apr 12 17:37:00 PST 2024

Distro Version

Debian Bookworm

Other Software

No response

Repro Steps

Mount any network drive like so:

mkdir /mnt/nas
mount -t drvfs -o uid=1000,gid=1000 '\\192.168.0.22\shared' /mnt/nas

Create a test executable that will write create and write to a file with 0444 permissions:

#include <fcntl.h>
#include <stdio.h>
#include <string.h>

int main() {
    int ret = open("test-file", O_RDWR|O_CREAT|O_EXCL, 0444);
    if (ret < 0) {
        printf("Failed. Error: %s (%d)\n", strerror(-ret), ret);
    } else {
        printf("Succeeded\n");
    }
    return 0;
}

Expected Behavior

The file should be created and the handle is returned. This works in real Linux, and also when outside a SMB share.

Actual Behavior

The file gets actually created, but returns a -1 EACCESS. Furthermore, the file can not be deleted using "rm" (not even as root) unless the permissions are changed via a chmod. Despite metadata not being enabled, permissions are somehow still applied:

marcos@DESKTOP-K9N8FLQ:/mnt/nas$ ls -la test-file
-r-xr-xr-x 1 marcos marcos 0 Sep 18 13:39 test-file

create-strace.log rm-strace.log

Diagnostic Logs

No response

[github-actions[bot]]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute [collect-wsl-logs.ps1](https://github.com/Microsoft/WSL/blob/master/diagnostics/collect-wsl-logs.ps1) in an **administrative powershell prompt**: ``` Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1 Set-ExecutionPolicy Bypass -Scope Process -Force .\collect-wsl-logs.ps1 ``` The script will output the path of the log file once done. If this is a networking issue, please use [collect-networking-logs.ps1](https://github.com/Microsoft/WSL/blob/master/diagnostics/collect-networking-logs.ps1), following the instructions [here](https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#collect-wsl-logs-for-networking-issues) Once completed please upload the output files to this Github issue. [Click here for more info on logging](https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#8-collect-wsl-logs-recommended-method) If you choose to email these logs instead of attaching to the bug, please send them to wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

• Cannot create symbolic links on drvfs network share (#5524), similarity score: 0.71

Closed similar issues:

• Permission inheritance is wrong on DrvFs with -o metadata (#2774), similarity score: 0.72
• Issues in reading and writing files in a Sharepoint folder with drvfs (#7037), similarity score: 0.72
• WSL1 overlayfs incorrectly manages file permissions (#8748), similarity score: 0.71
• Cannot access btrfs drive from Windows (#6711), similarity score: 0.71

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[socram8888]

Attached logs: WslLogs-2024-09-18_13-47-58.zip

For the record, this current behaviour breaks Git, which uses this file mode for the database, as evidenced by multiple issues reported elsewhere:

• https://superuser.com/questions/1450094/git-on-wsl-commands-fail-despite-permissions-seeming-fine
• https://superuser.com/questions/681196/debugging-git-repo-permissions-on-samba-share
• https://superuser.com/questions/1491499/use-git-on-a-shared-drive-within-wsl

[github-actions[bot]]

The log file doesn't contain any WSL traces. Please make sure that you reproduced the issue while the log collection was running.

Diagnostic information

``` Found '/question', adding tag 'question' Appx package is not installed Found no WSL traces in the logs ```

[socram8888]

Again, restarting the LxssManager service beforehand just in case: WslLogs-2024-09-18_13-59-31.zip

[github-actions[bot]]

Diagnostic information

``` Appx package is not installed ```

[socram8888]

Seems the cause is WSL1 settings the Read-only bit while opening. If the file is first opened with write permissions (eg 0600) and then chmod to 0444, it works.

[bk2204]

We got informed about this on the Git list. This is a common error in a variety of file systems, including some NFS servers. POSIX says this:

The argument following the oflag argument does not affect whether the file is open for reading, writing, or for both.

That is, POSIX forbids failing to open a file for writing because the permissions are 0444, and as such this is not POSIX compliant. Linux also does not have this bug, and follows the standard in this regard, so this is definitely a WSL bug.