VirtioFS directory mapping wrong uid/gid on Darwin (docker rootful template)

[paolomainardi]

Description

Hi everyone!

I'm experiencing an issue with incorrect UID/GID mapping for an existing directory. When this directory is mapped inside a container, I expect it to be mounted with the uid:gid as files, which is the usual behavior on Linux with Docker Desktop.

Here’s what is happening when comparing Lima and Docker Desktop:

❯ ls -altr
total 0
-rw-r--r--@   1 paolomainardi  staff     0 Sep 18 17:07 test
drwxr-xr-x@   3 paolomainardi  staff    96 Sep 18 17:07 .
drwxr-xr-x@ 105 paolomainardi  staff  3360 Sep 18 17:13 ..

❯ docker context use lima-sf-docker-dev
lima-sf-docker-dev
Current context is now "lima-sf-docker-dev"

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -altr / | grep test"
drwxr-xr-x    3 root     root            96 Sep 18 15:07 test

❯ docker context use desktop-linux
desktop-linux
Current context is now "desktop-linux"

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -altr / | grep test"
drwxr-xr-x    3 501      root            96 Sep 18 15:07 test

This isn’t a major issue, but it has disrupted several of my scripts, including a command that triggers the error fatal: detected dubious ownership in repository when running git rev-parse --show-toplevel.

[AkihiroSuda]

Seems relevant:

• virtiofs: file ownerships dynamically changes depending on the caller's UID #1513

[paolomainardi]

Seems relevant:

• virtiofs: file ownerships dynamically change depending on the caller's UID #1513

Not much, because in this case, just the directory has a UID/GID issue; files are correctly mapped.

[paolomainardi]

What I find more interesting is this ownership behavior difference. Basically, the permissions are shown right inside the directory, but they appear differently from the outside depending on whether you're using Lima, Docker Desktop, or native Linux Docker.

Linux Native (Reference Behavior)

paolomainardi@instance-20250918-145326:~/test$ id -u
1000
paolomainardi@instance-20250918-145326:~/test$ docker run -u 1000 --rm -v $PWD:/test alpine:latest ash -c "ls -al /test"
total 20
drwxr-xr-x    4 1000     1001          4096 Sep 19 08:14 .
drwxr-xr-x    1 root     root          4096 Sep 19 08:15 ..
drwxr-xr-x    7 1000     1001          4096 Sep 19 08:14 .git
-rw-r--r--    1 1000     1001            47 Sep 19 08:13 Dockerfile
-rw-r--r--    1 1000     1001             0 Sep 19 08:13 file
drwxr-xr-x    2 1000     1001          4096 Sep 19 08:13 subdir

paolomainardi@instance-20250918-145326:~/test$ docker run -u 1000 --rm -v $PWD:/test alpine:latest ash -c "ls -al / | grep test"
drwxr-xr-x    4 1000     1001          4096 Sep 19 08:14 test

What I'm seeing here:

1. Inside the directory: drwxr-xr-x 4 1000 1001 - correct, shows I own it ✅
2. From root level: drwxr-xr-x 4 1000 1001 - correct, consistent ownership ✅
3. Files: 1000:1001 - correct ✅

Lima (macOS)

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al /test"
drwxr-xr-x    6 501      root           192 Sep 19 07:59 .
drwxr-xr-x    1 root     root          4096 Sep 19 08:04 ..
drwxr-xr-x    9 501      root           288 Sep 19 07:58 .git
-rw-r--r--    1 501      root            47 Sep 19 07:59 Dockerfile
-rw-r--r--    1 501      root             0 Sep 19 06:58 file
drwxr-xr-x    3 501      root            96 Sep 19 08:00 subdir

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al / | grep test"
drwxr-xr-x    3 root     root            96 Sep 19 06:58 test

What I'm seeing here:

1. Inside the directory: drwxr-xr-x 3 501 root - correct, shows I own it ✅
2. From root level: drwxr-xr-x 3 root root - incorrect, shows root owns it ❌
3. Files: 501:root - correct ✅

Docker Desktop (macOS)

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al /test"
total 8
drwxr-xr-x    6 501      root           192 Sep 19 07:59 .
drwxr-xr-x    1 root     root          4096 Sep 19 08:04 ..
drwxr-xr-x    9 501      root           288 Sep 19 07:58 .git
-rw-r--r--    1 501      root            47 Sep 19 07:59 Dockerfile
-rw-r--r--    1 501      root             0 Sep 19 06:58 file
drwxr-xr-x    3 501      root            96 Sep 19 08:00 subdir

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al / | grep test"
drwxr-xr-x    6 501      root           192 Sep 19 07:59 test

What I'm seeing here:

1. Inside the directory: drwxr-xr-x 3 501 root - correct ✅
2. From root level: drwxr-xr-x 6 501 root - also correct! ✅
3. Files: 501:root - correct ✅

The practical impact

I can reproduce this issue with a simple test case. Given this Dockerfile:

FROM alpine:latest
RUN apk add --no-cache git

Build with: docker build -t test/git .

Linux native works fine:

paolomainardi@instance-20250918-145326:~/test$ docker run -u 1000 --rm -v $PWD:/test test/git ash -c "cd test/subdir && git rev-parse --show-toplevel"
/test

Lima breaks Git:

