mosaicstack/stack
1
0
Fork 0
Code Issues 42 Pull Requests Actions Packages Projects Releases 15 Wiki Activity

mosaic 0.0.31: npm package drops exec bits on tools/_scripts/* — breaks 'mosaic yolo' preflight #539

New Issue
Open
opened 2026-06-12 06:01:54 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-06-12 06:01:54 +00:00
Owner
Copy Link

Symptom

After installing @mosaicstack/mosaic@0.0.31 via npm, every file synced to ~/.config/mosaic/tools/_scripts/ is mode 644 (no exec bit). This breaks the mosaic yolo preflight, which invokes these scripts directly (e.g. mosaic-doctor, mosaic-critical) and fails with permission-denied.

Evidence

The published package payload itself ships without exec bits — this is a pack-time loss, not an install-time one:

$ ls -l ~/.npm-global/lib/node_modules/@mosaicstack/mosaic/framework/tools/_scripts/
-rw-r--r-- 1 hermes hermes  4342 mosaic-bootstrap-repo
-rw-r--r-- 1 hermes hermes  3285 mosaic-clean-runtime
-rw-r--r-- 1 hermes hermes   198 mosaic-critical
-rw-r--r-- 1 hermes hermes 13996 mosaic-doctor
...

npm preserves tarball modes on install, so files that enter the tarball as 644 install as 644.

Workaround (applied locally on web1)

chmod +x ~/.config/mosaic/tools/_scripts/*

Suggested fix (either works; both is belt-and-braces)

  1. Ensure exec bits survive packing: confirm the files have the exec bit in git (git update-index --chmod=+x) and that no build/copy step (e.g. a copy via fs.copyFile / tar without mode preservation) strips them before npm pack.
  2. Defensive: have the runtime sync step that populates ~/.config/mosaic/tools/_scripts/ chmod +x what it copies, so a bad tarball can never break preflight again.

Observed on: web1, Linux, npm global install, @mosaicstack/mosaic@0.0.31.

## Symptom After installing @mosaicstack/mosaic@0.0.31 via npm, every file synced to ~/.config/mosaic/tools/_scripts/ is mode 644 (no exec bit). This breaks the mosaic yolo preflight, which invokes these scripts directly (e.g. mosaic-doctor, mosaic-critical) and fails with permission-denied. ## Evidence The published package payload itself ships without exec bits — this is a pack-time loss, not an install-time one: $ ls -l ~/.npm-global/lib/node_modules/@mosaicstack/mosaic/framework/tools/_scripts/ -rw-r--r-- 1 hermes hermes 4342 mosaic-bootstrap-repo -rw-r--r-- 1 hermes hermes 3285 mosaic-clean-runtime -rw-r--r-- 1 hermes hermes 198 mosaic-critical -rw-r--r-- 1 hermes hermes 13996 mosaic-doctor ... npm preserves tarball modes on install, so files that enter the tarball as 644 install as 644. ## Workaround (applied locally on web1) chmod +x ~/.config/mosaic/tools/_scripts/* ## Suggested fix (either works; both is belt-and-braces) 1. Ensure exec bits survive packing: confirm the files have the exec bit in git (git update-index --chmod=+x) and that no build/copy step (e.g. a copy via fs.copyFile / tar without mode preservation) strips them before npm pack. 2. Defensive: have the runtime sync step that populates ~/.config/mosaic/tools/_scripts/ chmod +x what it copies, so a bad tarball can never break preflight again. Observed on: web1, Linux, npm global install, @mosaicstack/mosaic@0.0.31.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#539
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?