Repository navigation
sbx (macOS): resolves mkfs.erofs from PATH and picks an unnotarized Homebrew erofs-utils over its own notarized bundled copy — Gatekeeper blocks sandbox build #392
Description
Summary
On macOS, sbx fails to build a sandbox filesystem when a Homebrew erofs-utils is installed: sbx resolves mkfs.erofs from $PATH and picks up the ad-hoc-signed, unnotarized Homebrew binary (/opt/homebrew/bin/mkfs.erofs), which shadows sbx's own notarized bundled copy. macOS Gatekeeper rejects the Homebrew binary, so the first sandbox operation (e.g. sbx policy init balanced) fails:
"mkfs.erofs" cannot be opened because the developer cannot be verified.
macOS cannot verify that this app is free from malware.
Users without Homebrew erofs-utils on $PATH fall back to sbx's bundled copy and never hit this.
Root cause (confirmed on affected machines)
sbx v0.37.1 bundles its own mkfs.erofs and it is correctly notarized — the bug is PATH shadowing, not a missing/ unsigned sbx binary and not a cask dependency:
sbx-bundled .../Caskroom/sbx/0.37.1/libexec/mkfs.erofs |
/opt/homebrew/bin/mkfs.erofs (Homebrew erofs-utils 1.9.2) |
|
|---|---|---|
spctl -a -t install |
accepted | rejected |
| signing | Notarized Developer ID — Docker Inc (9BNSXJN65R) | ad-hoc, TeamIdentifier not set |
| sha256 | df5c5a71… |
be91c6b9… (different build) |
When Homebrew erofs-utils is present, /opt/homebrew/bin/mkfs.erofs is earlier on $PATH than sbx's bundled libexec copy, so sbx invokes the unnotarized one and Gatekeeper blocks it.
There is no com.apple.quarantine xattr on the rejected binary — the block is the code-signing/AMFI assessment, which is why xattr -d com.apple.quarantine (even with sudo) does not clear it.
Environment
- macOS Tahoe (26.x), Apple Silicon
- sbx v0.37.1 (Homebrew cask)
- Homebrew
erofs-utils1.9.2 also installed (symlinked at/opt/homebrew/bin/mkfs.erofs)
Reproduction
- macOS with Homebrew
erofs-utilsinstalled (brew install erofs-utils, or pulled in as a dependency of something else). sbx policy init balanced(or the first command that builds a sandbox filesystem).- Gatekeeper blocks
/opt/homebrew/bin/mkfs.erofs.
Suggested fix
Have sbx invoke its bundled libexec/mkfs.erofs by absolute path rather than resolving mkfs.erofs from $PATH. The bundled binary is already notarized (Docker Inc, 9BNSXJN65R), so no notarization change is needed — it is just being shadowed by an unnotarized system copy.
Workaround (for affected users)
brew uninstall erofs-utils(so sbx uses its own bundled, notarized copy), or- System Settings → Privacy & Security → Allow Anyway on the Homebrew
mkfs.erofs.
Note
Not a supply-chain concern with erofs-utils itself. The mechanism is purely PATH resolution picking an unnotarized system binary over sbx's notarized bundled one.
Activity
docs: link the filed upstream sbx notarization issue
cash commentedon Aug 4, 2026
macOS Tahoe user here and I don't have the above described issue. The sbx cask doesn't list
erofs-utilsas a dependency and it is not installed on my system. My guess is that @wz-gsa haderofs-utilsinstalled before installing sbx and that sbx is using the systemmkfs.erofsrather than the one packaged with sbx.docs: link the filed upstream sbx notarization issue
docs: document macOS Gatekeeper block on sbx helper mkfs.erofs (#263)
wz-gsa commentedon Aug 4, 2026
Update with a definitive root cause (thanks to diagnostics from another affected macOS Tahoe user):
sbx ships a correctly notarized
mkfs.erofs— the bug is that it invokesmkfs.erofsfrom$PATH, so a Homebrewerofs-utilsshadows the bundled copy.Two binaries on an affected machine:
.../Caskroom/sbx/0.37.1/libexec/mkfs.erofs/opt/homebrew/bin/mkfs.erofs(Homebrew erofs-utils 1.9.2)spctl -a -t installdf5c5a71…be91c6b9…(different build)So @cash is right that the sbx cask doesn't declare
erofs-utils— but sbx v0.37.1 does bundle its ownmkfs.erofsunderlibexec/, and that bundled copy is properly notarized by Docker Inc. The failure happens only when a user also has Homebrewerofs-utilsinstalled:/opt/homebrew/bin/mkfs.erofs(ad-hoc-signed, unnotarized) is earlier on$PATHand shadows sbx's notarized copy, so Gatekeeper rejects it. Users without Homebrewerofs-utilson PATH fall back to the bundled binary and never see the block — which matches @cash's experience.Note there is no
com.apple.quarantinexattr on the rejected binary, so the block is the code-signing/AMFI assessment, not the quarantine attribute — which is whyxattr -d com.apple.quarantinedoes not clear it.Suggested fix: have sbx invoke its bundled
libexec/mkfs.erofsby absolute path rather than resolvingmkfs.erofsfrom$PATH. No notarization change is needed — the bundled binary is already notarized; it's just being shadowed.Workaround for affected users:
brew uninstall erofs-utils(so sbx uses its own bundled copy), or System Settings → Privacy & Security → "Allow Anyway" on the Homebrew binary.[-]sbx: bundled mkfs.erofs (erofs-utils) helper is not notarized — macOS Gatekeeper blocks new users at first sandbox use (sbx policy init)[/-][+]sbx (macOS): resolves mkfs.erofs from PATH and picks an unnotarized Homebrew erofs-utils over its own notarized bundled copy — Gatekeeper blocks sandbox build[/+]docs: correct mkfs.erofs Gatekeeper root cause to PATH shadowing (#269)
AustinWise commentedon Oct 22, 2026
This can also cause problems on Linux. In my case, my system is:
apt-get install erofs-utilsWhen I run this command:
It fails with the error message from #481
This is because it is using the
/usr/bin/mkfs.erofsexecutable from Ubuntu instead of the SBX version at/usr/libexec/mkfs.erofs. I can work around this by removing theerofs-utilspackage.docker-sbx-issue-notifier commentedon Oct 26, 2026
This issue was closed automatically because a change for it was merged into the Docker Sandboxes
mainbranch.That change is not in a stable release yet. Sandboxes publishes a stable release every week, so it is normally available within two weeks. We'll comment here again when a stable release includes it. Releases and their notes are listed at https://github.com/docker/sbx-releases/releases.
ericcurtin commentedon Oct 26, 2026
Thank you for the report! sbx now prefers its bundled
mkfs.erofsover one from a system package. It will be in the next nightly build, so expect it in an upcoming release.ericcurtin commentedon Oct 31, 2026
Update: this is in v0.51.0-rc4 (pre-release), so expect it in v0.51.0. Thank you for your patience!
ericcurtin commentedon Nov 6, 2026
Update: this is now in v0.51.0. Please let us know if it does not work for you.