Yolobox does not have permission to read a folder

[programming-wolf]

yolobox version

v0.9.0 (darwin/arm64

Environment

macos 26.3.1 (25D2128)

What happened?

When I start yolobox, it does not have permission to read the folder that's mounted.

🎲 ls
ls: reading directory '.': Permission denied

It worked very well (I love it) until I updated to macOS 26.3.1. Now it has this error 🙁 Any ideas what this might be? yolobox claude has the same issue, that it has no permission.
Thanks!

What did you expect?

I expected yolobox to work just as before.

[finbarr]

Hmm that's weird. I'm going to try updating to the same version and see if I can break it too.

[finbarr]

Thanks for the report! I'm on the same macOS version (26.3.1) and can't reproduce this, so I need a few details to narrow it down.

1. What Docker runtime are you using?

• Docker Desktop for Mac?
• Colima? (if so, what VM type — vz or qemu? check with colima list)
• Podman?

2. Can you run these and paste the output?

# Your Docker runtime version
docker version

# User info inside the container
./yolobox run id

# Permissions on the mounted project directory
./yolobox run bash -c 'ls -la "$(pwd)" | head -5'

# Numeric UID/GID of the project dir inside the container
./yolobox run bash -c 'stat -c "%u:%g %a %n" "$(pwd)"'

# Host-side permissions on your project directory
ls -la .

3. Did you update Docker Desktop / Colima / Podman around the same time as the macOS update?

My hunch is that the macOS update changed something about file sharing (virtiofs/osxfs) that's causing a UID mismatch — the container's yolo user (uid 1001) can't read files owned by your macOS user (uid 501). But the diagnostics above will confirm.

— Claude (AI assistant helping triage yolobox issues)

[programming-wolf]

I am indeed using Colima, and I also did a brew upgrade straight after the macOS update, but I'm not sure if Colima was part of it.

❯ colima version
colima version 0.10.1
git commit: ed905203afdbc6fd4eae6cc301918099ff31e86e

runtime: docker
arch: aarch64
client: v29.3.0
server: v29.2.0

❯ colima list
PROFILE    STATUS     ARCH       CPUS    MEMORY    DISK     RUNTIME    ADDRESS
default    Running    aarch64    4       4GiB      50GiB    docker

❯ docker version
Client: Docker Engine - Community
 Version:           29.3.0
 API version:       1.53 (downgraded from 1.54)
 Go version:        go1.26.0
 Git commit:        5927d80c76
 Built:             Thu Mar  5 14:22:32 2026
 OS/Arch:           darwin/arm64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.2.0
  API version:      1.53 (minimum version 1.44)
  Go version:       go1.25.6
  Git commit:       9c62384
  Built:            Mon Jan 26 19:26:09 2026
  OS/Arch:          linux/arm64
  Experimental:     false
 containerd:
  Version:          v2.2.1
  GitCommit:        dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc:
  Version:          1.3.4
  GitCommit:        v1.3.4-0-gd6d73eb8
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

❯ yolobox run id
uid=1001(yolo) gid=1001(yolo) groups=1001(yolo)

❯ yolobox run bash -c 'ls -la "$(pwd)" | head -5'
ls: reading directory '/Users/USER/Documents/developer/github_programmingwolf/PROJECT': Permission denied
total 0

❯ yolobox run bash -c 'stat -c "%u:%g %a %n" "$(pwd)"'
501:20 755 /Users/USER/Documents/developer/github_programmingwolf/PROJECT

Host side permissions: 
USER staff rw-r-r

[finbarr]

Thanks for the detailed diagnostics! This confirms the issue.

Your directory has 755 permissions (501:20), so the yolo user (uid 1001) should be able to read it — but virtiofs is enforcing stricter UID-based access at the mount layer. This is a known Colima/virtiofs issue, and your brew upgrade likely updated Colima (you're on 0.10.1) which changed the VM's virtiofs behavior.

Immediate workaround — switch Colima to sshfs mount type (slower but correct permissions):

colima stop
colima start --mount-type sshfs --memory 4

We're also working on a fix in yolobox itself so the container user's UID matches your host UID automatically, which will make this work regardless of mount type.

— Claude (AI assistant helping triage yolobox issues)

[iliasu-zinc]

Hey @finbarr saw you tagged the issue I raised in Colima's repository, as per my last comment from today the spurious permission denials seen in the docker VM stem from the inotify setup on Lima itself, I submitted a patch to Lima which fixes the issue for me at least.

[finbarr]

Good news — we've pushed a fix in e97f273 that automatically remaps the container user's UID/GID to match your host project directory owner. This should resolve the issue on your next yolobox upgrade.

Additionally, @iliasu-zinc identified the root cause as an inotify bug in Lima itself and submitted a fix upstream: lima-vm/lima#4672. Once that lands in a Colima release, the virtiofs permission issue should be resolved at the VM level too.

@programming-wolf can you try upgrading yolobox and let us know if it fixes things for you?

yolobox upgrade

— Claude (AI assistant helping triage yolobox issues)

[programming-wolf]

Awesome, thank you so much for the super fast reaction and a fix! 💜

[finbarr]

@programming-wolf I'll need to bump the version. Claude got a little hasty there in recommending an upgrade!

[programming-wolf]

Yeah, no worries. I will only be at my laptop in 1-2 hours, then I'll try it. 😀

[finbarr]

@programming-wolf once this one completes you should be good to go: https://github.com/finbarr/yolobox/actions/runs/22803606942

Thank you!

[programming-wolf]

I had to restart colima, then it worked. I did receive the same error as before with 0.9.1, until I stopped and started colima, then all worked well. 🙂 Thanks again!