for-mac icon indicating copy to clipboard operation
for-mac copied to clipboard
verified publisher icon docker

Docker VMM: unexpected file permissions on macOS for files created in mounted volumes

Open adamnorwood opened this issue 9 months ago • 0 comments

Description

Using the Docker Virtual Machine Manager (VMM) setting in Docker Desktop for macOS has caused an issue for our team: after using it for about a month, I finally noticed that files created in mounted volumes by the container have incorrect/unexpected file permissions on the macOS host side of things, at least compared to how the permissions worked when using the Apple Virtualization framework (consistently using VirtioFS for testing this issue since that's the only option allowed with VMM).

Running Docker Desktop with the Apple Virtualization framework, files are created with these default permissions: -rw-r--r-- (644).

Running Docker Desktop with the beta VMM setting enabled, the same files are created with these default permissions: -rw-------@ (600) and with these extended attributes (as read with xattr -lx):

00000000  01 02 00 00 80 31 FC 5B 98 E0 F4                 |.....1.[...|
0000000B
user.containers.override_stat:
00000000  30 3A 30 3A 30 31 30 30 36 34 34                 |0:0:0100644|
0000000B

From inside of the container (e.g., running a shell or using the Docker Desktop container's Exec tab), the filesystem shows the expected 644 permissions.

This discrepancy isn't causing a problem inside our containerized application, but it's problematic when I've needed to transfer files between the host machine and other servers, especially as the file permissions prevent Apache and/or PHP from being able to serve the files (in our hosting environment where group read access is necessary). This issue might be related to these other recent comments mentioning PHP errors?

https://github.com/docker/for-mac/issues/7464#issuecomment-2485587042 https://github.com/docker/for-mac/issues/7464#issuecomment-2487116333 https://github.com/docker/for-mac/issues/7464#issuecomment-2621539570

Am I missing a documented means or a setting for Docker VMM that would allow it to work consistently with the previous engines' bind mounting / Virtiofs / whatever the difference is? Or is this possible a bug with the beta Docker VMM itself?

Thanks!

Reproduce

  1. With the Docker VMM option enabled in Docker Desktop for Mac, run the following docker command as a demo. This will create an empty text file in a new directory on your host machine at ~/vmm-file-permissions-issue/example.txt (sorry if there's a snazzier way to demo this basic "container with a mounted volume" setup…). This also echos out (ls -la) the permissions as seen from inside the container before it quits.
docker run --rm \
  -v ~/vmm-file-permissions-issue:/example \
  busybox:latest \
  sh -c "touch /example/example.txt && ls -la /example/example.txt"
  1. Run ls -la ~/vmm-file-permissions-issue/example.txt from your host machine. This will report -rw-------@ for that example.txt file (different from the container script's output in step 1).

Expected behavior

With all else being equal apart from the switch to the Docker VMM option, the expected behavior is that the file permissions would be consistent with the prior virtualization options: -rw-r--r--. Switching between the Docker VMM and Apple Virtualization options shouldn't cause unexpected file system changes.

docker version

Client:
 Version:           28.0.1
 API version:       1.48
 Go version:        go1.23.6
 Git commit:        068a01e
 Built:             Wed Feb 26 10:38:16 2025
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.39.0 (184744)
 Engine:
  Version:          28.0.1
  API version:      1.48 (minimum version 1.24)
  Go version:       go1.23.6
  Git commit:       bbd0a17
  Built:            Wed Feb 26 10:40:57 2025
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          1.7.25
  GitCommit:        bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc:
  Version:          1.2.4
  GitCommit:        v1.2.4-0-g6c52b3f
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

docker info

Client:
 Version:    28.0.1
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v0.9.8
    Path:     /Users/anorwood/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.21.1-desktop.2
    Path:     /Users/anorwood/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.33.1-desktop.1
    Path:     /Users/anorwood/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.38
    Path:     /Users/anorwood/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Beta) (Docker Inc.)
    Version:  v0.1.5
    Path:     /Users/anorwood/.docker/cli-plugins/docker-desktop
  dev: Docker Dev Environments (Docker Inc.)
    Version:  v0.1.2
    Path:     /Users/anorwood/.docker/cli-plugins/docker-dev
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.27
    Path:     /Users/anorwood/.docker/cli-plugins/docker-extension
  feedback: Provide feedback, right in your terminal! (Docker Inc.)
    Version:  v1.0.5
    Path:     /Users/anorwood/.docker/cli-plugins/docker-feedback
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/anorwood/.docker/cli-plugins/docker-init
  sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
    Version:  0.6.0
    Path:     /Users/anorwood/.docker/cli-plugins/docker-sbom
  scout: Docker Scout (Docker Inc.)
    Version:  v1.16.3
    Path:     /Users/anorwood/.docker/cli-plugins/docker-scout

Server:
 Containers: 10
  Running: 0
  Paused: 0
  Stopped: 10
 Images: 15
 Server Version: 28.0.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: bcc810d6b9066471b0b6fa75f557a15a1cbf31bb
 runc version: v1.2.4-0-g6c52b3f
 init version: de40ad0
 Security Options:
  seccomp
   Profile: unconfined
  cgroupns
 Kernel Version: 6.10.14-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 12
 Total Memory: 11.67GiB
 Name: docker-desktop
 ID: 735adcd2-5506-45b5-b02b-9b2d7300560c
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 No Proxy: hubproxy.docker.internal
 Labels:
  com.docker.desktop.address=unix:///Users/anorwood/Library/Containers/com.docker.docker/Data/docker-cli.sock
 Experimental: false
 Insecure Registries:
  hubproxy.docker.internal:5555
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 9.255.0.0/16, Size: 24
WARNING: daemon is not using the default seccomp profile

Diagnostics ID

EEF8DAA8-7233-4B72-B39A-F7C0DBAEF882/20250319160229

Additional Info

No response

adamnorwood avatar Mar 19 '25 16:03 adamnorwood