Synchronized file shares: all mmap() fails with ENODEV since 4.87.0, still present in 4.88.1; git fails with "fatal: mmap failed: No such device"

Bug report

Bug description

Starting with Docker Desktop 4.87.0 (236836), and still present in 4.88.1 (237512), every mmap() call on a file under a Synchronized file share fails with ENODEV (errno 19), for both MAP_PRIVATE and MAP_SHARED, in every container that mounts the share. Ordinary reads and writes still work, and Mutagen sync still propagates changes between the host and the VM copy; only memory mapping fails.

I encountered this issue as a git failure: git memory-maps .git/index, so every git command inside a container whose repository lives on a synchronized share dies immediately:

$ git status
fatal: mmap failed: No such device

On 4.86.0 (236216), mmap() works on the same share with the same settings; I expected that to keep working after updating.

What I found while isolating it:

Timing: my dev container logs show no such errors through Aug 25 on 4.86.0. The in-app updater finished installing 4.87.0 at 13:21:58 UTC on Aug 26, and the first mmap failed error was logged at 13:25:39 UTC, four minutes later, with no configuration change in between.
Downgrading to 4.86.0 with settings unchanged fixed it; installing 4.88.1 brought the failure back.
The failure is in the selfowner layer, not in Mutagen or the synced data. Inside the VM, the share's data lives at /var/lib/mutagen/file-shares/<id>/root on ext4 and is re-exported through selfowner mounts. With both paths mounted into one container (checked on 4.87.0 and again on 4.88.1), the same file mmaps fine via the raw ext4 path and fails through the share:
```
/raw/fshr_<id>/root/.git/index -> mmap OK
/sync/.git/index               -> mmap FAIL 19 No such device
```
mmap(2) documents ENODEV as "the underlying filesystem of the specified file does not support memory mapping", and /proc/filesystems in the VM lists selfowner as a nodev filesystem, so the selfowner module in the new kernel appears not to implement the mmap file operation.
Kernel versions: 4.86.0 (working) reports 6.12.76-linuxkit. 4.87.0 (failing) reported 7.0.12-linuxkit #1 SMP PREEMPT Wed Aug 12 20:18:49 UTC 2026, matching the "Linux kernel v7.0.12" entry in its release notes. 4.88.1 (failing) reports 7.0.12-linuxkit #1 SMP PREEMPT Fri Aug 14 16:27:59 UTC 2026, so the kernel was rebuilt between releases but stayed on v7.0.12 and behaves the same.
The failure occurred under two different Virtual Machine Manager selections; I switched the VMM while troubleshooting on 4.87.0 and it made no difference, which is consistent with the guest kernel being the changed component.
The 4.88.0 and 4.88.1 release notes list no kernel change and nothing related to file sharing, and testing 4.88.1 confirms the behavior is unchanged there.

Reproduction steps

Run verbatim on 4.88.1 (237512); the same commands succeed on 4.86.0 (236216).

On Docker Desktop 4.87.0 or 4.88.1 on macOS, configure a Synchronized file share for a host directory containing a git working tree, for example /Users/me/project.

Check that the container sees the share as selfowner (confirming that it is in fact using a Synchronized file share), then try to mmap a file on it:

docker run --rm -v /Users/me/project:/t alpine grep ' /t ' /proc/mounts
docker run --rm -v /Users/me/project:/t python:3.12-alpine python3 -c \
  "import mmap,os; fd=os.open('/t/.git/index',os.O_RDONLY); mmap.mmap(fd,4096,prot=mmap.PROT_READ,flags=mmap.MAP_PRIVATE); print('mmap OK')"

Observed output:

/run/mutagen-file-shares-mark /t selfowner rw,nosuid,nodev,relatime 0 0
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 19] No such device

Run any git command in a container against the same directory:
```
docker run --rm -v /Users/me/project:/t alpine/git -c safe.directory=/t -C /t status
```
Observed: fatal: mmap failed: No such device.
Run the same commands on 4.86.0: the mount is still selfowner, the probe prints mmap OK, and git prints normal status output.

Platform

macOS

Version information

fdintM4QLX2PXVP:~/www/ollie(codex/unpublished-preview-rss⁺)$ docker version && docker info
Client:
 Version:           29.7.2
 API version:       1.55
 Go version:        go1.26.5
 Git commit:        a7dcaa6
 Built:             Wed Aug  5 18:27:50 2026
 OS/Arch:           darwin/arm64
 Context:           desktop-linux

