fix(mcp-build): normalize dist modes before cp -a (macOS gRPC-FUSE)#28
Merged
hunzlahmalik merged 1 commit intoMay 20, 2026
Merged
Conversation
On macOS Docker Desktop, Node's fs.cpSync writes files in the bind mount with a com.docker.grpcfuse.ownership xattr declaring mode 200 even when the host inode is 644. The subsequent `cp -a` (and the original `rsync -avr`) then chmod the destination to 200, which lands on the real host inode and renders the bundle unreadable to anything outside the build container (Linux containers via gRPC-FUSE included). chmod-ing packages/server/dist before the copy rewrites the xattr to 644 while the host mode is still 644, so cp -a propagates the correct mode and the bundle is readable downstream. Behaviour on Linux hosts is unchanged: gRPC-FUSE only runs on macOS Docker Desktop; chmod -R is a no-op when modes are already correct. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
On macOS Docker Desktop,
make dev.build.penpot.mcpproduced a bundle whose files were owned mode 200 on the host — making the bundle unreadable to the subsequentrsyncinto the Docker build context, and to any container that later tried to consume them.Root cause
Even with VirtioFS selected in Docker Desktop's UI, both
UseGrpcfuse: trueandUseVirtualizationFrameworkVirtioFS: trueend up in the persisted settings JSON. gRPC-FUSE's ownership-tracking layer remains active and writes acom.docker.grpcfuse.ownershipxattr on any file created via a metadata-preserving op (Node'sfs.cpSync,cp -p, …). For the cpSync insidepackages/server/scripts/copy-resources.js, the xattr lands with"mode": 200even though the host inode is 644.A subsequent
cp -a(orrsync -avr -a) then reads the source mode via the xattr lens, sees 200, andchmods the destination to 200 — which through the VirtioFS layer becomes the real host mode 200. The bundle is now unreadable even by its owner.Fix
chmod -R u=rwX,go=rX packages/server/distafterpnpm run buildand before thecp -a. While the host mode is still 644, the chmod rewrites the xattr mode to 644 (and dir mode to 755), so the subsequentcp -apropagates the correct mode all the way through to the bundle.Impact
rsyncinto the Docker build context succeeds.chmod -Ris a no-op (modes already match) and adds <1 s to the build.Test plan
make dev.build.penpot.mcpon macOS (Docker Desktop, Apple Virtualization framework + VirtioFS selected, withUseGrpcfuse: truestill present in settings) — bundle builds, imagefoss-devstack/penpot-mcp:devproduced.