Permissions issue with VirtioFS

[abentele]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID:

Summary / Steps to reproduce

I started a gitlab container with docker compose.
This container has a volume:

<some-local-folder>:/var/opt/gitlab:cached

what I did in the running container (note the commands access a sub-folder of the volume):

chmod 2770 /var/opt/gitlab/git-data/repositories
stat --printf='%04a' $(readlink -f /var/opt/gitlab/git-data/repositories) | grep -o '....$'

Expected behavior

I would expect the permissions of this folder are as set by the chmod command before:

Therefore the output of the stat command should be:

2770

Actual behavior

output of the stat command with setting "gRPC FUSE" of Docker Desktop (this is ok):

2770

output of the stat command with setting "VirtioFS" of Docker Desktop (this is wrong!):

0770

Btw.: gitlab fails on startup because of this issue.

Information

The problem should be reproducible with any other container.
The problem is since I switched my settings to VirtioFS. With setting gRPC FUSE it works.

• macOS Version: 13.0.1
• Intel chip or Apple chip: Intel
• Docker Desktop Version: 4.15.0 (93002)

Output of /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check

Starting diagnostics

[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0014: are the backend processes running?
[PASS] DD0007: is the backend responding?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0012: is the VM networking working?
[SKIP] DD0030: is the image access management authorized?
[FAIL] DD0019: is the com.docker.vmnetd process responding? failed to ping vmnetd with error: failed to connect to /var/run/com.docker.vmnetd.sock: is vmnetd running?: dial unix /var/run/com.docker.vmnetd.sock: connect: no such file or directory
[PASS] DD0033: does the host have Internet access?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0032: do Docker networks overlap with host IPs?

Please investigate the following 1 issue:

1 : The test: is the com.docker.vmnetd process responding?
    Failed with: failed to ping vmnetd with error: failed to connect to /var/run/com.docker.vmnetd.sock: is vmnetd running?: dial unix /var/run/com.docker.vmnetd.sock: connect: no such file or directory

The com.docker.vmnetd process is needed to create symlinks for CLIs in your path.

Steps to reproduce the behavior

See above.

[niccolomineo]

Still testing this, but might be related to what the OP is experiencing: since updating to 4.15, when I git pull the files are set to 755 instead of 644. My umask seems to be defaulting to what I expect (0022). I don't seem to have any problems with the other virtualization modes available.

[thaJeztah]

Thanks for reporting; I just hit this issue myself; I'm discussing with the team working on VirtioFS, and they're looking into it.

[fasmat]

Same here. For some reason all files inside my devcontainer are now marked as executable after a git pull.

[bramru]

Same here, rolling back to 4.14.1 solves the problem

[thaJeztah]

Short update; I see a patch is being worked on to fix this (but not finished yet); from the description, it looks like there may be a bug on Apple's side, but we're looking at a workaround until that's fixed.

[markeissler]

I can also confirm this issue. It's really creating havoc while working in a VSCode devcontainer. Files randomly reset their permissions from 0644 to 0755 in the container. Then if try to run a git status in the host OS (macOS Monterey) git thinks ALL of the files have changed (or a ton of them) and a git diff indicates that the permissions have changed (from 0755 to 0644). This might be impacting my ability to rebase as well but not sure.

[markeissler]

Switched back to "gRPC FUSE" for now. Seems like a good enough work around until a fix is in place.

[fredericdalleau]

Hey there, this build no longer sets the executable bit on your volume files :
amd64: https://desktop-stage.docker.com/mac/main/amd64/94201/Docker.dmg
arm64: https://desktop-stage.docker.com/mac/main/arm64/94201/Docker.dmg
Let us know if any issue occurs, Thanks!

[fredericdalleau]

@abentele note that this executable bit issue is different for the issue you're facing. Investigation continues.

[oinopion]

@fredericdalleau my team experienced the same problem with permissions in dev container on 4.15. The build that you've linked resolves the problem for us 👍

Is this likely to be released soon?