Server: Docker Desktop 4.88.1 (237512)
 Engine:
  Version:          29.7.2
  API version:      1.55 (minimum version 1.40)
  Go version:       go1.26.5
  Git commit:       6a43e3d
  Built:            Wed Aug  5 18:28:35 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.3.3
  GitCommit:        aad11006b869517fcd3009450b6f82da282e1a9b
 runc:
  Version:          1.4.3
  GitCommit:        v1.4.3-0-gbb14dabe
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
Client:
 Version:    29.7.2
 Context:    desktop-linux
 Debug Mode: false
 Plugins:
  agent: Docker AI Agent Runner (Docker Inc.)
    Version:  v1.124.0
    Path:     /Users/fdintino/.docker/cli-plugins/docker-agent
  ai: Docker AI Agent - Ask Gordon (Docker Inc.)
    Version:  v1.30.0
    Path:     /Users/fdintino/.docker/cli-plugins/docker-ai
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.36.1-desktop.1
    Path:     /Users/fdintino/.docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.4.0
    Path:     /Users/fdintino/.docker/cli-plugins/docker-compose
  debug: Get a shell into any image or container (Docker Inc.)
    Version:  0.0.47
    Path:     /Users/fdintino/.docker/cli-plugins/docker-debug
  desktop: Docker Desktop commands (Docker Inc.)
    Version:  v0.4.3
    Path:     /Users/fdintino/.docker/cli-plugins/docker-desktop
  dhi: CLI for managing Docker Hardened Images (Docker Inc.)
    Version:  v0.0.7
    Path:     /Users/fdintino/.docker/cli-plugins/docker-dhi
  extension: Manages Docker extensions (Docker Inc.)
    Version:  v0.2.31
    Path:     /Users/fdintino/.docker/cli-plugins/docker-extension
  init: Creates Docker-related starter files for your project (Docker Inc.)
    Version:  v1.4.0
    Path:     /Users/fdintino/.docker/cli-plugins/docker-init
  mcp: Docker MCP Plugin (Docker Inc.)
    Version:  v0.43.3
    Path:     /Users/fdintino/.docker/cli-plugins/docker-mcp
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.2.6
    Path:     /Users/fdintino/.docker/cli-plugins/docker-model
  offload: Docker Offload (Docker Inc.)
    Version:  v0.6.13
    Path:     /Users/fdintino/.docker/cli-plugins/docker-offload
  pass: Docker Pass Secrets Manager Plugin (beta) (Docker Inc.)
    Version:  v0.2.1
    Path:     /Users/fdintino/.docker/cli-plugins/docker-pass
  sandbox: "docker sandbox" is deprecated, use Docker Sandboxes instead (Docker Inc.)
    Version:  v0.13.0
    Path:     /Users/fdintino/.docker/cli-plugins/docker-sandbox
  scout: Docker Scout (Docker Inc.)
    Version:  v1.24.0
    Path:     /Users/fdintino/.docker/cli-plugins/docker-scout

Server:
 Containers: 16
  Running: 3
  Paused: 0
  Stopped: 13
 Images: 52
 Server Version: 29.7.2
 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
 Discovered Devices:
  cdi: docker.com/gpu=webgpu
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: aad11006b869517fcd3009450b6f82da282e1a9b
 runc version: v1.4.3-0-gbb14dabe
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 7.0.12-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: aarch64
 CPUs: 16
 Total Memory: 15.6GiB
 Name: docker-desktop
 ID: 23bf78d2-b114-430a-85e0-df9064b31fba
 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/fdintino/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
 Firewall Backend: iptables

Diagnostics ID

CF44FBCF-B8AE-4A08-9D02-9EBFD0A35B8C/20260827031358

We ran into this today. Ruby 3.4+ uses mmap to read files so this basically makes synchronized file shares unusable on ruby projects :(

I also faced this is still present in 4.89.0 (238018). Three measurements from my environment to add.

1. v4.89.0 ships the same kernel build as v4.88.1.

$ docker run --rm alpine cat /proc/version
Linux version 7.0.12-linuxkit (root@buildkitsandbox) (gcc (Alpine 15.2.0) 15.2.0,
GNU ld (GNU Binutils) 2.45.1) #1 SMP PREEMPT Fri Aug 14 16:27:59 UTC 2026

Identical to the 4.88.1 string above. Reproduced on a throwaway share (~/src/mmap-repro):

mount:       /run/mutagen-file-shares-mark on /m type selfowner (rw,nosuid,nodev,relatime)
read():      hello
MAP_PRIVATE  mmap FAILED: errno=19 No such device
MAP_SHARED   mmap FAILED: errno=19 No such device

A plain bind mount on a path covered by no share (virtiofs) passes both.

Host: macOS 26.6.2 (25G83), Apple M3, arm64, Docker Engine 29.7.2, VirtioFS.

2. The loaded `selfowner` module does export an mmap handler.

$ docker run --rm --privileged alpine grep selfowner /proc/kallsyms | grep mmap
ffff80007a648418 t selfowner_mmap	[selfowner]

Noting this because the report reads as though the file operation may be absent.

3. Executing a binary stored on the share fails with SIGSEGV.

# on the share
$ docker run --rm -v ~/src/mmap-repro:/m alpine sh -c \
    'cp /bin/busybox /m/busybox && chmod +x /m/busybox && /m/busybox echo OK'
# exit 139, no output

# same binary, container's own filesystem
$ docker run --rm alpine sh -c \
    'cp /bin/busybox /tmp/busybox && chmod +x /tmp/busybox && /tmp/busybox echo OK'
OK

So native binaries installed onto a share cannot be run. In our case that shows up as Yarn failing to build esbuild and node-gyp failing on tree-sitter, with no mention of mmap in either error.

This should be fixed with Desktop 4.90. Can you please test?

In my case, I have confirmed that has been fixed in v4.90.0. Thank you!

Navigation Menu

Repository navigation

Synchronized file shares: all mmap() fails with ENODEV since 4.87.0, still present in 4.88.1; git fails with "fatal: mmap failed: No such device" #627

Bug report

Bug description

Reproduction steps

Platform

Version information

Diagnostics ID

1. v4.89.0 ships the same kernel build as v4.88.1.

2. The loaded `selfowner` module does export an mmap handler.

3. Executing a binary stored on the share fails with SIGSEGV.

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Synchronized file shares: all mmap() fails with ENODEV since 4.87.0, still present in 4.88.1; git fails with "fatal: mmap failed: No such device" #627

Description

Bug report

Bug description

Reproduction steps

Platform

Version information

Diagnostics ID

Activity

yboulkaid commented on Sep 2, 2026

ziguzagu commented on Sep 4, 2026

1. v4.89.0 ships the same kernel build as v4.88.1.

2. The loaded selfowner module does export an mmap handler.

3. Executing a binary stored on the share fails with SIGSEGV.

bsousaa commented on Sep 8, 2026

ziguzagu commented on Sep 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

2. The loaded `selfowner` module does export an mmap handler.