❯ docker run -u 501 --rm -v $PWD:/test test/git ash -c "cd test/subdir && git rev-parse --show-toplevel"
fatal: detected dubious ownership in repository at '/test'
To add an exception for this directory, call:
        git config --global --add safe.directory /test

Docker Desktop works fine:

❯ docker run -u 501 --rm -v $PWD:/test test/git ash -c "cd test/subdir && git rev-parse --show-toplevel"
/test

So this confirms that Lima's inconsistent ownership reporting is the outlier here. Both native Linux Docker and Docker Desktop maintain consistent ownership visibility from all perspectives, while Lima has this quirky behavior that's probably related to how it handles volume mounts through its virtualization stack (virtiofs + Apple Virtualization Framework).

[paolomainardi]

Just opened an issue to VirtioFS too, to ask their opinion on this: https://gitlab.com/virtio-fs/virtiofsd/-/issues/217

[AkihiroSuda]

Just opened an issue to VirtioFS too, to ask their opinion on this: https://gitlab.com/virtio-fs/virtiofsd/-/issues/217

I don't think Apple's virtiofs implementation uses https://gitlab.com/virtio-fs/virtiofsd

[afbjorklund]

You would want to check with QEMU (macOS / virtfs), QEMU (Linux / virtfs), QEMU (Linux / virtiofsd*) as well.

* it is not the default (the built-in required root), so it needs to be separately installed by using the Rust code

[paolomainardi]

Just opened an issue to VirtioFS too, to ask their opinion on this: https://gitlab.com/virtio-fs/virtiofsd/-/issues/217

I don't think Apple's virtiofs implementation uses https://gitlab.com/virtio-fs/virtiofsd

You're right, I just made a wrong assumption, going to close it.

[paolomainardi]

You would want to check with QEMU (macOS / virtfs), QEMU (Linux / virtfs), QEMU (Linux / virtiofsd*) as well.

• it is not the default (the built-in required root), so it needs to be separately installed by using the Rust code

Following Ite suggestion from the comments, I tested with qemu + 9p instead of the default **VirtioFS, that cannot be used with qemu, at least on Darwin:

? Do you want to start the instance now?  Yes
INFO[0008] Starting the instance "default" with VM driver "qemu"
INFO[0008] QEMU binary "/opt/homebrew/bin/qemu-system-aarch64" seems properly signed with the "com.apple.security.hypervisor" entitlement
FATA[0008] field `mountType` must be "reverse-sshfs" or "9p" for QEMU driver on non-Linux, got "virtiofs"

macOS + qemu + 9p

# Created with: limactl create --name=default --vm-type=qemu --mount-type=9p --mount-writable --memory=16 --cpus=8 --disk=100 template://docker-rootful

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al / | grep test"
drwxr-xr-x    6 501      dialout        192 Sep 19 07:59 test
❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al /test"  
total 8
drwxr-xr-x    6 501      dialout        192 Sep 19 07:59 .
drwxr-xr-x    1 root     root          4096 Sep 19 10:02 ..
drwxr-xr-x    9 501      dialout        288 Sep 19 08:12 .git
-rw-r--r--    1 501      dialout         47 Sep 19 07:59 Dockerfile
-rw-r--r--    1 501      dialout          0 Sep 19 06:58 file
drwxr-xr-x    3 501      dialout         96 Sep 19 08:00 subdir
❯ docker run -u 501 --rm -v $PWD:/test test/git ash -c "cd test/subdir && git rev-parse --show-toplevel"
/test

Results

1. Inside the directory: drwxr-xr-x 6 501 dialout - correct ✅
2. From root level: drwxr-xr-x 6 501 dialout - correct ✅
3. Files: 501:dialout - correct ✅

[paolomainardi]

I've just tried another container runtime for MacOS, another closed-source popular one, https://orbstack.dev which sould be based con VZ + VirtioFS too.

Results

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al / | grep test"
drwxr-xr-x    1 501      root           192 Sep 19 07:59 test

❯ docker run -u 501 --rm -v $PWD:/test alpine:latest ash -c "ls -al /test"
total 4
drwxr-xr-x    1 501      root           192 Sep 19 07:59 .
drwxr-xr-x    1 root     root            20 Sep 19 10:17 ..
drwxr-xr-x    1 501      root           288 Sep 19 08:12 .git
-rw-r--r--    1 501      root            47 Sep 19 07:59 Dockerfile
-rw-r--r--    1 501      root             0 Sep 19 06:58 file
drwxr-xr-x    1 501      root            96 Sep 19 08:00 subdir

1. Inside the directory: drwxr-xr-x 6 501 dialout - correct ✅
2. From root level: drwxr-xr-x 6 501 dialout - correct ✅
3. Files: 501:dialout - correct ✅

[paolomainardi]

Just opened an issue to VirtioFS too, to ask their opinion on this: https://gitlab.com/virtio-fs/virtiofsd/-/issues/217

I don't think Apple's virtiofs implementation uses https://gitlab.com/virtio-fs/virtiofsd

Some interesting tips shared by Virtiofsd devs: https://gitlab.com/virtio-fs/virtiofsd/-/issues/217#note_2763575847

[afbjorklund]

There was some talk about adding a krun driver. next to qemu-with-virtiofsd:

• Support libkrun (mostly for Virtio-GPU Venus), maybe via krunkit #2277

Porting virtiofsd to Darwin could probably also be done, like it was for virtfs* (9p)

* originally virtfs was Linux-only, which caused Podman 3 to not have any volumes...