fix bind-mount failure on macOS Docker Desktop

[ericcurtin]

Docker Desktop on macOS only shares specific directories with its Linux VM via VirtioFS ($HOME, /private, /Volumes, /tmp). Scripts installed to /usr/local/bin (e.g. via Homebrew) are not accessible, so Docker creates an empty directory placeholder in the VM. This makes /usr/bin/entrypoint a directory in the container, causing runc to fail with "is a directory".

distrobox-create: on Darwin, copy distrobox-init, distrobox-export, and distrobox-host-exec to ~/.local/share/distrobox/ (always under $HOME, always VirtioFS-shared) before using them as bind-mount sources.

distrobox-enter: the self-healing detection code reads .HostConfig.Binds, which Docker Desktop returns with a /host_mnt prefix (the VM's view of the VirtioFS mount). Strip this prefix on Darwin before checking file existence, preventing a spurious "mkdir: /host_mnt: Read-only file system" crash even for correctly-created containers.

[ericcurtin]

I didn't notice this before because during development was using my git repo which is in $HOME

[89luca89]

Would it make sense to have this logic as a pre-flight check in distrobox command instead? So it's all in one place?
It would defy it when people use distrobox-create or distrobox-enter directly but this should be rare enough (given that single entrypoint is suggested as default from the beginning almost)

EDIT: or maybe we can fix it on brew tap to contextually install it to ~/.local/bin too (or only there)
EDIT2: also I'm worried about stale entries during upgrades, or uninstalls

[ericcurtin]

What about a hard link? Then we never go stale, because the same file is shared

[89luca89]

What about a hard link? Then we never go stale, because the same file is shared

If it works on macos like it works on linux I suppose yes, cp should preserve inode number.
But what about on uninstall? We can handle the uninstall via script, but brew won't cover it, and copied scripts will be kept around, and based on the user's setup, it might still be accessible (if they have ~/.local/bin in PATH)

[ericcurtin]

Regarding the hard link idea: it might be risky because Homebrew updates often replace the file (creating a new inode), which would leave the hard link pointing to a stale/orphaned version of the script.

What if we treat ~/.local/share/distrobox/ as a managed cache?

1. In the main distrobox entry point, we add a macOS-specific check.
2. If the scripts in /usr/local/bin are newer than the ones in ~/.local/share, we cp them over.
3. This solves the 'stale entry' problem on upgrades automatically.

For uninstalls, it does leave a small footprint, but that's fairly standard for macOS CLI tools. We could just document it or add a cleanup flag to distrobox-rm. This keeps the logic centralized and avoids the VirtioFS mount issues entirely.

[89luca89]

Regarding the hard link idea: it might be risky because Homebrew updates often replace the file (creating a new inode), which would leave the hard link pointing to a stale/orphaned version of the script.

What if we treat ~/.local/share/distrobox/ as a managed cache?

1. In the main distrobox entry point, we add a macOS-specific check.
2. If the scripts in /usr/local/bin are newer than the ones in ~/.local/share, we cp them over.
3. This solves the 'stale entry' problem on upgrades automatically.

For uninstalls, it does leave a small footprint, but that's fairly standard for macOS CLI tools. We could just document it or add a cleanup flag to distrobox-rm. This keeps the logic centralized and avoids the VirtioFS mount issues entirely.

Agree, it should be in one entry point and should handle staleness
For the litter, well yea we should document that, maybe brew folks also have a solution, I don't know

[ericcurtin]

@89luca89 made another change, let me know what you think

[ericcurtin]

My biggest worry about only putting the scripts in ~/.local/ in thing's like this won't "just work"

curl -s https://raw.githubusercontent.com/89luca89/distrobox/main/install | sudo sh